かけだしSEのためのデータベース設計入門

データベースの設計フェイズには、大きく分けて「概念設計」「論理設計」「物理設計」の３段階があります。

１．１　概念設計とは

概念設計では、データベースを必要とする業務を行うために必要なデータを抽出し、「概念データモデル」を作成します。

１．２　論理設計とは

論理設計では概念データモデルを整理し、使用するデータベースの種類に合わせた形に変換を行うことで「論理データモデル」を作成します。

１．３　物理設計とは

物理設計では必要なハードウェア資源を確保し物理的なデータ配置を決定するだけでなく、パフォーマンスを考慮してデータベースを整理し、より現実的な「物理データモデル」を作成します。

各フェーズの詳しい手順は、次の項目にてご説明致します。

２．１　要件を明確にする

まず初めに、作成しようとしているデータベースで一体どんなデータを管理したいのかを確認します。データベースを使用する対象の業務を詳細に分析し、必要な要件を洗い出します。ここで要件定義が不十分だと後で大問題につながるため、特に顧客データベースを作成する場合などは思い込みを排除して十分な打ち合わせを行うことが重要です。

２．２　エンティティを抽出する

エンティティとは日本語で「実体」と訳されますが、ここでは「ある目的のデータひとかたまり」というイメージです。データのカテゴリという感じを想像して頂けると分かりやすいかと思いますが、例えば社員データを管理したい場合、「氏名」や「役職」、「所属部署」などがエンティティとして抽出できます。

２．３　概念データモデルを作成する

業務に必要なエンティティを全て洗い出したら、それを元に最初のデータモデルとなる「概念データモデル」を作成します。この段階では、どのタイプのデータベース（リレーショナルデータベースかNoSQLかなど）を利用するか特定しないようにモデルを作成します。

２．４　ER図を作成する

概念データモデルの作成には、ER図が多く用いられます。次の図は、社員データを表すER図の例です。なおER図の書き方にはいくつかあり、代表的なものには「IE記法」や「IDEF1X記法」などがあります。今回は、「IE記法」を例にとってご説明します。

まず社員データを取りまく部署データ、役職データ、等級データをそれぞれ大きな分類とし、日の下部分に抽出したエンティティを余さず配置し、整理します。

次に、データを特定するための主キーを決定します。今回、社員データは「社員番号」、給与等級データは「等級」がそれぞれのデータの中で一意になるので、それを主キーに設定します。 役職と部署については重複が考えられる項目しかないため、専用の主キーを用意します。

最後にリレーションを設定します。関係のあるデータ同士を線でつなぐ「リレーション」に、図の鳥の足のような「カーディナリー」を記入します。このカーディナリーは「多重度」を表しており、図のようなものは「１：多（１：１以上）」を表しています。（鳥の足のようなものが「多」を表す記号です）

３．１　ER図をRDBのテーブルに変換する

論理設計では、まずデータベースの種類を決定し、それに沿った形に変換したテーブル定義を作成します。これを「論理データモデル」と呼びます。

上図ではデータ型も記載していますが、正しくは後の物理設計フェイズにて決定します。

３．２　正規化を行う

作成したテーブルから冗長な部分などを削除するため、正規化を行います。上図では、すでに第３正規化まで必要のない状態まで分解されています。

なお詳しい正規化の手順については、次の記事をご参照下さい。

■関連記事： リレーショナルデータベース正規形の種類と正規化手順

４．１　物理設計の手順

物理設計では、データの入れ物など物理的な部分を決定していきます。まず「文字列」「数字」「英数字（半角）」などのデータ型を決めます。

４．２　性能要件を確認する

１日に何件、年間何件ずつデータが追加されるのかの容量や、一度にどのくらいアクセスがあるのかなど、業務を円滑にすすめるために必要なハードウェアやネットワークなどの性能要件を確認します。

４．３　インデックスを作成する

性能（パフォーマンス）向上のために、インデックスを作成します。データベースにインデックスを登録すると、処理スピードの向上が図れます。物理設計まで行われて修正が加えられたデータモデルを、「物理データモデル」と呼びます。

４．４　必要に応じて正規化を崩す

また正規化の関係でパフォーマンスが足りない場合、あえて正規化を崩すことがあります。

４．５　データ格納領域を設計する

性能要件にて確認した量のデータを十分に格納できるだけのデータ領域を計算し、ハードウェアの仕様やハードウェア上でのファイルの配置を決定します。

今回の記事をまとめるにあたりOracle社から提供されているDB設計の手順書や関連書籍などを確認しましたが、自分が現場で経験したことだけでなく、本によっても各フェイズで行う内容がずれているケースがみられました。（テーブル定義を決めるのが論理か物理かで割り振りが異なるなど）このようにDB設計は一概に言えるものではありませんが、本記事でおおまかな流れのイメージを掴んで頂けたら幸いです。