【データベース】物理の仕事は最後のお楽しみ！「データベース概念設計」｜情報処理問題1000本ノック
システム開発における「データベース設計」。顧客のビジネス要件をデータモデルとして落とし込んでいく際、どのフェーズで何の作業を行うかという役割分担を正しく見極める問題を攻略しましょう。
1. 【 問題 】：データベース（データモデリング・データベース設計フェーズ）
【 問題 】 データベース設計のプロセスに関する記述です。業務要件をもとに、特定のデータベース管理システム（DBMS）の種類やハードウェアの制約に依存しない、業務データの全体像や関係性をモデル化する「概念設計」の作業として、最もふさわしくないもの（別の設計フェーズの作業であるもの）はどれでしょうか？
（ア）業務に必要なエンティティ（実体）を抽出する
（イ）パフォーマンス向上のための物理的なアクセスパス（インデックス等）を決定する
（ウ）現行システムで扱われているデータベースや帳票のデータ構造を分析する
（エ）表記の揺れを防ぐため、データ項目（属性）の名称や意味の標準化を行う
2. 正解：
正解：（イ）物理的なアクセスパスを決定する
3. 解説：「頭の中の整理（概念）」から「マシンの設定（物理）」へ
データベース設計は、抽象度の高いものから具体的なものへと、以下の3段階のステップを踏んで進められます。
問題となっている「概念設計」は最初のステップであり、特定のDBMS製品の仕様や、サーバーの性能といった「物理的な都合」は一切無視して進めるのが最大のルールです。そのため、アクセス速度を上げるためのルート決めである「（イ）物理的なアクセスパスの決定（インデックス設計やデータ配置）」は、最終段階の「物理設計」で行うべき作業であり、概念設計の段階で行うのは不適切です。
| 設計フェーズ | 設計の目的とアプローチ | 具体的な作業・成果物の例 |
|---|---|---|
| ① 概念設計 | 業務の観点からデータの全体像を把握する（DBMSやハードウェアは無視）。 | ・エンティティの抽出 ・E-R図の作成 ・データ項目の標準化 |
| ② 論理設計 | 概念モデルを、リレーショナルDBなどの「データモデル」に適した形に変換する。 | ・テーブルの定義（属性の決定） ・データの正規化（第1〜第3） ・主キーや外部キーの定義 |
| ③ 物理設計 | 特定のDBMSやハードウェアの仕様に合わせて、実装レベルの設定を行う。 | ・（設問のケース）アクセスパスの決定 ・インデックスの設計 ・テーブル容量の計算・配置場所決定 |
1. 理解のコツ: 「一戸建てのマイホーム作り」に例えてみましょう。
・最初の段階は「概念設計」です。ここでは家族で話し合って「リビングは広くしたい（エンティティ抽出）」「子供部屋は2つ必要」といった『理想の生活のカタチ』だけを考えます。このとき、現行の古い家（現行DB）の不満を分析したり、家族間で言葉の定義（データ項目の標準化）を合わせたりします。
・次の段階が「論理設計」で、建築士が間取り図（テーブル定義）を作成し、無駄のない動線（正規化）に整えます。
・最後の段階が「物理設計」です。ここでようやく「壁の中にどんな断熱材を入れるか」「コンクリートの強度はどうするか（物理的なアクセスパスの決定）」という、大工さんやマシン目線の具体的な工事仕様を決めていきます。まだどんな家にするかの全体像（概念）を話し合っている最初の会議で、いきなり「釘の長さをどうするか」を決めるのはナンセンスですよね。だから（イ）は仲間外れになります。
2. 試験対策の視点: データベース分野における、午前・午後試験ともに超・頻出の区分問題です。問題文の形式として「概念設計として正しいものはどれか」または今回のように「ふさわしくないものはどれか」というパターンで出題されます。
見分ける最大のコツは、選択肢の中に「物理」「パフォーマンス（速度）」「インデックス」「容量（サイズ）」「格納構造」といった、ハードウェアやDBMSの生々しいスペックを感じさせるキーワードが入っているかどうかです。これらが入っていれば100%「物理設計」の作業ですので、概念設計の網の目から一発で弾き出すことができるようになり、確実な得点源になります。
4. まとめ
「データベースの概念設計は、業務要件からデータの構造や関係性を浮き彫りにするフェーズであり、マシンの性能やデータへのアクセスルートを決定する『物理的な作業』は一切含まない」。この明確な境界線と3つの設計ステップの順番（概念→論理→物理）を、しっかりと記憶に定着させておきましょう！