ITパスポート 2014年 春期 問83

関係データベースの構築工程の実行順序【ITパスポート 解説】

正解の理由

• 関係データベース（relational database）：データを「表（テーブル）」で管理する仕組みです。表は行（レコード）と列（属性・カラム）で構成されます。
• 表（テーブル）：同じ種類のデータをまとめたもの。例えば「顧客」テーブルは顧客ごとの情報を行で持ち、列は「氏名」「住所」など。
• 業務分析：業務の流れやルール、誰が何をするかを整理すること。これが設計の出発点になります。

解法ステップ

1. 業務分析を行う（b）
   • まず業務の目的・流れ・関係者を整理します。
   • どの業務で何を入力し、何が出力されるのかを明確にします。
   • 例：受注 → 出荷 → 請求 の流れを図にする。
2. 管理するデータ項目を洗い出す（a）
   • 業務で必要となるデータを列挙します（顧客名、商品コード、数量、単価、日付など）。
   • データをグループ化して「エンティティ（表になりうるまとまり）」を決めます。
   • ER図（Entity-Relationship図：要素間の関係を図にしたもの）を描いて、関係性を確認します。
3. 表（テーブル）を作成する（c）
   • 洗い出したデータ項目に基づいてテーブルを設計します。
   • 主キー（Primary Key：レコードを一意に識別する列）や外部キー（Foreign Key：他テーブルとの対応を示す列）を決めます。
   • 必要に応じて正規化（データの重複を避け、整合性を高める設計）を行います。
4. 実装と検証
   • SQLなどでテーブルを作成し、サンプルデータで業務が正しく動くか確認します。

選択肢別の誤答解説

• ア: a → b → c
  データ項目を先に洗い出してから業務を分析する流れです。業務の全体像を知らずに項目を列挙すると、重要な項目を見落としたり、不要な項目を含めたりしてしまいます。結果的に設計のやり直しが発生します。
• イ: b → a → c
  正解。業務を理解してから必要なデータを決め、最後にテーブル化します。設計の効率と品質が最も良くなります。
• ウ: b → c → a
  業務を分析した後にすぐ表を作り、その後でデータ項目を洗い出す順です。表を先に作ると、あとから追加する項目でテーブル構造が崩れやすく、手戻りが多くなります。
• エ: c → a → b
  最も不適切です。表（テーブル）を先に作ると、業務の要件と合わない設計になり、システムが実際の業務に合致しません。

よくある誤解

1. 「とりあえず表を作れば進むだろう」
   表を先に作ると、一見早く進んだように見えますが、業務要件に合わない設計を後で直すコストが大きくなります。最初に業務を把握することが重要です。
2. 「データ項目の洗い出しは単なる列挙でいい」
   単に項目名を並べるだけでは不十分です。どの項目がどのエンティティに属するか、同じ意味の項目が複数ないか、キーは何か、という視点で整理する必要があります。
3. 「正規化は面倒だから省略してよい」
   正規化（データの重複をなくす設計）は後のデータ不整合や更新の手間を減らします。小規模でも基本は押さえておくべきです。

補足コラム

• ER図（Entity-Relationship図）は、業務分析結果を設計に落とすのに非常に役立ちます。エンティティ（顧客・商品・注文など）を箱で表し、それらの関係（1対多、多対多）を線で表します。
• 正規化の簡単なイメージ：
  • 1NF（第1正規形）：各セルに単一の値を入れる（複数値を避ける）。
  • 2NF〜3NF：関連するデータを別テーブルに分け、重複を減らす。
  • 例：注文情報に「顧客住所」を繰り返し入れるのではなく、顧客テーブルにまとめ、注文テーブルから参照する（外部キーを使う）。
• 簡単なSQL例（テーブル作成イメージ）：

  CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    address VARCHAR(200)
  );
  
  CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
  );
  

FAQ