WEBデザイン制作講義のシステム設計のER図とデータベース設計

データベース設計※画像クリックで拡大表示

• データベース設計は、
  リレーショナル・データベース（RDB）では、エンティティがテーブル（表）、属性がカラム（列）、検索等の索引がテーブルの主キー（プライマリキー）であり、まずデータベースの論理設計を行います。
• 事例の「コンテンツ共有サイト」では、データベースとして「グループ・エベントマスタ」「メンバーマスタ」「コンテンツデータ」の３つのエンティティを設定しており、その内容に対し、画面で表示する内容や処理内容から必要とする属性を明らかにします。
• 事例の「コンテンツ共有サイト」の論理設計DBをER図で作成すると
  
  となります。

1. 「システム設計のデータフロー設計と画面遷移図」と要件定義書で記述した内容から、「グループ・イベントマスタ」の属性には、「秘密キー」、「タイトル」、「掲載期間」が必要となります。
2. 同様に、「メンバーマスタ」の属性には、ユーザーIDとなる「メールアドレス」、「パスワード」、アップロードロードした「登録者名」が必要で、メンバーの利用状況を考慮すると「ログイン回数」、「有効期間」を追加します。
3. 残る「コンテンツデータ」の属性は、「秘密キー」、写真かビデオかの「コンテンツタイプ」、「撮影メモ」、コンテンツの保存場所のパスである「サムネール画像用」「拡大画像用」「アップロードしたオリジナルファイル」が必要となり、処理内容的に「データ容量」と「ダウンロード回数」を追加します。
4. 各「エンティティ」の属性が決まったので、「秘密キー」のリレーションとしては、「グループ・イベントマスタ」が「１」で「コンテンツデータ」が「０以上」の関係を持ち、「メールアドレス」のリレーションとしては、「メンバーマスタ」が「１」で「コンテンツデータ」が「０以上」の関係を持ちます。
5. リレーショナルデータベース（RDB）のテーブルで一意化するため、各テーブルのID（プライマリキー）が必要となります。

• データベース設計の開発ステージ完了の目安は、
  
  1. 概念DB設計：要件定義ステージで、システム化対象範囲が確定して、必要とするエンティティが明確化されていること。
  2. 論理DB設計：基本設計ステージで、業務システム遂行上必要なデータ項目が明確化されていて、画面・帳票設計との突き合わせが完了していること。
  3. 物理DB設計：詳細設計ステージで、処理性能や利用するDBMS（例えば、MySQL）特性を考慮しており、テーブルの属性やインデックスが明らかになっていること。（実装可能な状態）

物理データベース設計の作業手順

• ネーミングルールの設定は、
  物理名として、テーブルとカラムの名称を設定。
  1. データ項目は、重複をなくして一意化を図る。
  2. 物理名から項目内容が分かるような名称にする。
  3. 複合語の項目名の区切りは、キャメルケース又は、アンダーバーで分かりやすくする。
• テーブルの共通列定義の設計は、
  
  1. 共通列として、各テーブル（エンティティ）で共通となる項目（カラム）で、削除フラグ、登録日、登録者、更新日、更新者などが一般的です。
  2. 削除フラグは、データベースの最適化の一つで、外部キー制約（FK:Foreign Key）の項目に対する削除処理などのトラブルを避けるため、削除処理のときそのレコードを削除するのではなくフラグをセットして、外部キーのレコード整合性を保持します。削除レコードは、バッチ処理等により、一括処理すると良い。リアルタイム処理では、フラグの「１」を立てて更新し、外部キー制約の削除せずにパフォーマンスを高めます。
  3. 登録や更新は、各レコードに対する登録や更新処理時にセットして、レコードごとのタイムスタンプを設けます。登録日、更新日は、処理時のシステム日付（データタイプ：datetime)にし、登録者、更新者はログイン中のIDにします。
• テーブル・ルール設計は、
  
  1. プライマリーキー（PK:Primary Key）は、Nullでなくユニークであることの制約から、テーブル内で一意化するため、レコードの追加ごとに自動的に生成する「auto_increment」を利用することがDB設計を容易にします。
  2. 外部参照キー（FK:Foreign Key）は、ER図上で明確化してテーブルのリレーションを関係を設定しますが、実装のための「DDL出力」時に、FK制約の取り扱いを定め設定するかどうかを決定します。
• ビュー設計は、
  
  1. 「仮想テーブル」とも呼ばれ、テーブルの実データを格納せずにアプリケーションからは、物理テーブルと同じようにアクセスできるものです。
  2. 物理的なテーブル上のカラムを形成せずに、複雑な検索を頻繁に利用する場合や複数のテーブルを組み合わせた論理的テーブルを仮想的に作成する場合などに有効です。
• インデックス設計は、
  
  1. インデックスは、カラムが特定の値をもつレコードの高速検索に使用され、インデックスがないと最初のレコードから開始してテーブル全体を読み取るため、検索が遅くなります。逆に更新処理では、データ部の更新と同時にインデックス部の更新も必要となるため負荷が増大します。
  2. 検索の高度化として、複数のカラムに対するインデックス（複合インデックス）を作成でき、インデックス化されたカラムの値を連結することによって生成された値が含まれるため、ソート化された配列と見なすことができます。
  3. 「MySQL」の場合は、インデックス設定をしなくても自動的に作成されますので、DB設計上ではあまり考慮しなくて良いと思われます。
  4. SQLのEXPLAIN構文を利用すると、より速くレコードを検索するSELECTを得るために、どの時テーブルにインデックスを追加しなければならないかを確認できます。
• 格納構造設計は、
  
  1. 処理のアクセス状況から、データ件数（容量）を見積る必要があります。
     
  2. データ容量は、初期データ量、データ増加率や最大データ容量、保存期間について分析して、テーブル領域、インデックス領域の算出して、データベースの充填率を考慮します。
  3. データ件数が多く競合が発生するケースが多い場合は、パーティショニング・テーブル（分割方式）の実装を考慮する必要があります。
  4. DBの正規化（標準化）図り、セキュリティ面を考慮したテーブル構造の設計を考慮します。