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

データベーススペシャリスト 2011年 午後1 問01

データベースの基礎理論に関する次の記述を読んで、設問1〜3に答えよ。

　 　D社は、健康の維持・増進を目的としたフィットネスクラブ事業を展開している。D社では新たに、メタボリックシンドローム対策のために、専任スタッフが個々の会員の目標に応じた様々なプランを立て、各プランのトレーニングに当たって支援を行うことになった。 具体的には、高い運動効果、確実なシェイプアップ効果が得られるように、運動・栄養に関する専門知識をもった専任スタッフがマンツーマンでアドバイスを行う個人トレーニングなどの有料メニューを提供することにした。 そのための情報システム(以下、本システムという)を構築するために、従来の会員管理データモデルに、必要な要素を追加して、再設計することにした。 本システムのデータモデルで検討した関係スキーマは、図1のとおりである。 　図3〜5は、図2の関数従属性及び自明でない多値従属性の表記法に従って、属性間の主な関数従属性を表したものである。 図1、図3〜5の主な属性とその意味及び制約を表1に示す。 表2は、関係 “予約時間割” の具体例である。
データベーススペシャリスト試験（平成23年 午後1 問1 図1）
データベーススペシャリスト試験（平成23年 午後1 問1 表1）
データベーススペシャリスト試験（平成23年 午後1 問1 図2） ↩設問1(2) ↩設問2(1) ↩設問3(2)
データベーススペシャリスト試験（平成23年 午後1 問1 図3） ↩設問1(1) ↩設問1(2) ↩設問1(3)
データベーススペシャリスト試験（平成23年 午後1 問1 図4） ↩設問1(3)
データベーススペシャリスト試験（平成23年 午後1 問1 図5） ↩設問2(1) ↩設問2(2)
データベーススペシャリスト試験（平成23年 午後1 問1 表2） ↩設問3(1)

設問1：関係“会員”及び図3,4について、（1）～（3）に答えよ。

問題文を見る
（1）関係“会員” は、第1正規形の条件を満たしていない。 その理由を40字以内で具体的に述べよ。

模範解答

有料メニュー選択は、複数のメニューIDの集合であり、値が単一値ではない。

解説

解答の論理構成

  1. 第1正規形(1NF)の定義
    すべての属性値は「単一・不可分(atomic)」でなければなりません。
  2. 本問での属性一覧
    【問題文】
    “会員（会員ID、…、オプション選択、有料メニュー選択）”
    ここに “有料メニュー選択” が存在します。
  3. “有料メニュー選択” の実態
    専任スタッフが「個人トレーニングなどの有料メニュー」を複数提案・管理する業務フローのため、1人の会員が複数メニューを同時に持つケースがあると読み取れます。
    → 1属性でメニューIDの集合を保持。
  4. 結論
    したがって関係“会員”は「非原子的な集合値を含む」ため1NF違反となります。
    模範解答は
    “有料メニュー選択は、複数のメニューIDの集合であり、値が単一値ではない。”

誤りやすいポイント

  • 「オプション選択」も複数になるのでは？と迷って二者を併記してしまう。設問は1つの具体的理由を聞いており過剰記述は減点対象です。
  • 1NFと2NF・3NFを混同し、「主キー従属」「部分関数従属」など別次元の話を書いてしまう。
  • 「NULLがあると1NF違反」と覚えている受験生がいますが、1NFの必須条件はあくまで原子性です。

FAQ

Q: 「有料メニュー選択」を別関係に分割するとどう設計すべきですか？
A: “会員ID” と “メニューID” を主キーとする中間関係(例えば “会員_メニュー”)を新設し、多対多を正規化します。
Q: NULL値は1NFに影響しませんか？
A: NULLの有無は1NFの判定基準ではありません。原子性を満たしつつNULLが許容されるケースもあります。
関連キーワード: 第1正規形、原子性、繰返し属性、多対多関係、正規化

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

この設問をAIに質問する

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

設問1：関係“会員”及び図3,4について、（1）～（3）に答えよ。

問題文を見る
（2）図3の関数従属性を、図2中の凡例の欄に示した表記法に従って完成させよ。

模範解答

データベーススペシャリスト試験（平成23年 午後1 問1 設問1-2解答）

解説

解答の導き方

  1. 図3の点線領域を確認します。そこには「会員種別（会員種別ID、入会金、月会費、利用可能日、利用可能時間）」「オプション（オプションID、オプション名、追加月額）」「メニュー（メニューID、メニュー名、標準時間、料金、定員）」と並んでいます。まずこの列挙が、各関係の属性集合を示していることが分かります。
  2. 図3中央に縦に「会員種別ID」「オプションID」「メニューID」が配置され、それぞれから左右の属性群へ向かう構図になっています。設計上「〜ID」と名付けられた属性はその関係の識別子（主キー）を表すのが一般的であり、識別子が一意に決まれば同じ関係内の他の属性値も一意に定まります。したがって図2の表記法の「A → B」に対応して、各IDが左右の属性群を決定する（関数従属性が成り立つ）と判断できます。
  3. 各関係について、決定子（左辺）と被決定属性（右辺）を確定します。
    • 会員種別については「会員種別（会員種別ID、入会金、月会費、利用可能日、利用可能時間）」の記載から、会員種別IDが入会金・月会費・利用可能日・利用可能時間 を決定します。よって
      会員種別ID → 入会金、月会費、利用可能日、利用可能時間
    • オプションについては「オプション（オプションID、オプション名、追加月額）」の記載から、オプションIDがオプション名・追加月額 を決定します。よって
      オプションID → オプション名、追加月額
    • メニューについては「メニュー（メニューID、メニュー名、標準時間、料金、定員）」の記載から、メニューIDがメニュー名・標準時間・料金・定員 を決定します。よって
      メニューID → メニュー名、標準時間、料金、定員
  4. 以上を図2の表記法にならってまとめると、完成形は以下の3つの関数従属性になります。
    会員種別ID → 入会金、月会費、利用可能日、利用可能時間
    オプションID → オプション名、追加月額
    メニューID → メニュー名、標準時間、料金、定員

誤りやすいポイント

  • メニューの属性数を誤る
    図に示された「メニュー」は「メニュー名、標準時間、料金、定員」の4属性です。余分に属性を付け加えたり、数を誤って答えると失点になります。
  • ID属性の混同（会員IDと 会員種別IDなど）
    図1等にある「会員ID」は個々の会員を識別する属性で、「会員種別ID」は会員種別を識別する属性です。どのIDがどの関係の主キーかを見誤らないことが重要です。
  • 図中の線の太さ・細さを属性の必然性と取り違える
    図の表現（枠線の太さや配置）は可視化の都合で変わることがあります。設問は点線領域の関係スキーマ列挙と中央のID配置から関数従属性を導くことが目的です。
  • 多値従属性と関数従属性を混同する
    属性が「複数個の値を持ち得る」場合は多値従属性や別関係への正規化を検討しますが、今回の図3では各属性が当該関係の被決定属性として列挙されているため、まずは関数従属性で表すのが正しい解釈です。
  • 表記法の誤用（複数属性・複合決定子の書き方）
    図2の表記に従い、複数の被決定属性は右辺に列挙（A → B、C）し、複合決定子は左辺を集合で表す（{A, B} → C）ことを忘れないこと。

FAQ

Q: 図3の「利用可能日」「利用可能時間」は複数値（たとえば複数の曜日や時間帯）を取り得るように見えます。複数値なら多値従属性で表すべきですか？
A: 設問文・図3では「会員種別」の属性として列挙されているため、本問では「会員種別ID → 利用可能日、利用可能時間」と関数従属性で表すのが適切です。ただし実務上これらが本当に複数値を取り得る仕様であれば、別表に分けて正規化するか、図2の多値従属性表記（たとえば 会員種別ID ──≫ 利用可能日｜利用可能時間 のような表記）で明示する必要があります。
Q: 図2の表記で「複数の被決定属性」をどう書けばいいですか？
A: 被決定属性が複数ある場合は右辺に列挙します。たとえばA → B、Cと書くか、集合表記を使ってA → {B, C} と表します。複合決定子は左辺に集合を用いて {A, B} → Cのように書きます。
Q: なぜ「〜ID」がその関係の決定子（主キー）だと判断して良いのですか？
A: モデリング上は「〜ID」という命名は一意識別子を示す慣習であり、図中で中央に配置され矢印で他属性群を指す位置にあることから決定子の役割を果たしていると判断できます。問題文の関係スキーマ列挙に「会員種別（会員種別ID、...）」のようにIDが先に明示されている点が根拠です。
関連キーワード: 関数従属性、多値従属性、主キー、候補キー、正規化

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

この設問をAIに質問する

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

設問1：関係“会員”及び図3,4について、（1）～（3）に答えよ。

問題文を見る
（3）図4の関係 “スタッフ” の候補キーを一つ答えよ。

模範解答

｛スタッフID、更新日、担当可能日時｝

解説

解答の導き方

  1. 図4の点線領域に「スタッフ（スタッフID, 姓、 名、 性別、 生年月日、 電話番号、 住所、 プロフィール、 取得資格、 対応可能トレーニング、 登録日、 更新日、 担当可能日時、 担当設定日、 勤務店舗）」と記載されています。図中では中央に「スタッフID」と「更新日」があり、中央から「担当可能日時」へ矢印が伸び、さらに「担当可能日時」の下に「担当設定日」「勤務店舗」が続いています。図2の表記法に従うと、これらの矢印は属性間の従属性（関数従属性または自明でない多値従属性）を表します。
  2. 図4の読み取りから次の従属性が導けます（図示の意味に基づく解釈）：
    • {スタッフID, 更新日} → 姓、名、性別、生年月日、電話番号、住所、プロフィール、登録日 …（スタッフの個人情報はスタッフごとのある時点（更新日）で決まる）
    • {スタッフID, 更新日} ──≫ 担当可能日時（担当可能な日時は一人のスタッフ・ある更新時点に対して複数あり得るため、非自明な多値従属性であると読むのが妥当です）
    • {スタッフID, 更新日, 担当可能日時} → 担当設定日、勤務店舗（各担当可能日時に対して設定日や勤務店舗が定まる）
    特に重要なのは「担当可能日時」が一人のスタッフに対して複数値を取りうる点であり、これは単純な関数従属性ではなく多値従属性として扱うのが自然です。
  3. 候補キー性の判定（閉包を用いた考え方）：
    • 候補と考える集合をX = ｛スタッフID、更新日、担当可能日時｝とします。
    • {スタッフID, 更新日} → 個人情報等なので、それらはXから導けます。
    • {スタッフID, 更新日, 担当可能日時} → 担当設定日、勤務店舗なので、これらもXから導けます。
    • よってXの閉包X+ は関係「スタッフ」の全属性を含みます。したがってXは超キーです。
  4. 最小性の確認（冗長属性がないか）：
    • ｛スタッフID、更新日｝（担当可能日時を外した場合）は、担当可能日時が複数あるため各担当可能日時ごとに複数行が存在し得るので一意に行を識別できません（多値従属性を考慮すると ｛スタッフID、更新日｝ は担当可能日時を決定しない）。よってキーになりません。
    • ｛スタッフID、担当可能日時｝（更新日を外した場合）は、同じスタッフ・同じ担当可能日時でも、更新日が異なる別の版（プロフィール等の更新履歴）があり得るため一意になりません。
    • ｛更新日、担当可能日時｝（スタッフIDを外した場合）は、異なるスタッフが同じ担当可能日時・同じ更新日を持つ可能性があり一意になりません。
    • 以上より、Xは余分な属性を持たない最小の超キー、すなわち候補キーの一つです。
結論：候補キーの一つは ｛スタッフID、更新日、担当可能日時｝ です。

誤りやすいポイント

  • 矢印をすべて関数従属性（FD）と誤読し、｛スタッフID、更新日｝のみでキーになると結論してしまう。担当可能日時は多値（複数）を取り得るため、多値従属性（MVD）として扱うのが正しい場合が多い。
  • 図中の「登録日」と「更新日」を混同する。登録日は加入時の固定値、更新日はバージョン（日付）として時点を区別するため、更新日がキーに必要となる設計があり得る。
  • 最小性を検証せずに冗長属性を含めたキーを書いてしまう。候補キーは「全属性を決定する」かつ「最小」であることを必ず確認する。
  • 「取得資格」「対応可能トレーニング」などが多値かどうかを明確にせずにキー設計を行う。関係の粒度（どの単位で行を切るか）を図から正確に読み取ることが重要。

FAQ

Q: なぜ ｛スタッフID、更新日｝ が候補キーにならないのですか？
A: 図4の構成から「担当可能日時」は一人のスタッフ・ある更新時点に対して複数の値を持ち得る（利用できる複数の日時）と解釈できます。多値従属性がある場合、｛スタッフID、更新日｝では各担当可能日時ごとの行を区別できないため、行を一意に特定できません。
Q: 取得資格や対応可能トレーニングも多値になっている場合、キーは変わりますか？
A: 取得資格等が多値でかつ行が「資格ごと」に分かれているなら、その別関係では別のキー設計（例えば ｛スタッフID、更新日、取得資格｝ のようなキー）が必要になります。図4が示すように行の単位が「スタッフ×担当可能日時」であれば、今回の候補キー ｛スタッフID、更新日、担当可能日時｝ で全属性を決定できます。
Q: 矢印の向きが読み取りにくいときのチェックポイントは？
A: 図2の表記法（関数従属性と自明でない多値従属性の区別）をまず確認し、業務上の意味（例：可否日時は一人に複数あり得る／氏名は一人に一つ）を当てはめて、FDかMVDかを判断してください。
関連キーワード: 関数従属性、多値従属性、候補キー、最小性、正規化

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

この設問をAIに質問する

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

設問2：図5について、(1)、(2)に答えよ。

問題文を見る
（1）関係“自己記録”、“目標”、“測定”の候補キー、及び第1正規形、第2正規形、第3正規形のうち、どこまで正規化されているかを答えよ。 また、正規形の判別根拠を、部分関数従属性及び推移的関数従属性の“あり”又は“なし”で示せ。“あり” の場合は、その関数従属性の具体例を、図2中の意味の欄に示した表記法に従って示せ。

模範解答

データベーススペシャリスト試験（平成23年 午後1 問1 設問2-1解）

解説

解答の論理構成

  1. 関数従属性の読み取り
    • 【問題文】の「図5　関係“自己記録”、“目標”、“測定”の属性間の主な関数従属性」には、
      ・「会員ID」「記録日」を左辺に取り、右辺に各測定値を示す矢印
      ・「会員ID」「設定日」「経過日数」を中心に、左辺が一部欠けた矢印
      ・「会員ID」「測定日時」を左辺に取り、右辺に各測定値を示す矢印
      が描かれています。これが候補キーと部分／推移的従属性を判断する根拠です。
  2. 自己記録
    • 図中で「会員ID」「記録日」→{体重, 最高血圧, 最低血圧, 総歩数, 入力日}
    • 左辺のいずれか一方のみを左辺にした矢印は存在しないため、{会員ID, 記録日} が最小の決定因、すなわち候補キー。
    • 非キー属性同士を結ぶ矢印も無いため、部分関数従属性・推移的関数従属性ともに“なし”。
    • よって第3正規形。
  3. 目標
    • 図中で
      ・{会員ID, 設定日, 経過日数} → {体脂肪率, 筋肉量, 体重, 腹囲}
      ・{会員ID, 設定日} → {基準日, スタッフID}
    • 最小の決定因は {会員ID, 設定日, 経過日数} であり候補キー。
    • しかし {会員ID, 設定日} が候補キーの真部分集合で “{基準日, スタッフID}” を決定しているので部分関数従属性が“あり”。
    • 推移的関数従属性は見当たらない。
    • 部分関数従属性がある時点で第1正規形止まり。
  4. 測定
    • 図中で「会員ID」「測定日時」→{体脂肪率, 筋肉量, 体重, 腹囲, 最高血圧, 最低血圧, 脈拍数}
    • 左辺の真部分集合を起点とする矢印は無いので {会員ID, 測定日時} が候補キー。
    • 非キー属性間の矢印も無い。部分・推移ともに“なし”。
    • 従って第3正規形。
  5. まとめ（模範解答との一致）
    • 自己記録：候補キー {会員ID, 記録日}／第3正規形／部分・推移とも“なし”
    • 目標：候補キー {会員ID, 設定日, 経過日数}／第1正規形／部分“あり”({会員ID, 設定日} → {基準日, スタッフID})／推移“なし”
    • 測定：候補キー {会員ID, 測定日時}／第3正規形／部分・推移とも“なし”

誤りやすいポイント

  • 「{会員ID, 設定日} → {基準日, スタッフID}」を見落として 目標 を第2正規形と誤判定する。
  • “推移的”と“部分”を混同し、キー外属性どうしの従属性が無い場合でも推移的従属性があると誤って記載する。
  • 候補キーを単一属性と勘違いし、「記録日」「測定日時」が一意と早合点してしまう。
  • 第3正規形＝“すべてのキーが単一属性”と誤解する（実際は複合キーでも可）。

FAQ

Q: 部分関数従属性があるだけで必ず第1正規形にとどまるのですか？
A: はい。部分関数従属性が存在する時点で第2正規形の条件を満たさないため、第1正規形止まりとなります。
Q: 推移的関数従属性の判定ではどこに注目すれば良いですか？
A: 非キー属性Ａが別の非キー属性Ｂを決定し、Ｂがさらに他の非キー属性Ｃを決定するとき、Ａ→Ｃ が成り立てば推移的従属性です。図5にはこのような“非キー→非キー”の矢印が描かれていないため“なし”と判定します。
Q: 候補キーが複数存在する可能性は？
A: 図5に示された矢印だけを見る限り、自己記録と測定には一意の候補キーしか読み取れません。目標も同様で、{会員ID, 設定日, 経過日数} 以外のキーを導く矢印は示されていません。
関連キーワード: 正規化, 候補キー, 部分関数従属, 推移的関数従属, 関数従属性

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

この設問をAIに質問する

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

設問2：図5について、(1)、(2)に答えよ。

問題文を見る
（2）関係“自己記録”、“目標”、“測定”のうち、第3正規形でないものを一つ選んで関係名を示し、第3正規形に分解した関係スキーマで示せ。 なお、分解した関係スキーマの関係名は任意とし、主キーを、下線で示すこと。

模範解答

関係名：目標 関係スキーマ： 　・目標1（会員ID、設定日、基準日、スタッフID） 　・目標2（会員ID、設定日、経過日数、体脂肪率、筋肉量、体重、腹囲）

解説

解答の論理構成

  1. “目標” の属性は【問題文】「会員ID, スタッフID, 基準日、経過日数、設定日、体脂肪率、筋肉量、体重、腹囲」。
  2. 図5から以下の関数従属が読み取れます。
    ・{会員ID, 設定日} → {基準日、スタッフID}
    ・{会員ID, 設定日、経過日数} → {体脂肪率、筋肉量、体重、腹囲}
  3. 主キー候補は {会員ID, 設定日、経過日数}。
  4. {基準日、スタッフID} が主キーの「真部分」{会員ID, 設定日} に従属しているため、部分関数従属が存在し第3正規形に違反。
  5. 対処として、部分従属する属性を切り離す。
    ・目標1：{会員ID, 設定日} を主キーに {基準日、スタッフID} を保持。
    ・目標2：主キーを維持し、残りの測定目標項目と経過日数を保持。
  6. いずれも
    ① すべての非キー属性が候補キーに完全関数従属し、 ② 候補キー以外の属性間に推移的従属がない
    ため第3正規形を満たします。

誤りやすいポイント

  • 会員ID＋設定日を主キーと誤認し、「経過日数」を取りこぼす。
  • {基準日、スタッフID} と {経過日数} を混同し、推移的従属だと誤解する。
  • 分解後の主キーを下線で示さず減点される。

FAQ

Q: 「部分関数従属」と「推移的従属」はどう見分けますか？
A: 主キーの“真部分”による従属なら部分関数従属、候補キー以外の属性を介して従属するなら推移的従属です。本問は前者です。
Q: 分解するときに「経過日数」をどちらに入れるか迷います。
A: 「経過日数」は主キーの一部であり、{体脂肪率、筋肉量、体重、腹囲} に完全従属するため、目標2に残すのが正解です。
関連キーワード: 第3正規形、関数従属、部分関数従属、正規化、主キー

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

この設問をAIに質問する

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

設問3：関係“予約時間割”について、（1）～（3）に答えよ。

問題文を見る
（1）関係“予約時間割”は、更新時に不都合なことが生じる。 その状況を、表2を基に60字以内で具体的に述べよ。

模範解答

・会員ID＝A1の予約をすべて削除すると、スタッフID＝S1が担当するメニューID＝M1の情報もなくなる。 ・会員ID＝C1の予定日時の変更時に、複数行の予定日時をすべて変更しなければ不具合が生じる。 ・会員ID＝A1の予約がないと、スタッフID＝S1が担当するメニューID＝M1の情報も登録できない。

解説

解答の論理構成

  1. 主キー候補を確認
    表2から「予約枠ID」が時間帯・担当スタッフ・メニューを識別しているが、同じ枠に複数会員が入るため予約枠IDだけでは一意にならない。
    ➔ さらに、表2では同じ予約枠R4に会員C1の行がスタッフS2とS3の2行あるので、｛予約枠ID, 会員ID｝でも一意にならず、スタッフIDなども含めて行を識別する必要がある。
  2. 関数従属性の把握
    予約枠ID → 予定日時 が成立し、予約枠の情報（予定日時）が会員やスタッフの数だけ繰り返し記録される。
  3. 生成される更新異常
    • 削除異常
      「会員ID＝A1を削除すると スタッフID＝S1が メニューID＝M1を担当する枠R1の情報も失われる」
    • 更新異常
      「会員ID＝C1の予定日時を修正する際、予約枠R4のC1の2行（スタッフS2・S3）を両方変更しないと食い違いが発生」
    • 挿入異常
      「スタッフID＝S1が メニューID＝M1を担当する新枠を追加したくても、対応する 会員IDが決まらないと行を挿入できない」
  4. したがって「一つの関係に複数の事実（予約枠情報と予約参加者情報）が混在している」ことが不都合の原因となる。

誤りやすいポイント

  • 「予約枠IDが主キー」と思い込み、重複行を見落とす
  • 更新異常＝重複行だけと誤解し、挿入・削除異常を忘れる
  • 具体例に 別IDを混ぜる／数字を改変する と減点対象

FAQ

Q: なぜ 予定日時 を主キーに含めないのですか？
A: 同じ日時に異なる枠が存在し得るため、一意性を保証できません。表2でも2011-04-01 19:00にR2が複数行あります。
Q: 第3正規形にするにはどう分割しますか？
A: 「予約枠（予約枠ID, 予定日時、スタッフID, メニューID）」と「予約参加者（予約枠ID, 会員ID）」に分ければ、各関係は主キーに完全関数従属し更新異常を解消できます。
Q: 多対多を別関係に分けるメリットは？
A: 重複がなくなり行数削減・整合性向上・インデックス利用効率化など、性能と保守性の両面で有利です。
関連キーワード: 第3正規形、関数従属性、更新異常、削除異常、挿入異常

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

この設問をAIに質問する

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

設問3：関係“予約時間割”について、（1）～（3）に答えよ。

問題文を見る
（2）表3は、関係 “予約時間割” を分割した関係 “クラス” の具体例であり、自明でない多値従属性が含まれている。 その自明でない多値従属性を、図2中の凡例の欄に示した表記法に従って図6に示す。図6中の(a)〜(c)に入れる属性名を答えよ。　（b, cは順不同） データベーススペシャリスト試験（平成23年 午後1 問1 表3）
データベーススペシャリスト試験（平成23年 午後1 問1 図6）

模範解答

a：予約枠ID b：会員ID c：スタッフID

解説

解答の導き方

  1. 問題の確認
    図題の指示により「表3は、関係 “クラス” の具体例であり、自明でない多値従属性が含まれている。」とあります。図6はその自明でない多値従属性を図示するための枠組みで、左側の (a) が決定側、右側の上（b）と下（c）が独立した従属集合を表します（図2の例4に対応する表記）。
  2. 表3の観察（属性の列挙）
    表3の属性は 予約枠ID、会員ID、スタッフIDの三つです。したがって図6に入る名前はこの三つのうちのいずれかになります。
  3. 多値従属性の判定（具体例からの導出）
    • 表3を予約枠IDごとに見ると、例えば 予約枠ID = R2の行が
      R2 — 会員ID:B1 — スタッフID:S2
      R2 — 会員ID:B2 — スタッフID:S2
      のように、同じ 予約枠IDに対して会員IDが複数の値（B1, B2）を取っていることが分かります。これは 予約枠ID →→ 会員ID（多値従属性）の可能性を示します。
    • さらに 予約枠ID = R4を見ると、会員IDがC1,C2,C3、スタッフIDがS2,S3と複数の値を取っており、表3には (C1,S2),(C2,S2),(C3,S2),(C1,S3),(C2,S3),(C3,S3) の組合せがすべて存在します。これは「予約枠IDに関して会員IDの値集合とスタッフIDの値集合が互いに独立に複数値を持っている」ことを示します（まさに非自明な多値従属性の特徴です）。
    • よって成立する多値従属性は 予約枠ID →→ 会員IDと 予約枠ID →→ スタッフIDです。
  4. 図6への対応付け（図2の表記法を用いる）
    図2の例4（C ──≫ A｜B）の形に合わせると、Cに対応するのは「予約枠ID」、A,Bに対応するのは「会員ID」と「スタッフID」です。図6の配置に従えば (a) = 予約枠ID、(b),(c) は 会員IDと スタッフID （順不同）となります。
最終的な対応
a：予約枠ID
b：会員ID
c：スタッフID

誤りやすいポイント

  • 予約枠IDを単独で候補キーと誤認する
    表3の各行を一意に識別するのは (予約枠ID, 会員ID, スタッフID) の組であり、予約枠ID単独では行を一意に決められません。予約枠IDに複数の会員や複数のスタッフが対応するため、候補キーと断定すると誤りになります。
  • 関数従属性（FD）と多値従属性（MVD）を混同する
    「予約枠ID → 会員ID」のようなFDと判断すると誤りです。FDなら同一の予約枠IDに対して会員IDは一意である必要がありますが、表3では複数の会員IDが存在します。独立に複数値をとる場合は多値従属性を疑います。
  • 独立性（クロス積）の確認不足
    多値従属性かどうかは、右辺のそれぞれの値集合が独立であるかを確認する必要があります。片側に複数値があっても、組合せがすべて出てこない場合は典型的な非自明多値従属性とは言えません。表3のR4のように全ての組合せが現れているかを確認してください。
  • (b),(c) の順序を気にしすぎる
    設問で (b, cは順不同) とある通り、どちらが上か下かは問われていません。対応付けの内容が合っていれば順序問題で減点されません。

FAQ

Q: どうして左辺を「予約枠ID」にできるのですか？
A: 表3を予約枠IDごとにグループ化すると、同一の予約枠IDに対して複数の会員IDと複数のスタッフIDが現れ、それらが独立に組合せて出現しているからです。図2の多値従属性の表記（C ──≫ A｜B）に合わせると、Cに相当するのが「予約枠ID」です。
Q: 多値従属性は必ず非自明ですか？
A: いいえ。多値従属性X →→ Yが自明でない（非自明）であるためには、YがXに含まれないことと、X ∪ Yが全属性集合と等しくないことなどの条件があります。今回のケースでは「会員ID」「スタッフID」はどちらも「予約枠ID」に含まれず、独立に複数値を取るため非自明です。
Q: 表3のデータが一部欠けていたらどう判断しますか？
A: 多値従属性を主張するには、右辺集合の独立性を確認する必要があります。全ての組合せが出現していない、あるいはある右辺値が常に同時に現れるなどの偏りがあると、多値従属性とは限らず追加検証（または他の従属性の検討）が必要です。
関連キーワード: 多値従属性、関数従属性、第4正規形、候補キー、関係分解

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

この設問をAIに質問する

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

設問3：関係“予約時間割”について、（1）～（3）に答えよ。

問題文を見る
（3）表3の関係 “クラス” を第4正規形に分解した関係の具体例を、表3に倣って次の二つの表に示せ。 　なお、表の欄はすべて埋まるとは限らない。 データベーススペシャリスト試験（平成23年 午後1 問1 設問3-3）

模範解答

データベーススペシャリスト試験（平成23年 午後1 問1 設問3-3解）

解説

解答の導き方

  1. 関係スキーマの確認
    図1より、関係「予約時間割」は属性「予約枠ID」「予定日時」「会員ID」「スタッフID」「メニューID」を持ちます。まずこのスキーマを前提に考えます。
  2. 多値従属性の検出（表2の観察）
    表2を見ると、同じ「予約枠ID」に複数の「会員ID」が現れています（例：R2にB1、B2、R4にC1、C2、C3）。これは同一の「予約枠ID」に対して会員の集合が複数あることを示しており、非自明な多値従属性「予約枠ID」──≫「会員ID」が存在すると判断できます。
    図2の表記法（多値従属性の表現）および図6の「クラス」の例に倣うと、主因子（ここでは「予約枠ID」）に対して複数の属性集合が独立に多値従属している場合は第4正規形の違反になります。設問の意図はこの多値従属性を解消する分解を行うことです。
  3. 分解方針（第4正規形への分解ルール）
    一般に、非自明な多値従属性X ─≫ Yが存在する場合は関係Rを (X, Y) と (X, R − Y) に分解します。本件ではX = 「予約枠ID」、Yの一つに「会員ID」が該当します。設問（模範解答）に従ってもう一方の多値的な関連対象を「スタッフID」とみなし、次の二つの関係に分解します。
    • R1(予約枠ID, 会員ID)
    • R2(予約枠ID, スタッフID)
  4. 主キーの決定（重要）
    分解後の各関係における主キーは次のとおりです。
    • R1の主キーは (予約枠ID, 会員ID) の複合キーです。理由：同一の「予約枠ID」に複数の「会員ID」が対応するため、各行を一意に識別するには両者の組合せが必要です。
    • R2の主キーは (予約枠ID, スタッフID) の複合キーです。設問の分解例では同一予約枠に対して複数のスタッフが対応し得る前提で複合キーとしています（よって単一の「予約枠ID」を主キーとする説明は誤りになります）。
  5. 具体例（模範解答に倣った分解結果）
    左表：R1(予約枠ID, 会員ID)
    予約枠ID会員ID
    R1A1
    R2B1
    R2B2
    R3A1
    R4C1
    R4C2
    R4C3
    右表：R2(予約枠ID, スタッフID)
    予約枠IDスタッフID
    R1S1
    R2S2
    R3S1
    R4S2
    R4S3
    これらは模範解答に示された具体例に対応しています。分解後は各関係が2属性構成となるため、元の非自明な多値従属性は自明になり、第4正規形を満たします。なお、表2に重複行（例：R4, C3の重複）がある場合は分解後の各表では組合せの重複を取り除いて一意に列挙します。
  6. 無損失性と情報の保持
    分解は「予約枠ID」で結合すれば元の組合せ情報（予約枠ごとの会員集合とスタッフ集合）を再現できます。さらに「予定日時」「メニューID」などが「予約枠ID」に関数従属する属性であれば、別に 予約枠情報（例：予約枠(予約枠ID, 予定日時, メニューID)）を用意して保持するのが冗長性回避の観点から望ましいです。

誤りやすいポイント

  • 分解後に「予約枠ID」が単独で各表の主キーになると誤認すること。模範解答の分解は複合主キー（予約枠ID, 会員ID）／（予約枠ID, スタッフID）を想定しています。
  • 関数従属性（FD）と多値従属性（MVD）を混同すること。FDは単一値の決定、MVDは集合として独立に複数値が存在することを扱います。
  • 表2の重複行をそのまま残してしまうこと。正規化では組合せを一意化して記述します。
  • 予定日時やメニューIDの取り扱いを忘れて、冗長なデータ配置にしてしまうこと。これらは予約枠に紐づく（関数従属する）属性として別関係に分離するのが一般的です。
  • 第4正規形の目的をBCNFと混同すること。BCNFは関数従属性に関する正規化であり、4NFは多値従属性に注目する点が異なります。

FAQ

Q: 分解後の (予約枠ID, スタッフID) の主キーが (予約枠ID) でも良いのではないですか？
A: 実データで常に「予約枠ID」→「スタッフID」の関数従属性が成り立つならば (予約枠ID) を主キーにできる場合もあります。しかし問題の分解例（および第4正規形対策）では同一予約枠に複数のスタッフが対応し得ることを想定しており、(予約枠ID, スタッフID) の複合主キーとするのが標準的です。
Q: 分解して情報が失われることはありますか？
A: 正しい分解は無損失（lossless）であれば情報を失いません。本件のように共通の属性「予約枠ID」で結合できる分解は無損失分解となり、自然結合で元の組合せを再現できます。
Q: どうして第4正規形が必要なのですか？
A: 多値従属性が存在すると同じ情報が多数回繰り返され、更新・削除・挿入の異常（冗長性による不整合）が生じやすくなります。4NFにすることでそのような冗長性を取り除き、データ整合性を高めます。
関連キーワード: 多値従属性、 第4正規形、 関数従属性、 複合主キー、 無損失分解

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

この設問をAIに質問する

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

戦国ITクイズ機能

\ せっかくなら /

データベーススペシャリストを
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！

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

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