戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

応用情報技術者 2009年 秋期 午後 問06


旅行業務用データベースの設計に関する次の記述を読んで、設問1~3に答えよ。

   旅行会社であるZ社では、四半期ごとにパッケージツアー(以下、ツアーという)の計画を作成し、発売開始後、申込みを受け付ける。Z社には、本社のほかに、地域ごとに支店があり、ツアーの申込みは、インターネットと支店店頭の両方で行える。また、ツアーの申込みに関するデータは、本社のデータベースで一括して管理する。   〔ツアー〕  ・ツアーにはツアーコードが付されている。ツアーの内容が同じであれば、出発日が異なってもツアーコードは同じであるが、日数が異なればツアーコードは異なる。  ・ツアーは、ツアーコードが同じでも、出発日によって価格が異なることがある。   〔ツアーに関する業務〕  ・ツアーの申込みを受け付けたときには、申込番号、申込者の顧客番号、申込日、申し込んだツアーのツアーコード、そのツアーの出発日、参加人数を登録する。新規の顧客の場合には顧客番号を新たに設定し、顧客の氏名、住所、郵便番号、電話番号、電子メールアドレスを登録する。  ・ツアーを申し込んだ顧客には、店頭での申込みかインターネットからの申込みかにかかわらず、それ以降、支店から四半期ごとにツアーなどに関する情報をダイレクトメールで送付する。顧客を担当する支店は、顧客の郵便番号によって決めている。発送は、その時点で担当となっている支店が行う。なお、支店間の業務量の均等化のために、担当範囲を随時見直すことにしている。   〔データベースの設計〕  ・E-R図を作成してテーブル設計を行った結果、ツアーテーブル、申込みテーブル、顧客テーブル、支店テーブルの四つのテーブルから成るデータベースを作成することにした。  ・E-R図を図1に、設計したテーブルを表1に示す。なお、表1において、下線の引かれた列名は、主キーである。
応用情報技術者試験(平成21年度 秋期 午後 問06 図01) ↩設問3
〔データベースの運用〕  ・ツアーテーブルには、四半期ごとにその期のツアー商品を追加する。当該四半期の間にツアーテーブルの内容が変更されることはない。  ・ツアーの申込みを受け付けるごとに、申込みテーブルに行を1件追加する。申込番号は、ツアーの申込み1件ごとに設定する。   〔正規化に関する検討〕  ツアーテーブルの非キー属性の中には、候補キーに完全関数従属していない属性が存在するので、ツアーテーブルは第二正規形ではない。すなわち、非キー属性であるaとbが、候補キーの一部であるcだけに関数従属している。  顧客テーブルの非キー属性の中には、ほかの非キー属性を介して候補キーに関数従属(推移関数従属)している属性があるので、顧客テーブルは第三正規形ではない。具体的には、非キー属性であるdは、やはり非キー属性であるeに関数従属している。ただし、Z社では、入力間違いなどの可能性を考慮し、顧客テーブルの郵便番号は住所に関数従属しないものと考えている。

設問1:

問題文を見る
本文中のa〜eに入れる適切な字句を解答群の中から選び、記号で答えよ(aとbは順不同)。
解答群  ア:価格  イ:顧客番号  ウ:氏名  エ:住所  オ:出発日  カ:担当支店コード  キ:ツアーコード  ク:ツアー名称  ケ:電子メールアドレス  コ:電話番号  サ:日数  シ:郵便番号

模範解答

a:サ b:ク c:キ d:カ e:シ

解説

解答の論理構成

  1. ツアーテーブルの候補キー
    【問題文】では「ツアーテーブル」の主キーが「ツアーコード、出発日」であると明示されており、これは複合キーです。
  2. 第二正規形の条件確認
    第二正規形にするには「非キー属性が候補キーの全項目に完全関数従属」していなければなりません。
  3. 非キー属性ごとの依存関係を整理
    • 「ツアーコード」が同じでも「出発日」によって「価格」が変わる → 「価格」は「ツアーコード」「出発日」の両方に依存。
    • 「ツアーコード」が同じなら「日数」「ツアー名称」は変わらない → 両者は「ツアーコード」のみに依存。
      したがって「日数」「ツアー名称」が部分関数従属に該当し、【問題文】の
      「非キー属性であるaとbが、候補キーの一部であるcだけに関数従属している」
      に当てはまります。
      ・a=「日数」(サ)
      ・b=「ツアー名称」(ク)
      ・c=「ツアーコード」(キ)
      (※aとbは順不同なので逆でも正解)
  4. 顧客テーブルの第三正規形違反を確認
    【問題文】では「顧客を担当する支店は、顧客の郵便番号によって決めている」とあります。これは
    「郵便番号」→「担当支店コード」
    の関数従属を意味します。さらに「顧客番号」→「郵便番号」であるため、 「顧客番号」→「郵便番号」→「担当支店コード」
    となり、「担当支店コード」は候補キーである「顧客番号」に対して推移的に関数従属します。
    よって
    ・d=「担当支店コード」(カ)
    ・e=「郵便番号」(シ)

誤りやすいポイント

  • 「価格」は出発日により変動するので部分関数従属ではないことを見落としやすい。
  • 「郵便番号→住所」と思い込み、「住所」がeだと誤答するケースが多い。問題文には「郵便番号は住所に関数従属しないものと考えている」と明記されている。
  • E-R図の矢印に気を取られ、論点が正規化であることを忘れると判断がブレやすい。

FAQ

Q: 「日数」と「ツアー名称」のどちらが a でも良いのですか?
A: はい。【問題文】に「aとbは順不同」と指示があるため、どちらをa・bにしても正解です。
Q: 「担当支店コード」が主キーでないのに推移的従属になるのはなぜ?
A: 第三正規形の条件は「主キー以外の非キー属性が他の非キー属性に依存しない」ことです。「担当支店コード」は非キー属性なので、「郵便番号」に依存している時点で推移的従属となります。
Q: 「住所」は郵便番号から決まるのでは?
A: 問題文に「入力間違いなどの可能性を考慮し、顧客テーブルの郵便番号は住所に関数従属しないものと考えている」と書かれているため、今回は従属関係がないものとして扱います。

関連キーワード: 正規化、第二正規形、推移的関数従属、候補キー、部分関数従属

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:正規化に関する検討について、(1)〜(3)に答えよ。

問題文を見る
(1)テーブルが第二正規形ではない場合、一般的には様々な問題が発生する可能性がある。しかし、ツアーテーブルの場合にはそのような問題は発生しないと考えられる。その理由を、本文の記述に照らし合わせて35字以内で述べよ。

模範解答

ツアーテーブルに追加された行がその後変更されることはないから

解説

解答の論理構成

  1. 問題文は、ツアーテーブルが第二正規形ではない理由として「非キー属性であるaとbが、候補キーの一部であるcだけに関数従属している」と述べています。これは複合キーの一部に対する部分関数従属であり、通常は更新・挿入・削除異常の原因になります。
  2. ところが「データベースの運用」において、ツアーテーブルについて「ツアーテーブルには、四半期ごとにその期のツアー商品を追加する。当該四半期の間にツアーテーブルの内容が変更されることはない。」と明言されています。
  3. 行が“追加のみ”で“更新・削除をしない”運用であれば、第二正規形に満たないことによる更新異常は発生しません。
  4. したがって、「ツアーテーブルに追加された行がその後変更されることはないから」という解答になります。

誤りやすいポイント

  • 「常に正規化しなければならない」と思い込み、運用ポリシーを無視してしまう。
  • 「変更されない」という文を読み落とし、通常の更新異常リスクをそのまま当てはめてしまう。
  • 部分関数従属=必ず問題、と短絡的に判断し、実際のビジネスルール(追加のみ)と結び付けられない。

FAQ

Q: 第二正規形にしなくても本当に問題は起きませんか?
A: 運用が「追加のみ」で「更新・削除を行わない」限り、部分関数従属による更新異常は生じません。運用変更時には再検討が必要です。
Q: 追加専用テーブルでも正規化するべきでは?
A: 保守性・将来拡張を考えると正規化は望ましいですが、本問では四半期ごとに固定化される性質を優先し、性能や設計工数を抑える判断と読めます。
Q: 部分関数従属と推移的関数従属の違いは何ですか?
A: 部分関数従属は「複合キーの一部にのみ依存」、推移的関数従属は「非キーが別の非キーを介してキーに依存」する状態です。

関連キーワード: 第二正規形、部分関数従属、更新異常、データ冗長性、運用ポリシー

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:正規化に関する検討について、(1)〜(3)に答えよ。

問題文を見る
(2)顧客テーブルが第三正規形でないために発生する問題を、本文の記述に照らし合わせて60字以内で述べよ。

模範解答

支店の担当範囲が変更されると、顧客テーブルの該当するすべての行の担当支店コードを修正しなければならない。

解説

解答の論理構成

  1. 顧客テーブルの主キーは「顧客番号」であり、非キー属性に「郵便番号」と「担当支店コード」が存在します。
  2. 本文には、顧客を担当する支店は「顧客の郵便番号によって決めている」とあります。したがって「担当支店コード」は「郵便番号」に関数従属します。
  3. さらに「郵便番号」は主キー「顧客番号」に関数従属するので、「担当支店コード」は主キーに対して推移的に関数従属していることになります。これは第三正規形の条件(非キー属性は候補キーに対して推移的依存を持たない)に違反します。
  4. 本文には「担当範囲を随時見直す」とあるため、郵便番号と支店の対応が変わることがあります。このとき、「顧客テーブル」の複数行に同じ「郵便番号」が記録されていると、紐づく「担当支店コード」もすべて更新する必要が生じます。
  5. 以上より、第三正規形を満たしていないと更新負荷が集中する更新異常が発生し、「支店の担当範囲が変更されると、顧客テーブルの該当するすべての行の担当支店コードを修正しなければならない。」という模範解答に至ります。

誤りやすいポイント

  • 「郵便番号→担当支店コード」の依存を見落とし、主キー依存だと勘違いする。
  • 「担当範囲を随時見直す」記述を読み飛ばし、更新異常のリスクを具体的に想像できない。
  • “第二正規形”と“第三正規形”の条件を混同し、部分関数従属と推移的関数従属を区別できない。

FAQ

Q: 「郵便番号」も非キー属性ですが、なぜ問題になるのですか?
A: 非キー属性同士の依存(郵便番号→担当支店コード)が存在し、推移的関数従属が発生しているためです。
Q: どう修正すれば第三正規形になりますか?
A: 「郵便番号」「担当支店コード」を分離し、郵便番号をキーとした別テーブルを設けることで推移的依存を排除できます。
Q: 更新異常が放置されるとどんな実害がありますか?
A: 支店範囲変更時に一部行の更新漏れが発生し、誤った支店からダイレクトメールが送付されるなどサービス品質が低下します。

関連キーワード: 更新異常、推移的関数従属、第三正規形、正規化、関数従属

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:正規化に関する検討について、(1)〜(3)に答えよ。

問題文を見る
(3)顧客テーブルを第三正規形になるように分解せよ。新規に追加するテーブルには適切なテーブル名を付け、表1に倣って列名を記述し、主キーを示す下線を引くこと。

模範解答

テーブル名:列名 顧客:顧客番号、氏名、住所、郵便番号、電話番号、電子メールアドレス 担当支店:郵便番号、担当支店コード

解説

解答の論理構成

  1. 依存関係の確認
    問題文には、 ・「顧客を担当する支店は、顧客の郵便番号によって決めている。」
    ・「顧客テーブルの非キー属性の中には、ほかの非キー属性を介して候補キーに関数従属(推移関数従属)している属性がある」
    とあり、さらに
    ・「非キー属性であるdは、やはり非キー属性であるeに関数従属している。」
    と示されています。
    ここでd=「担当支店コード」、e=「郵便番号」であることは、顧客テーブル中で唯一“支店”を示す列が「担当支店コード」であり、その決定要因が「郵便番号」だと述べられていることから分かります。
  2. 推移的関数従属の特定
    顧客テーブルの主キーは「顧客番号」。したがって
    「顧客番号」 → 「郵便番号」 → 「担当支店コード」
    という推移的関数従属が存在し、第三正規形(3NF)を満たしません。
  3. 分解方針
    第三正規形では「非キー属性は候補キーに対して推移的に従属してはならない」ため、 「郵便番号」→「担当支店コード」の依存関係を独立テーブルに切り出します。
  4. 分解後のテーブル
    【顧客】
    顧客番号、氏名、住所、郵便番号、電話番号、電子メールアドレス
    【担当支店】
    郵便番号、担当支店コード
    これにより、顧客テーブルは
    ・主キー「顧客番号」→残るすべての非キー属性
    のみとなり、推移的依存が取り除かれて第三正規形が達成されます。

誤りやすいポイント

  • 「住所が同じなら郵便番号が同じ」と思い込み、郵便番号→住所と逆方向の依存を設定してしまう。問題文には「入力間違いなどの可能性を考慮し、顧客テーブルの郵便番号は住所に関数従属しない」と明記されています。
  • 「担当支店コード」を主キーにしたくなるが、問題文は「顧客を担当する支店は、顧客の郵便番号によって決めている」と述べており、郵便番号が決定属性です。
  • 顧客テーブルから「郵便番号」まで削除してしまうと、顧客の住所情報とDM送付業務に支障が出るため、郵便番号は顧客テーブルに残す必要があります。

FAQ

Q: 将来、郵便番号と担当支店コードの対応が変わった場合はどう扱いますか?
A: 「担当支店」テーブルの該当行を更新するだけで済み、顧客テーブルの行を個別に更新する必要がありません。これが正規化の更新容易性です。
Q: 「担当支店」テーブルに支店名を入れなくてもよいのですか?
A: 支店名は「支店」テーブルに保持されており、「担当支店コード」で参照できます。同じ列を二重に持たせないことでデータの整合性を保ちます。

関連キーワード: 正規化、第三正規形、推移的関数従属、主キー、データベース設計

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

現在の設計では、ツアーに参加した人全員の情報をデータベースに保持しているわけではないので、参加者全員にダイレクトメールを送ることはできない。そこで、それぞれのツアーの参加者全員の情報をデータベースに格納することを検討する。そのために、図1のE-R図にエンティティを一つ追加する。また、それに従って、申込者に加えて全参加者の情報を顧客テーブルに格納するとともに、新たなテーブルを追加して、申込番号ごとに、そのツアーに参加するすべての顧客の顧客番号を保持するようにする。  これを実現するために、図1に対して、適切な名称を付したエンティティを追加し、リレーションシップを記入せよ。

模範解答

(図を参照) 応用情報技術者試験(平成21年度 秋期 午後 問06 設問03 解答)

解説

解答の論理構成

  1. 現状把握
    • 【問題文】では「現在の設計では、ツアーに参加した人全員の情報をデータベースに保持しているわけではない」と明言されています。
    • 申込みテーブルには「申込番号」「参加人数」しかなく、誰が参加したかは「申込者の顧客番号」しか残りません。
  2. 必要要件の整理
    • 同じ【問題文】に「申込番号ごとに、そのツアーに参加するすべての顧客の顧客番号を保持するようにする」とあり、かつ「顧客テーブルに格納」と指示があります。
    • つまり「顧客」と「申込み」の間に多対多の関連が存在すると認識できます。
      • 1回の申込み(申込番号)に対し複数の顧客が参加する。
      • 1人の顧客は複数回の申込みに参加し得る。
  3. E-R図での解決策
    • 多対多の関係は連結エンティティ(中間テーブル)で表現するのが定石です。
    • 連結エンティティには実体名と主キーを与える必要があります。業務的に自然かつ読解しやすい名称として「参加」を採用。
    • 「参加」は
      • 主キー:申込番号+顧客番号(両方下線)
      • 外部キー:申込番号 → 申込みテーブル、顧客番号 → 顧客テーブル
    • これにより
      • 「顧客」→「参加」:1対多
      • 「申込み」→「参加」:1対多
      • 間接的に「顧客」と「申込み」は多対多となります。
  4. 模範解答との一致
    • 公開された模範図には左下に境界線の太い矩形「参加」が追加され、太線の矢印(多対多を分解した1対多の連結)で「顧客」「申込み」に接続されています。
    • これが上記論理と完全に合致するため、解答は「参加」エンティティの追加と両リレーション設定で確定します。

誤りやすいポイント

  • 「参加人数」列を分割して人数分の行を生成すれば良いと誤解し、中間エンティティを作らない。→ 顧客ごとの属性が付けられなくなり失敗します。
  • 「ツアー」と「顧客」の間に直接多対多を設定してしまう。→【問題文】は「申込番号ごとに」保持すると明確なので階層を飛ばすと要件違反です。
  • 連結エンティティ名を業務用語(例:「明細」など)にしてしまい、試験官に伝わりにくくする。名称は業務内容を表す「参加」が最適です。

FAQ

Q: 連結エンティティの主キーは複合でなければいけませんか?
A: はい。要件は「申込番号ごとに…顧客番号を保持」ですので一意に決めるのは「申込番号」+「顧客番号」の組だけです。サロゲートキーを追加してもかまいませんが、試験では複合主キーで示すのが無難です。
Q: 「参加人数」列はどうなりますか?
A: 参加者を行単位で保持するので「参加人数」は集計で算出でき、冗長になります。正規化の原則から「参加人数」は申込みテーブルから削除するか、ビジネス上の理由があれば残しても更新時には整合性チェックが必要です。
Q: 顧客テーブルに「新規顧客」をどう登録するのですか?
A: 申込み処理時点で「顧客番号」を採番し、「氏名」「住所」「郵便番号」「電話番号」「電子メールアドレス」を登録した上で、中間テーブル「参加」に1行(申込者本人)を挿入します。同行者が既存顧客でなければ同様に顧客テーブルへ追加し、「参加」でリンクします。

関連キーワード: E-R図、多対多、中間テーブル、正規化、外部キー

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

応用情報技術者を
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について