各工程の中でどこまでのデータベース設計を実施するべきかを明確に意識できるよう設計内容をまとめる。
役割
DB設計はソフトウェア開発においてデータベースモデルを作成する作業である。
各工程において以下を設計する。
■要件定義：概念データモデル
■基本設計：論理データモデル
■詳細設計：詳細データモデル
要件定義
データモデルはITの知識がないと難しいため、SEがベース案を作るべきであるが、成果物のレベル感（やり過ぎ、やらなさ過ぎ）には注意が必要である。業務フローを分析した結果抽出されたデータを漏れなく捕捉するイメージである。
概念データモデルの作成
①概念データモデル図の作成
・静的なビジネスの全体像を把握することが目的である
・データモデルの抽出 静的な管理対象を5W1Hで抽出
※モデル例 ・・・ 「顧客」「社員」「店舗」「注文履歴」
・データの種類、主な項目を捉える。モデルだけだとわかった気になるが、バリエーションや範囲などの議論に至らず考慮モレが発生しやすくなるため注意すること。
②データディクショナリの作成
・ER図を作成する過程で出てきた項目を名前や意味を整理する。
・ホノニム（同音異議）、シノニム（異音同義）の標準化、データの範囲を定義する。
基本設計
DOA(Data Oriented Approach)の思想をベースに正規化技法を用いてデータモデルを整理する。
論理データモデルを作成する
①ER図の作成
①-1 エンティティの作成・正規化
・要件定義で補足したデータを整理・統合し、エンティティを作成する。
（四角形の形 角あり→独立エンティティ 角丸→依存エンティティ）
・抽出したエンティティを元に、属性(attribute)を決める。
・補助ツールを使うと便利
（私はこれを使わせてもらっています。https://a5m2.mmatsubara.com/）
①-2 正規化
目的：データの重複をなくし整合性をもってデータを取り扱えるようにデータベースを設計すること
第一正規形：繰返しのデータ項目の組などの集合体を分離する
第二正規形：キーの従属関係を洗い出し、部分従属な関係を分離する
→明細テーブルに分割する場合がこのパターンがよくある
第三正規形：キー以外の従属関係を洗い出し、キー以外の全ての項目がキーに完全従属するように
従属関係を分離する。また複数のエンティティから類似の正規系グループが発生した
時には統合を検討する。
②最適化作業
リレーションを意識し、エンティティを見直すことで重複するデータを排除するとともに、業務ルールやプロセスを確認する。
③一般化作業
データベース構造をビジネス視点から見直す→ビジネス視点でのエンティティの分離
④安定性検証作業
変化に強いデータ構造の目線で検証（ビジネスルールが変わったときに耐えられるか）
詳細設計
論理データモデルを実際のDBMSを使用することを前提に、物理の構造とアクセス方法を決定する。
物理データモデルを作成する
①表内と表間の定義
①-1 カラム設計
名称、データ型、長さ、空白値（NULL値）の扱い、ドメイン（定義域）設計
①-2 参照制約の定義
②セキュリティの設定
・ビューの作成（データの安全を保護）
・ユーザごとに利用可能な表やアクションを制限
③性能向上のための構造定義
③-1 パフォーマンス考慮
・インデックス設定
カーディナリティ（カラムのデータ種類）が低い項目にインデックスを作成しても使われない可能性が高い
レコードを大量に追加、削除すると→インデックスが変わる
・非正規化（テーブルアクセスの観点から）
③-2 DBアクセス設計
・コミットのタイミング
・排他制御
・デッドロックの回避→ロックの順番を決めておく
④データの移行設計
レガシーシステムがある場合は検討する
RDBMSへの実装
①データベースアクセスはライブラリなどを提供し共通化する。
CONNECT,DISCONNECT,COMMIT,ROLLBACK
②データ操作命令はSQL文を利用する
■オプティマイザの仕様
Oracleは10g以降ルールベースはなく、コストベースオプティマイザのみサポートされる
（データ件数、偏り、分布を加味してSQLを最適化している）
■NULLのソート順→DBMS次第
Oracleの場合 order by（昇順）にするとNULLは先頭 order by オプション NULLS FIRSTで制御可能である。