真のデータベースエンジニアを目指そう！：データベースエンジニアへの道（1）（3/3 ページ）

[阿尾操, 下平浩由，アクセンチュア・テクノロジー・ソリューションズ]

論理データモデル

　論理データモデルは、概念の世界で集めてきたデータ項目のうち、ユーザーにシステム化を期待される範囲でコンピュータに記憶される永続的なデータを対象としたデータモデルです。

　論理データモデルには、4つのデータモデル・タイプ（階層型、ネットワーク型、リレーショナル型、オブジェクト型）がありますが、データ構造を最も表現しやすいタイプに当てはめて論理データモデルを作っていきます。いわゆるER図は、この論理データモデルの「リレーショナル型」に当たります。

　一般的に、データベースの実装方式が「リレーショナル・データベース」であることを前提として、論理データモデルのタイプにリレーショナル型を選択していると思いますコラム2。

　リレーショナル型の表記にはER図を用います。論理データモデルを作成する際には、「リソース系エンティティ」と「イベント系エンティティ」の切り出し、それらのリレーションシップを整理していきます。また、エンティティ内に詳細な属性を定義し、「コード設計」によって体系化します。さらに、概念ER図とは異なり、ここではデータがコンピュータに蓄積されることを考慮するため、システム的に重複のない、無駄のないデータ管理を実現するため「正規化」を行います。

　なお、今回の連載において特に断りなく論理データモデルと表現した場合は、リレーショナル型を指しているものとします。

Point

• システム化の範囲において、コンピュータに記憶される永続的なデータを対象とする。
• 概念ER図の「エンティティ」を「リソース系エンティティ」と「イベント系エンティティ」に切り出す。
• システム的に重複のない、無駄のないデータ管理を実現するため、「正規化」を行う。
• 「論理データモデル」は、ER図で表す。

コラム2

論理データモデルはデータベースの実装方式とは独立している

　論理データモデルをリレーショナル型で作成することと、データベースの実装方式としてリレーショナル・データベースを採用することはイコールではありません。あくまでも論理データモデルのデータ構造の表現形式の1つとしてリレーショナル型があり、論理データモデルは実装方式には依存せず、独立した関係にあります。

　しかし、現実的には論理データモデルのタイプにデータベースの実装方式を一致させることは設計において非常に効率が良く、一般的に行われています。例えば、論理データモデルのリレーショナル型の表記に使われるER図は、リレーショナル・データベースの実装にマッピングしやすく（エンティティ→テーブル、リレーションシップ→リレーションシップ）、設計フェイズで一貫してER図を使うことによって見通しの良いモデリングを行うことができます。

　与件としてデータベースの実装方式がリレーショナル・データベースであることが分かっているならば、あえて論理データモデルのタイプに「階層型」や「ネットワーク型」を採用することはないといえます。

物理データモデル

　物理データモデルでは、利用する実装環境（ハードウェアも含む）の特性を考慮して論理データモデルを物理データモデルへ変換します。ここで初めて、ソフトウェアとしてのデータベースの話が出てきます。多くの場合、リレーショナル・データベースが採用され、Oracle、DB2、SQL Serverなどの具体的なRDBMSへの実装を目的とした物理データモデルを作成します。

　つまり、物理データモデルは個々のデータベース製品の機能に依存しているため、ある単一システムを設計する際に、「概念データモデル：論理データモデル＝1：1」ですが、「論理データモデル：物理データモデル＝1：N（実装するデータベース製品の種類）」という特徴があります（図3）。

図3　データモデルの位置付け

　ここでは、データ型の定義、ビューの定義、インデックス設計、定義や各種のパラメータ設定など物理的な環境に依存した物理データモデルを作ります。また、非機能要件としてのパフォーマンス・チューニング（データ容量、表領域の計算）などの調整もここで行います。また必ず必要なわけではありませんが、検索などのパフォーマンスを考慮して「非正規化」を行うこともあります。

　なお、今回の連載において特に断りなく物理データモデルと表現した場合は、リレーショナル・データベースを対象としているものとします。

Point

• RDBMS全般の知識、製品固有のデータベースの知識を駆使する。
• 「インデックス設計」を行う。
• 「非正規化」を行う。
• 非機能要件としての「パフォーマンス・チューニング」を行う。

　以上のようにして各データモデルを作成し、最終的にデータベースが出来上がります（図4）。

図4　データベースを構築するまでの流れ

　以上、設計・構築フェイズで作成されるデータモデルについて解説してきました。データモデルが何を意味するものであるか、感じだけでもつかめていただけたでしょうか？ 一般的に、DAが概念データモデルと論理データモデルを作成し、DBAが物理データモデルを作成します。しかし、アプリケーションの規模やプロジェクトの事情によっては、論理データモデルからDBAが担当することもあります。

今回のまとめ

　今回は、データベースエンジニアとは何であるかを定義し、併せてデータベース開発工程の設計・構築フェイズで作成されるデータモデルについて解説してきました。

　現実的には、ある日突然、皆さんがDAやDBAの役割を担うようなことは少ないかもしれません。しかし、いつそのチャンスが巡ってきてもよいように日ごろから準備しておくことが肝心です。チャンスが巡ってきてからキャッチアップをすればよいなどと考えている人には、そのチャンスさえも巡ってこないものです。

　次回からは、「データベースエンジニアになるための必須知識」について、実例を交えながら紹介していきます。（次回へ続く）

筆者プロフィール

▼アクセンチュア・テクノロジー・ソリューションズ

アクセンチュアから生まれた、企業改革のためのシステム開発を手掛けるエンジニア集団。安間裕が代表取締役社長を務める。阿尾操はOracleとDB2に精通し、最近も、Seasar2がお気に入りのシステム・アナリスト。下平浩由はネットワーク、データベースなどのインフラ／ミドルウェアに精通したシニア・システム・アナリスト。