はじめての設計をやり抜くための本【設計編】第3章外部設計の手法⑨データベース論理設計
DB論理設計の概要
概念モデルをもとにDB論理設計を行う。DB論理設計ではDBに作成するテーブルとテーブルのカラム、またそれらのカラムがテーブルにおいてキーであるかなどを設計する。
→論理ER図を作成する。（表記方法：IDEF 1X表記もしくはIE表記を使用）
本書籍ではIDEF 1X表記を採用
ER図はER図作成ツールを使用する。ツールはIDEF 1X表記 とIE表記の両方をサポートしているものが多い。
概念モデルを既に作成しているので、DB論理設計は難しくはない。
DB論理設計の目的は、概念モデルで作成したモデルをリレーショナルデータベースで扱える形式に書き換えること。
■リレーションの正規化
正規化：データの冗長性を排除し、データに一貫性を持たせて、不整合なく管理する方法。第１正規形から第５正規形まである。（一般的には第３正規形まで行う）
第１から順番に正規化について記載する。
○第１正規形
テーブルの全てのカラムがこれ以上「分割できないカラム」で構成されているテーブルのこと。「分割できないカラム」とは繰り返し構造のないテーブルのこと。また、これ以上分割できない値、単一の値をスカラ値と呼ぶ。
※逆に配列、リスト、レコードなど複数の値の集合を非スカラ値と呼ぶ。
例：社員テーブル（第１正規形になる前）
この会社では社員は複数のプロジェクトにアサインされることがある。
上記の図ではプロジェクト名が繰り返し構造をもっているので、第１正規形ではない。その繰り返し構造のプロジェクトを別テーブルに移す
例：社員テーブル（第１正規形なった後）
※XML文書が文字列カラムに登録されている場合、XMLタグ単位で分割は
できるが特に理由がなければXML文書は単一の値として１つのカラムに登録する。
例：社員テーブル（XML文書そのまま格納）
○第２正規形とは
あるテーブルが第１正規形であり、かつ全ての非キーカラムが全ての候補キーに対して完全関数従属する場合のテーブルのこと。言い換えると、全ての非キーカラムが全ての候補キーに対して部分関数従属しないテーブルのこと
候補キーとは
その行を一意に特定することができるカラム、もしくはカラムの集合を指す。候補キーの中から１つが主キーになることができる。
行には必ず候補キーが１つ以上ある。例として下記の図を示す。
[３つの候補キー]
・社員番号（主キー）
・社会保険番号
・所属IDと名前 ※所属している部署に同姓同名の人がいない場合
関数従属とは
Aが決まるとBも必ず決まる関係（表記：A→B）
この場合、Aを決定項、Bを従属項と呼ぶ
上記の例の場合、社員番号が決まると社員が決まるので「社員は社員番号に関数従属する」といえる。同じように「社員は社会保険番号、所属IDと名前でも関数従属する」といえる。
部分関数従属とは
上記の例では、所属名は所属IDに関数従属している。所属IDは候補キーの部分集合である。決定項である候補キーの部分に関数従属することを部分関数従属と呼ぶ。候補キーに対して部分関数従属していると第２正規形ではない
第２正規形にするには下記の図のように分割する。
○第３正規形
あるテーブルが第２正規形であり、かつ全ての非キー属性が全ての候補キーに非推移的に完全関数従属する場合のテーブルのこと。
※第２正規形は候補キーへの部分関数従属を禁じているが、第３正規形は候補キーへの推移的な関数従属を禁止している。
＊関数従属とは「A→B」のこと。推移的な関数従属とは「A→B→C」のこと
上記の例では、社員テーブルの候補キーには「社員番号」、「社会保険番号」、「所属IDと名前」の３つがある。
※「所属IDと名前」が候補キーになるのは同じ所属に同姓同名を配属しない場合のみ。
例：第３正規形（同じ所属に同姓同名を配属する）
「社員番号」、「所属ID」、「所属名」は推移的な関数従属の関係にある。
社員番号が決まると所属IDが決まり、所属IDが決まると所属名が決まる。
（社員番号→所属ID→所属名）
例：第３正規形（社員番号→所属ID→所属名）
論理ER図の作成
DB論理設計では概念モデルを元に論理ER図を作成する。
[ER図作成の注意点]
・主キーを決める
・関連を外部キーにする
・多対多の関連を関連テーブルにする。
・継承をリレーショナルで実現する。
■主キーを決める
概念モデルのそれぞれの概念を論理ER図のテーブルとして作成する。ER図作成ツールによりテーブルをエンティティと呼ぶことがある。
概念モデルに「注文」という概念がある。それをそのままテーブルにする。
●主キーの付け方
・人口キー
シーケンスなどの連番をシステムが自動的に採番して主キーとする。
・自然キー
注文の注文番号のように、実際にそのテーブルに存在するカラムを組み合わせて主キーとする。
・自然キーの欠点
主キーという変更できないものに業務やドメインに依存するカラムを使用すると、業務やドメインの変化が致命的な問題になる。
・人口キーの欠点
自然キーではデータベースで一意制約を保証できるが、人口キーではプログラムで保証する必要があること。また、人口キーは連番になることが多い
のでシステム外の利用者や外部システムには公開しない。
例：注文テーブル（人口キーによる主キー：注文ID）
■関連を外部キーにする
概念モデルの概念の間には関連がある。
例：概念モデルの関連
例：ER図の関連
概念モデルの概念間の関連は、論理ER図の外部キーとして表現されます。
外部キーでは参照先のテーブルの主キーを持つ。注文テーブルからは会員IDを持つ。そして注文明細では注文IDを外部キーとして持つ。
■多対多の関連を関連テーブルにする
基本的に概念モデルの関連は１対多が望ましい。多対多のモデルがある場合は「本当に必要なのか」を考えることが必要。他の概念を経由すれば間接的に関連をもつことができるなら、多対多の関連を持つ必要はない。
■継承をリレーショナルで実現する
概念モデルの継承をリレーショナルデータベースで実現する
継承を実現する３つの方法
・抽象クラスと具象クラスごとにテーブルを作る
・具象クラスごとにテーブルを作る
・クラス階層ごとに汎用テーブルを作り、さらに型を表すカラムを用意する
○抽象クラスと具象クラスごとにテーブルを作る
継承をテーブル間のリレーションで置き換える方法。クラスごとにテーブルを作成するので、概念モデルを素直に表現でき、正規化が十分に行われる。
○具象クラスごとにテーブルを作る
継承の考え方を捨て、具象クラスごとに抽象クラスのデータを含めてテーブルを作る方法。１つの具象クラスが１つのテーブルに対応付けられるので、非常に簡単。ただし、ポリモーフィズムを表現できない。例えば、抽象クラスでデータや何らかの関連を持っていても、各テーブルに分散して配置されてしまう。
○クラス階層ごとに汎用テーブルを作り、さらに型を表すカラムを用意する
継承のクラス階層を１つのテーブルで表現する方法。ポリモーフィズムも表現でき、パフォーマンスも問題ない。後から具象クラスを追加することが少し難しくなる。具象クラスの数が多いとカラムが多くなり、複雑になる。
また、具象クラスのカラムはNULL許可にしなければならない。
この方法では、どの具象クラスをテーブルのレコードが表すのかを表現するために種別のカラムが必要になる。下記の図では注文決済種別をそのカラム
とする。
以上、３つの継承の実現方法を表にまとめると下記のようになる。
どの方法を選択するかは、そのデータがポリモーフィズムが必要なのかどうか、あるいは具象クラスが追加されるのかどうかで検討する。
概念モデルをもとにER図を作成すると下記の図のようになる。
下記の図では継承の実現方法として「クラス階層ごとに汎用テーブルを作り、さらに型を表すカラムを用意する」を採用している。
ここまでで外部仕様の設計とDBの論理設計が完了した。ここから先はそれをもとに、システムを構成するプログラムをどのように開発するのかを検討する。すなわち、内部設計である。
DB論理設計ではできるだけ正規化されたモデルを作成する必要がある。継承の実現方法によっては冗長になる場合があるが、第３正規形まで行うようにすると良い。
第3章外部設計の手法⑨データベース論理設計を終了します。
次回は⑩NoSQLデータベース設計について記載します。
この記事が気に入ったらサポートをしてみませんか？