『OSS教科書 OSS-DB Silver Ver.2.0対応』（翔泳社）
こちらの書籍のデータベースの設計についての部分を読んだので、こちらを元にデータベース設計の基本について、学習のアウトプット目的でまとめます。
サービス化（データベース化）する対象世界を０からテーブル作成を行える形にするまでの考え方や手順を順序立てて書いています。
データモデル
データベースを構築する対象の範囲を対象世界と呼びます。
データモデルとは、対象世界をモデル化したものを指します。
データモデルには、対象世界を抽象化した概念データモデルと、その概念データモデルをデータベースで実装可能な形にした論理データモデルがあります。
（後でそれぞれについて具体的にまとめています）
概念データモデルと論理データモデルを作成する手順は次のようになります。
- 対象世界から概念データモデルを抽象化する
- 概念データモデルから論理データモデルに変換する
概念データモデル
概念データモデルは、対象世界を抽象化して、対象世界のデータ構造を概念的に捉えた結果を表現したモデルです。
概念データモデルの作成はERモデル（ER図）で行います。
ERモデルとは、上図右側のような、実体同士を線でつなげた図です。
Entity（実体）とRelationship（関連）によって作成するのでERモデルと呼ばれます。
Entityは、管理対象とするデータの集合体を指します。
Relationshipは、Entity間のつながりを指します。
- 例１）売上の単位で出荷がある場合（売上１に対して出荷が１の場合）：１対１
- 例２）各部門に複数の社員が所属し、社員は１つの部門のみに所属する場合：１対多
- 例３）製品は複数の部品で構成され、同じ部品が複数の製品で利用される場合：多対多
すなわち、概念データモデルとは、対象世界のデータをER図に起こしたものを指します。
この段階ではまだ、特定のデータベースに依存しないため、データベースでテーブルを作成して実装することはできません。
データベースで実装可能にするために論理データモデルに変換します。
論理データモデル
論理データモデルは、データとデータ間の関係を論理的に表したもので、そのままデータベースとして実装可能なデータモデルとなっています。
論理データモデルの種類には、歴史的に「階層モデル」、「ネットワークモデル」、「関係モデル」などがありますが、リレーショナルデータベースシステムでは関係モデルを使います。
関係モデル
関係モデルは、関係（リレーション）と呼ばれる表構造でデータを表現します。（以下画像）
関係モデルの構成要素の名称は次のように呼ばれるようです。
- 行：タプル（組、ロー）
- 列：アトリビュート（属性、カラム）
（個人的に現場では行と列としか聞いたことがないです）
データベース設計
データベース設計は次の手順で行います。
- 概念データモデルを作成する（ER図を作成）
- 導入するデータベースマネジメントシステムに合わせて論理データモデルに変換する（関係モデルを作成）
概念データモデルの作成
最初に、管理対象とするデータを対象世界から抽出し、Entityとして定義します。
抽出するデータは、実体が物理的に存在するデータだけでなく、実体が存在しないデータも含めて検討します。
- 商品、取引先などのように、実体が物理的に存在するデータ（例：部門）
- 売上、出荷などのように、実体が存在しないデータ（例：社員）
概念データモデルを作成する上でポイントとなるのは、「対象世界はどうあるべきか」、「対象世界ではどのようなデータを保持すべきか」という点です。
例えは、「部門」と「社員」のつながりを考えます。
部門を視点とすると、「１つの部門には複数の社員が入るのか」「１人も社員が属していない部門があってもいいのか、よくないのか」など。
社員を視点とすると、「社員は必ずどこかの部門に属すのか、属さなくてもいいのか」「１人の社員は１つの部門にしか属さないのか、複数の部門に属すこともあるのか」など。
論理データモデルへの変換
ER図を作成したら関係モデルに変換します。基本的にER図の１つのEntityが関係モデルの１つの表（関係）に対応します。
ただし、「多対多」のRelationshipがある場合、そのままでは関係モデルとして扱うことはできません。
解消する方法としては、多対多の間に新たなEntity（連関Entity）を作成し、「１対多」と「多対１」のRelationshipにすることで関係モデルを作成します。
正規化
多対多の関係を解消した関係モデルであっても、データベースにそのまま実装すると、データの更新によって、冗長なデータが発生したり、不整合が生じたり、データが失われたりするなど、不整合が発生する場合があります。
データベースに発生する不整合を更新時異常と言います。
更新時異常が発生しないようにするために、関係を正規化します。
更新時異常
登録時
丸山太郎さんが複数回注文すると、丸山太郎さんについて同じ情報を何度も登録しなければならない。
更新時
丸山太郎さんが新宿区神楽坂から中央区日本橋へ転居した場合に顧客住所の更新漏れが発生するとデータの不整合になる。
削除時
丸山太郎さんが注文を取り消した時に売上情報を削除すると、丸山太郎さんの情報そのものも削除されてしまう。
候補キーと主キー
正規化を行うときは主キーを決める必要があります。
主キーを決めるには、まず候補キーを明確にします。候補キーとは、行を一意に識別できる単独の属性、もしくは必要最小限の属性の集合です。
主キーにはNULLを含めることができません。（NOT NULL制約）
非キー属性
非キー属性とは、いずれの候補キーにも含まれない属性です。
関数従属
正規化を行うには、関数従属という性質に注目します。
関数従属は属性間の性質で、Xの値が決まれば別の属性Yの値がただ１つ決まる場合、「属性Yは属性Xに関数従属する」と言います。
非正規形
第一正規形
第二正規形
第三正規形
ボイスコッド正規形
