DB設計基礎

データベースの設計

データベース設計とは,データベースによってデータを管理できるように,現実の世界を抽象化してデータモデルを作成していく作業である。データモデルはデータベースをどのように構成するかということを定義したものである。

優れたデータベースを構築するためには、設計段階からデータの構成を工夫しなければならない。効率的なデータベースを設計するための方法論として、「正規化」という概念が存在する。また、この「正規化」の基本概念となるものに ER モデルというものがある。

データモデルを作成していく作業(データモデリング)は,一般的に概念設計,論理設計,物理設計という3つの段階を通して行われる。そして,それぞれの段階ではアウトプットとして概念モデル,論理モデル,物理モデルが作成される。

概念モデル

概念設計では,データベースによって管理の対象とするものを現実の世界から抽出して概念モデルを作成する。概念モデルは,最終的にリレーショナルデータベースでデータを管理するとしても,特定のデータモデルを意識して作成するものではない。

概念モデルの作成にあたっては,ERモデル(実体参照モデル)がよく使用される。ERモデルでは,その名のとおり,実体(エンティティ)と関連(リレーションシップ)によってモデルを作成していく。実体は現実の世界を構成する実体そのもの,関連は実体間のつながりを表現する。また,実体や関連は属性(アトリビュート)を持つことができる。

論理設計

論理設計では,概念設計によって作成された概念モデルを,特定のデータモデルに対応した論理モデルに変換する。したがって,リレーショナルデータベースによってデータを管理するのであれば,ERモデルからリレーショナルモデルを作成する。ERモデルからリレーショナルモデル,つまり,テーブル(リレーション)への変換は機械的に行うことができる。しかし,そのままテーブルに変換しただけでは,リレーショナルモデルとして適切な形式にならない場合がある。

そこで,論理設計ではテーブルをリレーショナルモデルとして適切な形式に変換する作業(正規化)を行う。テーブルを正規化することによってデータの冗長性や不整合の発生を減少させることができる。また,論理設計では,ERモデルにおける属性をテーブルの列としてデータ型を決定し,テーブルや列に対して制約を定義するといったことも,この段階において行う。

物理設計

物理設計の段階になって初めてデータベースとしての性能について考慮する。具体的には,論理設計において正規化したテーブルの定義を崩したり,インデックスを定義したりして性能が向上するようにモデルを修正していく。また,物理設計では使用するデータベースに依存する機能を使用することもある。

物理設計によって修正されたモデルを物理モデルと呼び,このモデルをもって実際にデータベースによって管理することができる形式となる。

ERモデル

実世界に存在するものの中で、データベースとして表現すべき対象物をエンティティ (entity:実体) と呼ぶ。また、エンティティとエンティティの相互関係をリレーションシップ (relationship:関連) と呼ぶ。そして、この関係を図示し、エンティティとエンティティの間のリレーションシップを分析する技法を ER(Entity-Relationship) モデルという。

エンティティとエンティティのリレーションシップには、次のような対応関係がある。

1:1
エンティティ A に対して、エンティティ B は一つしか存在しなくて、エンティティ B に対してもエンティティ A は一つしか存在しないようなリレーションシップの場合、1:1 の対応であるという。例えば、エンティティ「学生」とエンティティ「学生番号」のリレーションシップは 1:1 である。

1:N
エンティティ A に対して、エンティティ B が複数存在し、エンティティ B に対してはエンティティ A が一つしか存在しないようなリレーションシップの場合、1:N の対応であるという。例えば、エンティティ「父親」とエンティティ「子」のリレーションシップは 1:N です。

M:N
エンティティ A に対して、エンティティ B が複数存在し、エンティティ B に対してもエンティティ A が複数存在するようなリレーションシップの場合、M:N の対応であるという。例えば、エンティティ「講義」とエンティティ「受講生」のリレーションシップは M:N である。

正規化

正規化とは、実世界の事象や情報を、データベース上で効率よく利用できるようにモデル化することや、その手順のことを言う。リレーショナル型データベースでは、複雑なテーブルを特定の規則に従って単純なテーブルに分割することが正規化であるといえる。

まだ正規化されていないものを非正規形、正規化されたものを正規形という。正規形には、正規化の程度により、第一正規形から第五正規形まである。ほとんどの場合、第三正規形まで正規化すれば的確な正規化がなされたとしてよいとされている。ここでも第三正規形までについて説明する。

・関数従属性
ある列の値 X が決まると同時に、別の列の値 Y が自動的に決まるとき、Y は X に関数従属であるという。Y が X に関数従属であるとき、X → Y と表記する。

・推移的関数従属性
ある関数従属関係から、新たな関数従属関係が得られるような場合、推移的関数従属性を持つという。X → Y 及び Y → Z の関係があるとき、X → Z は推移的関数従属性を持つ。次に、それぞれの正規形について説明する。

・非正規形
全く正規化が行われていない状態のテーブルをいう。ER モデルの説明に用いた受注伝票を 1つのテーブルにしたものは、非正規形のテーブルである。
f:id:wanwan_bowbow_ilovecat:20181012122727g:plain
商品番号から合計金額の部分は、あと 4つ右へ続いているものとする。このように、非正規形のテーブルは非常に大きなものになり、同じ列が何度も繰り返される。この例の場合は、商品番号〜合計金額の部分が 5つあることになる。


・第一正規形
非正規形のテーブルを、繰り返し現れる列がない状態にしたものをいう。列を固定部分と繰り返し部分にグループ化し、固定部分と繰り返し部分をキーを用いて連結することをいう。
f:id:wanwan_bowbow_ilovecat:20181012122631g:plain
繰り返し部分を切り離して別のテーブルにする。ただし、そのまま切り離したのでは、受注番号と商品の関係などが不明になるので、受注番号と商品番号を連結キーとして分離する。分離したテーブルは上記のようになる。


・第二正規形
主キーとなる列の値が決まれば、他の列の値が決まるようにテーブルを分割した状態をいう。関数従属関係のある部分は、別テーブルに分割するということである。
f:id:wanwan_bowbow_ilovecat:20181012122647g:plain
第二正規形を作成するには、関数従属性を満たすテーブルに分割する必要がある。第一正規形の上のテーブルでは、受注番号→受注日、顧客名、顧客住所という関数従属関係が成立しているので、第二正規形の条件を満たしている。
次に下のテーブルについて、合計金額は単価と数量から計算されるものなので、この時点で取り除く。すると、(受注番号、商品番号) →数量、(商品番号) →商品名、単価という二つの関数従属関係が存在することがわかる。

第一正規形の場合は、主キー (受注番号、商品番号) の一部 (商品番号) により、商品名と単価が決まっている。このようなとき、商品名と単価は、主キーに対して部分関数従属しているという。第二正規形では、このような部分関数従属関係をなくすようにする。


・第三正規形
主キーとなる列以外の値によって、他の非主キー列の値が決まることがない状態にテーブルを分割した状態をいう。推移的関数従属関係である部分を、別テーブルに分割するということである。
f:id:wanwan_bowbow_ilovecat:20181012122659g:plain
第二正規形のテーブルのうち、一番上のテーブルを分割する。このテーブルでは、受注番号→顧客名、顧客名→顧客住所となっており、受注番号→顧客住所は推移的関数従属関係を形成している。よって、このような部分を別テーブルとする。真中のテーブル、一番下のテーブルは、推移的関数従属関係は持たないため、分割の必要はない。

正規化のメリット

・データ管理の容易化
データに変更の必要が生じたときに、変更する手間が大幅に削減される。
・データの部品化
正規化されたデータは他のシステムで利用できる可能性が高まる。
・データ容量の削減
データの関係を明確にすることにより、無駄な列を削除することができる。その結果、データ処理の効率も上がる。

正規化はデータベース設計には欠かせない概念である。しかし、正規化すれば必ず優れたデータベースになるとは限らない。正規化することにより、テーブルの数が増える。これにより検索などでテーブルを結合する場合は、その処理が複雑になることにより、パフォーマンスが低下する可能性もある。正規化することにより生ずるメリットと、デメリットのバランスを考えて正規化することが大切だ。

とはいっても、正規化によるメリットは、データの関係を明らかにすることにより生じる。ですから、パフォーマンスのことを考えて、正規化を最後までしないということではなく、正規化したものを、状況に応じて崩すという考え方が大切だ。