設計について学習してみた。（データベース論理設計編）

はじめに

今回は、データベース論理設計についての紹介です。
下記観点からの理解につながれば幸いです。

1. What データベース論理設計ってなに？
2. When データベース論理設計は、どのタイミングでやるのか
3. Why なぜデータベース論理設計をやるのか
4. How データベース論理設計のやり方（データベース論理設計をやってみよう！）

目次

章	タイトル	概要
1	データベース論理設計ってなに？	データベース論理設計の基本的な考え方について紹介します。
2	データベース論理設計は、どのタイミングでやるのか?	アプリケーション開発のどの段階で、実施するのか紹介します。
3	なぜデータベース論理設計をやるのか	データベース論理設計の目的や意義について紹介します。
4	データベース論理設計をやってみよう！	実際にデータベース論理設計をやりながら、実施していく際のポイントを紹介します。

1.データベース論理設計ってなに？

結論、データベース論理設計とは、概念モデリングの際に出てきた情報や、概念モデリングで表現されたモデルを、リレーショナルデータベースで扱える形式に書き換えることです。

 
 
 
ここで一度、前回やった概念モデリングを思い出してください。
 

 
この概念モデリングによって、楽天市場アプリケーションの開発において必要な情報や、その情報の関係性が整理できたと思います。
実際に開発をしていくとなった場合は、この概念モデリングによって洗い出された情報を、データベースに保持させたりするんだろうなぁと、ぼんやりとしたイメージは湧いてくるかと思います。

ただこの概念モデリングだけを元に、データベースやテーブルを作成しようとしてもちょっと厳しいかと思います。
なので、今回のデータベース論理設計を行い、アプリケーション開発に必要な情報を、データベース上のテーブルとして管理するにはどうしたらいいか、テーブル同士のリレーション（関係）をつなげるにはどの情報をキーに繋げたらいいかを決めて、ぼんやりとしたイメージを実際の開発時に使える明確な設計資料に近づけていきます。
 
 
 

 
 
 
この明確なイメージに近づけていくために、論理ER図というものを作成します。
論理ER図の作成方法については、後ほど詳しく説明します。
また、データベース論理設計の中で、論理ER図作成の後に正規化という工程があります。
この正規化をすることによって、容量が節約され、アプリケーション運用後のデータの変更に柔軟に対応できるようなデータベースの作成につながります。
この正規化のやり方についても、後ほど詳しく説明します。

要するにデータベース論理設計は、概念モデリング図を元に、「データベースのテーブルに保存する項目を決め」、「テーブルの関係性を表し」、「効率の良いデータベースになるように、テーブルを分割したりする」といったものになります。

2.データベース論理設計は、どのタイミングでやるのか？

結論、外部設計のフェーズでやることが多いそうです。

 
要件定義のフェーズで、実施した概念モデリング上の概念データモデルを、データベース上で管理できる形に書き換えていく作業なので、外部設計のタイミングで実施することが多いそうです。

3.なぜデータベース論理設計をやるのか。

結論、下記のようなメリットがあります。

・データベースで必要なデータの種類や関連を明確にするのに役立つ。

・アプリケーション開発チーム内に、共通の理解をもたらす。

・データの効率的な格納とクエリ実行をサポートし、データベースのパフォーマンスを向上させる。

・データベースの保守を容易にし、エラーや問題の発生の減少につながる。

まず、「1.データベース論理設計ってなに？」での説明と重複しますが、データベースで必要なデータの種類や関連を明確にするのに役立ちます。
データベース論理設計は、概念モデリング図をもとに、「データベースに管理させる必要があるデータってこれがあるよね」、「このデータは１つのテーブルとして管理した方がいいよね」、「テーブル同士の関係性はこのデータをもとに繋がっているよね」などと、あれこれ考えて情報を、データベース上で管理できる形に置き換えていく作業です。
なので、もちろんデータベースで必要なデータの種類や関連を明確にするのに役立ちます。

次に、アプリケーション開発チーム内に、共通の理解をもたらすというメリットがあります。
この共通の理解は、開発時のメンバーだけでなく、開発後の運用・保守のメンバーにまでもたらすメリットといえます。
実際、世に出回っているアプリケーションは、作って終わりではなく、長い期間運用されていくものがほとんどだと思います。
その中で、企画から設計、開発、テスト、保守・運用（また場合によっては、エンハンスといった機能追加もあります。）とさまざまな工程を踏んでいきます。
その工程の中で、すべて一貫して同じメンバーで実施するということは稀だと思います。
新しいメンバーが増えたり、工程ごとにメンバーが入れ替わったりなどなど。
そういった新しく参画したメンバーに、データベース論理設計で作成した資料を見せることで、既存のメンバーと同じ認識・理解を持たせることにつながります。

３つ目に、データの効率的な格納とクエリ実行をサポートし、データベースのパフォーマンスを向上させるといったメリットがあります。
こちらのメリットは、正規化の工程を踏むことによって得られます。
正規化では、データが無駄に重複して格納されたりしないようなデータベース構造になるように、データを小さなテーブルに分割していきます。重複したデータがなくなり冗長性が削減されることにより、変更や追加が容易に行えるデータベースになります。
また正規化によって、各テーブルで無駄なデータを持つことがなくなるので、クエリ実行で検索する際の処理時間が短縮されます。

最後にデータベースの保守を容易にし、エラーや問題の発生の減少につながるといったメリットがあります。
データベース論理設計を行うことにより、データが整理された構造で配置されます。
そうすることで、データの変更が容易になり、保守性が向上します。
また、データの一貫性も確保されるので、同じ情報を異なる場所（テーブル）に格納してエラーが発生することも防ぎます。

4.データベース論理設計をやってみよう！

では実際にデータベース論理設計をやってみましょう！

まず、実施の大まかな流れは、「論理ER図を作成」→「正規化」となります。

①論理ER図を作成

論理ER図の作成は下記ポイントを踏まえて、概念モデルを見ながら順番に進めていきます。

1. 主キーを決める
2. 関連を外部キーにする
3. 多対多の関連を関連テーブルにする
4. 継承をリレーショナルで実現する

今回は、前回やった楽天市場の概念モデルに、注文決済モデルを追加した下記の概念モデルをもとに論理ER図を作成していきます。

 
 
1.主キーを決める
まず、概念モデルをデータベースで扱える形式に書き直す最初の作業として、概念をそのままテーブルにします。（ここでは注文の概念を取り上げます。）

概念モデルの概念と同じ名前をテーブル名にします。
注文合計金額などの属性も、そのままテーブルに追加します。
そして候補キーを洗い出し、その中から主キーを決めます。
候補キー・・・テーブルのレコードを一意に識別する属性
主キー・・・候補キーの中から選ばれる属性。他のテーブルとの関連付けに使用される。

この「注文」概念の中では、候補キーは「注文番号」のみになります。
注文番号は楽天市場のシステム内で採番した、注文を一意に識別するための番号になります。
この時点で、主キーは注文番号でよさそうに思えます。
しかし、まだ注文番号で確定してはいけません。
主キーにする条件として、「レコードを一意に識別する属性である」ということの他に、「変更されないものである」ということが必要になります。
注文番号は変更されることはないでしょうか？
注文番号は、セキュリティ上の懸念が発見されたり、後々他のシステムとの統合がされる場合に、注文番号の形式を変える必要性が出てきて、変更される可能性があります。
注文番号は主キーとしての条件を満たしていません。
となると、主キーとなりうる属性がなくなりました。
この場合は、システムが自動で連番を採番する注文IDといった属性を追加して、それを主キーにします。
注文IDは、「レコードを一意に識別する属性である」、「変更されないものである」の条件を満たす属性なので、問題なさそうです。
これまでの概念モデルからの変更をまとめると下記の図になります。
（ER図のIDEF1X記法にならって、ハイフンなどは削除しています。）

また全体に変更を加えたものは下記になります。
（より具体的にイメージできるように属性をいくつか追加しております。）
（注文決済関連の主キーが全て注文決済IDになっていることについては、後述します。）

2. 関連を外部キーにする。

次に概念間の関連を、外部キーを使用して表現していきます。
一方のテーブルの主キーが、もう一方のテーブルの列に外部キーとして存在することによって、テーブル間を関連付けます。
外部キーを使用して関連を表現したものが下記になります。

ER図において「一対多」の関係を表現するときは、「一」の方に白抜きの菱形を、「多」の方に黒丸をつけ、破線で関連を表現します。
そして外部キーには、foreign keyの意味を持つ（FK）を記述して外部キーの属性であることを明示します。
（注文決済の関連については後述します。）

3. 多対多の関連を関連テーブルにする
   今回、取り組んでいる楽天市場の例では、多対多の関連はありませんが、もし下記のような多対多の関連があった場合、
   

下記のように２つのテーブルの間に関連テーブルを作って実現します。

リレーショナルデータベースでは、多対多でテーブルが関連している場合、両方の主キーを全て持つテーブル（関連テーブル）を作成することによって、関連性を表現します。

4. 継承をリレーショナルで実現する
   論理ER図作成の最後の工程として、概念モデル内で継承があった際の、論理ER図上で表現するための方法を説明します。
   論理ER図で継承を実現するためには以下の３つの方法があります。
   ・抽象クラスと具象クラスごとにテーブルを作る
   ・具象クラスごとにテーブルを作る
   ・クラス階層ごとに汎用テーブルを作り、さらに型を表すカラムを用意する
   今回は、この中の抽象クラスと具象クラスごとにテーブルを作る方法でやっていきたいと思います。
   （他の２つの方法についての説明は、割愛します。）

この方法は、継承をテーブル間のリレーションで置き換える方法になります。
具象クラスが後ほど増えたり、変更されたとしても、柔軟にテーブルを追加、変更しやすいのが特徴です。
しかし、一方で、SELECT文などでデータの検索をかける際に、抽象テーブルと具象テーブルをJOINして取得するため、パフォーマンスが低くなるデメリットがあります。

それでは、やってみましょう。
本記事から概念モデルに追加した注文決済モデル関連をもとに、論理ER図上で継承を表現します。
まず、抽象クラスのテーブルと具象クラスのテーブルに分けて整理します。
そして抽象テーブルの主キーを外部キーとして具象テーブルの主キーに指定します。

その後、抽象テーブルから具象テーブルに実線を引き、具象テーブル側に黒丸をつけます。

これを、全体の論理ER図に反映させると下記になります。

ここまでが論理ER図を作成の工程になります。
ここまでできたら、後半の正規化の工程に入っていきます。

②正規化

正規化という作業は、第一正規化〜第六正規化まであるそうなんですが、業務上は第三正規化までで十分なことが多いので、今回は第一正規化から第三正規化までをご紹介いたします。

1.　第一正規化
第一正規化では、繰り返し出てくるカラム（属性）がないテーブルにすることです。
例えば、下記のようなテーブルがあったとします。（右側は実際にRDBでテーブルを構築した際のイメージです。）

このテーブルは、明らかに冗長であると言えそうです。
商品カラムと単価カラムが繰り返し構造を持ってしまっています。
このようなテーブル設計をしてしまった場合、一度に注文する商品の量を４つ以上にしてしまうと破綻してしまいます。
このようなテーブルがあった場合の第一正規化は、商品（商品名カラムと単価カラム）の繰り返しを取り除きます。

そうすると実際にRDB上でテーブルを作成した場合は下記のようになります。

テーブル内の商品関連のカラムの繰り返し構造がなくなり、一度に注文する量が増えても破綻することは無くなりました。
このようにカラムの繰り返しを取り除く工程を第一正規化と言います。

2.　第二正規化
第二正規化は「部分関数従属」をしているカラムを切り出したものになります。
「部分関数従属」は「あるIDが決まれば、それ以外の情報が決まる」というデータのことを言います。
ですので、第二正規化をする際は、主キーを見つけ、主キーが決まればそれに紐づいて確定するカラムかどうかを考えていきます。
実際に下記のようなテーブルの場合だと、主キーの注文IDが決まれば注文番号、注文日、ユーザーID、購入ユーザーは決まります。
そして、残りの商品名、単価は注文IDが決まっても、値は決まりません。

そうなった場合に、商品名と単価を別テーブルとして切り出し、主キーを作ります。

以上で第二正規化は完了となります。

3.　第三正規化
第三正規化は「推移的関数従属」を除いたものになります。
推移的関数従属とは、「『あるIDが決まると決定されるID』によって確定する情報が存在する状態」を意味します。
実際に下記のような注文テーブルの場合だと、主キーの注文IDが決まれば、ユーザーIDが決まり、それによって購入ユーザーが決まる構造があります。

そのようなテーブルがあった場合に第三正規化を行います。
ユーザーIDと購入ユーザーをユーザーテーブルとして分離します。

以上で第三正規化は完了となります。

まとめ

データベース論理設計は、概念モデリングの際に出てきた情報や、概念モデリングで表現されたモデルを、リレーショナルデータベースで扱える形式に書き換えるといった重要な工程になります。
論理ER図の作成で、データベースで必要なデータの種類や関連を明確にする。
正規化で、データベースの保守を容易にする。
そうすることで、後のデータベース構築を、整理できた状態で保守性高い構造に構築できるようになると思います。
また今後、内部設計のデータベース物理設計を執筆予定ですが、データベース物理設計では、今回の論理ER図をもとにテーブル名やカラム名、カラムの型、サイズも決めていきます。
今回学習の参考にした書籍は下記になります。
設計の基本を知らなくても理解できる内容になっております。

https://www.shoeisha.co.jp/book/detail/9784798153766

次の記事は、「非機能要件定義とシステム設計」についての執筆を予定しています。

拙文最後までお読みいただきありがとうございます。