データベーススペシャリスト 2011年 午後1 問01
データベースの基礎理論に関する次の記述を読んで、設問1〜3に答えよ。
D社は、健康の維持増進を目的としたフィットネスクラブ事業を展開している。D社では新たに、メタボリックシンドローム対策のために、専任スタッフが個々の会員の目標に応じた様々なプランを立て、各プランのトレーニングに当たって支援を行うことになった。 具体的には、高い運動効果、確実なシェイプアップ効果が得られるように、運動・栄養に関する専門知識をもった専任スタッフがマンツーマンでアドバイスを行う個人トレーニングなどの有料メニューを提供することにした。 そのための情報システム(以下、本システムという)を構築するために、従来の会員管理データモデルに、必要な要素を追加して、再設計することにした。 本システムのデータモデルで検討した関係スキーマは、図1のとおりである。
図3〜5は、図2の関数従属性及び自明でない多値従属性の表記法に従って、属性間の主な関数従属性を表したものである。 図1、図3〜5 の主な属性とその意味及び制約を表1に示す。 表2は、関係 “予約時間割” の具体例である。
設問1：関係“会員”及び図3,4について、（1）～（3）に答えよ。
（1）関係“会員” は、第1正規形の条件を満たしていない。 その理由を 40字以内で具体的に述べよ。
模範解答
有料メニュー選択は、複数のメニューIDの集合であり、値が単一値ではない。
解説
解答の論理構成
- 第1正規形(1NF)の定義
すべての属性値は「単一・不可分(atomic)」でなければなりません。 - 本問での属性一覧
【問題文】
“会員（会員ID、…、オプション選択、有料メニュー選択）”
ここに “有料メニュー選択” が存在します。 - “有料メニュー選択” の実態
専任スタッフが「個人トレーニングなどの有料メニュー」を複数提案・管理する業務フローのため、1人の会員が複数メニューを同時に持つケースがあると読み取れます。
→ 1属性でメニューIDの集合を保持。 - 結論
したがって関係“会員”は「非原子的な集合値を含む」ため1NF違反となります。
模範解答は
“有料メニュー選択は、複数のメニューIDの集合であり、値が単一値ではない。”
誤りやすいポイント
- 「オプション選択」も複数になるのでは？と迷って二者を併記してしまう。設問は1つの具体的理由を聞いており過剰記述は減点対象です。
- 1NFと2NF・3NFを混同し、「主キー従属」「部分関数従属」など別次元の話を書いてしまう。
- 「NULLがあると1NF違反」と覚えている受験生がいますが、1NFの必須条件はあくまで原子性です。
FAQ
Q: 「有料メニュー選択」を別関係に分割するとどう設計すべきですか？
A: “会員ID” と “メニューID” を主キーとする中間関係(例えば “会員_メニュー”)を新設し、多対多を正規化します。
A: “会員ID” と “メニューID” を主キーとする中間関係(例えば “会員_メニュー”)を新設し、多対多を正規化します。
Q: NULL 値は1NFに影響しませんか？
A: NULLの有無は1NFの判定基準ではありません。原子性を満たしつつNULLが許容されるケースもあります。
A: NULLの有無は1NFの判定基準ではありません。原子性を満たしつつNULLが許容されるケースもあります。
関連キーワード: 第1正規形、原子性、繰返し属性、多対多関係、正規化
設問1：関係“会員”及び図3,4について、（1）～（3）に答えよ。
（2）図3の関数従属性を、図2中の凡例の欄に示した表記法に従って完成させよ。
模範解答
解説
解答の論理構成
- 候補キーの確認
- 【問題文】には“会員種別ID”“オプションID”“メニューID”が「…を一意に識別する」と記載されています。
- よって各 ID がその関係の主キー＝候補キーになります。
- 関数従属性の方向性
- 候補キーから他属性へは必ず関数従属性が成り立ちます。
- 逆方向（例：入会金 → 会員種別ID）はスキーマ説明からは導けません。
- 図2の凡例へのマッピング
- 図2［例1］は A → B を示すシンプルな形式。
- 本問では従属先が複数なので A → {B, C, …} のようにカンマで列挙します。
- 個別に列挙
- 会員種別ID → 入会金、月会費、利用可能日、利用可能時間
- オプションID → オプション名、追加月額
- メニューID → メニュー名、標準時間、料金、定員
- 以上が模範解答図とも一致します（【模範解答】画像参照）。
誤りやすいポイント
- “利用可能日、利用可能時間”だけを別矢印にしてしまう
→ すべて 会員種別ID に従属します。 - “料金、定員”が メニューID ではなく メニュー名 に従属すると誤解
→ 同名メニューでも料金が異なる可能性を排除できないため、識別子である メニューID を起点にします。 - 多値従属性と混同
→ 本問に多値従属性は無い。図2［例4］の表記を使わないよう注意。
FAQ
Q: 「定員」も メニューID から一意に決まる根拠は？
A: 【問題文】に示された メニュー（メニューID、…、定員） という関係スキーマ自体が「1 つの メニューID に対して 1 つの定員」と設計されています。
A: 【問題文】に示された メニュー（メニューID、…、定員） という関係スキーマ自体が「1 つの メニューID に対して 1 つの定員」と設計されています。
Q: メニュー名 が候補キーになり得るか？
A: 【問題文】には “異なるメニューが同名である場合がある” などの記述が無く、逆に メニューID が「…を一意に識別する」と明示されています。したがって メニュー名 単独では識別子になりません。
A: 【問題文】には “異なるメニューが同名である場合がある” などの記述が無く、逆に メニューID が「…を一意に識別する」と明示されています。したがって メニュー名 単独では識別子になりません。
Q: もし追加属性が増えたらどう考える？
A: まず新属性が ID で一意に決まるかを確認し、決まるならば ID → 新属性 を追加。逆に新属性がキー候補になり得るならば候補キー再検討が必要です。
A: まず新属性が ID で一意に決まるかを確認し、決まるならば ID → 新属性 を追加。逆に新属性がキー候補になり得るならば候補キー再検討が必要です。
関連キーワード: 関数従属性、正規化、候補キー、主キー、属性従属
設問1：関係“会員”及び図3,4について、（1）～（3）に答えよ。
（3）図4の関係 “スタッフ” の候補キーを一つ答えよ。
模範解答
｛スタッフ ID、更新日、担当可能日時｝
解説
解答の論理構成
- 図4中央の大枠には 「スタッフID」「更新日」 が描かれ、そこから右側へ矢印が伸び 「担当可能日時」 に到達しています。これは【問題文】の表記規則（図2）より
を意味します。 - 同じ中央枠から上方へ伸びる矢印は 「登録日」 に接続しており、
が成り立ちます。 - 右側ブロック 「担当可能日時」 から下方へ矢印が分岐し 「担当設定日」「勤務店舗」 を指しているため、
が成立します。 - 左側二つの情報ブロック（個人情報、取得資格／対応可能トレーニング）から中央枠へ矢印が入っているので、
も読み取れます。 - 関係 “スタッフ” の全属性集合は
｛スタッフID, 姓、名、性別、生年月日、電話番号、住所、プロフィール、取得資格、対応可能トレーニング、登録日、更新日、担当可能日時、担当設定日、勤務店舗｝
です。上記 1)〜3) により ｛スタッフID, 更新日、担当可能日時｝ で他のすべてが一意に決まるためスーパーキーになります。 - ただし
• ｛スタッフID, 更新日｝ では 3) が不足
• ｛スタッフID, 担当可能日時｝ では 2) が不足
• ｛更新日、担当可能日時｝ では個人情報を決定できない
よって最小決定集合は ｛スタッフID, 更新日、担当可能日時｝ であり、これは候補キーです。
誤りやすいポイント
- 「スタッフID は固有だから単独キー」と早合点する
- “矢印の向き”を読み違え、決定側と従属側を逆に解釈する
- 更新日と担当可能日時のどちらか一方だけで登録日や担当設定日を決められると誤認する
- 左側ブロックからの矢印を無視し、個人情報がキーに不要と判断してしまう
FAQ
Q: スタッフIDが一意なら候補キーではないのですか？
A: 図4の従属性より「同一スタッフIDでも更新日が異なれば別レコード」「担当可能日時が複数存在する」ケースが示唆されており、スタッフID単独では一意性を保証できません。
A: 図4の従属性より「同一スタッフIDでも更新日が異なれば別レコード」「担当可能日時が複数存在する」ケースが示唆されており、スタッフID単独では一意性を保証できません。
Q: どうして更新日と担当可能日時の両方が必要なのですか？
A: 更新日は登録日を、担当可能日時は担当設定日・勤務店舗を決定するため、それぞれが欠けると全属性を一意に決定できなくなるからです。
A: 更新日は登録日を、担当可能日時は担当設定日・勤務店舗を決定するため、それぞれが欠けると全属性を一意に決定できなくなるからです。
Q: 3 つの属性以外を含むスーパーキーは候補キーになりませんか？
A: なりますが、候補キーとは「最小スーパーキー」を指すため、余分な属性を含む組は候補キーとは呼びません。
A: なりますが、候補キーとは「最小スーパーキー」を指すため、余分な属性を含む組は候補キーとは呼びません。
関連キーワード: 関数従属性、候補キー、正規化、最小決定集合
設問2：図5について、（1）、（2）に答えよ。
（1）図5について、(1)関係“自己記録"、"目標”、“測定” の候補キー、及び第1正規形、第2正規形、第3正規形のうち、どこまで正規化されているかを答えよ。 また、正規形の判別根拠を、部分関数従属性及び推移的関数従属性の“あり”又は“なし”で示せ。“あり” の場合は、その関数従属性の具体例を、図2中の意味の欄に示した表記法に従って示せ。
模範解答
解説
解答の論理構成
-
候補キーの同定
- 図5では “自己記録” の決定因子として「会員ID」「記録日」が示され、そこから体重や総歩数へ矢印が伸びている。よって {会員 ID, 記録日} が候補キー。
- “測定” も同様に「会員ID」「測定日時」から全属性へ矢印が出ているので {会員 ID, 測定日時} が候補キー。
- “目標” では中央ブロックに「会員ID」「設定日」「経過日数」が描かれ、その3属性を起点に右下へ派生している。従って {会員 ID, 設定日、経過日数} が候補キー。
-
第1〜第3正規形の判定手順
第1正規形：繰返し集合がない（図5はすべて単一値属性）→3関係とも満たす。
第2正規形：主キーの一部 → 非キー属性 が存在しないこと。- “自己記録”／“測定” は該当する矢印がなく部分関数従属性なし。
- “目標” は {会員 ID, 設定日} → {基準日、スタッフ ID} が存在し、主キーの一部から非キー属性が決定しているので未達。
第3正規形：非キー属性間の推移的関数従属性がないこと。- “自己記録” と “測定” には推移的な矢印が図示されておらず、条件を満たす。
- “目標” は第2正規形を満たしていないため第3正規形にも到達しない。
-
部分・推移的関数従属性の有無
- “自己記録”：部分「なし」、推移「なし」
- “目標”：部分「あり」 {会員 ID, 設定日} → {基準日、スタッフ ID}、推移「なし」
- “測定”：部分「なし」、推移「なし」
誤りやすいポイント
- 「{会員 ID, 設定日} → 基準日」は推移と誤認しがちだが、決定因子が主キーの一部なので部分関数従属性。
- “目標” の主キーを {会員 ID, 設定日} と短絡し、経過日数を落としてしまうミス。図5では経過日数が中央枠内に描かれており候補キーに含まれる。
- “自己記録” の「入力日」矢印を推移的依存と勘違いするケース。図示されているのは主キー側からの直接依存で推移ではない。
FAQ
Q: “目標” を第2正規形にするにはどう分割しますか？
A: 例として R1(会員ID, 設定日、基準日、スタッフID) と R2(会員ID, 設定日、経過日数、体脂肪率、筋肉量、体重、腹囲) に分ければ部分関数従属性が解消され第2正規形になります。
A: 例として R1(会員ID, 設定日、基準日、スタッフID) と R2(会員ID, 設定日、経過日数、体脂肪率、筋肉量、体重、腹囲) に分ければ部分関数従属性が解消され第2正規形になります。
Q: 推移的関数従属性はどのように見抜きますか？
A: 主キーでない属性Ａが別の非キー属性Ｂを決定し、Ｂがさらに他の非キーＣを決定する形（Ａ → Ｂ、Ｂ → Ｃ）。図5にそのような二段階矢印が無いので“なし”と判断します。
A: 主キーでない属性Ａが別の非キー属性Ｂを決定し、Ｂがさらに他の非キーＣを決定する形（Ａ → Ｂ、Ｂ → Ｃ）。図5にそのような二段階矢印が無いので“なし”と判断します。
Q: 第3正規形とボイス・コッド正規形(BCNF)は同じですか？
A: 第3正規形は「主キー候補か否か」を条件にするため、候補キーでない決定因子があっても主キーが絡めば許容されます。BCNFは「決定因子は常に候補キー」でより厳格です。本設問は第3正規形までの判定です。
A: 第3正規形は「主キー候補か否か」を条件にするため、候補キーでない決定因子があっても主キーが絡めば許容されます。BCNFは「決定因子は常に候補キー」でより厳格です。本設問は第3正規形までの判定です。
関連キーワード: 正規化、候補キー、部分関数従属性、推移的関数従属性、第3正規形
設問2：図5について、（1）、（2）に答えよ。
（2）関係 “自己記録"、“目標”、“測定” のうち、第3正規形でないものを一つ選んで関係名を示し、第3正規形に分解した関係スキーマで示せ。
なお、分解した関係スキーマの関係名は任意とし、主キーを、下線で示すこと。
模範解答
関係名：目標
関係スキーマ：
・目標1（会員ID、設定日、基準日、スタッフID）
・目標2（会員ID、設定日、経過日数、体脂肪率、筋肉量、体重、腹囲）
解説
解答の論理構成
- “目標” の属性は【問題文】「会員ID, スタッフID, 基準日、経過日数、設定日、体脂肪率、筋肉量、体重、腹囲」。
- 図5 から以下の関数従属が読み取れます。
・{会員ID, 設定日} → {基準日、スタッフID}
・{会員ID, 設定日、経過日数} → {体脂肪率、筋肉量、体重、腹囲} - 主キー候補は {会員ID, 設定日、経過日数}。
- {基準日、スタッフID} が主キーの「真部分」{会員ID, 設定日} に従属しているため、部分関数従属が存在し第3正規形に違反。
- 対処として、部分従属する属性を切り離す。
・目標1：{会員ID, 設定日} を主キーに {基準日、スタッフID} を保持。
・目標2：主キーを維持し、残りの測定目標項目と経過日数を保持。 - いずれも
① すべての非キー属性が候補キーに完全関数従属し、 ② 候補キー以外の属性間に推移的従属がない
ため第3正規形を満たします。
誤りやすいポイント
- 会員ID＋設定日を主キーと誤認し、「経過日数」を取りこぼす。
- {基準日、スタッフID} と {経過日数} を混同し、推移的従属だと誤解する。
- 分解後の主キーを下線で示さず減点される。
FAQ
Q: 「部分関数従属」と「推移的従属」はどう見分けますか？
A: 主キーの“真部分”による従属なら部分関数従属、候補キー以外の属性を介して従属するなら推移的従属です。本問は前者です。
A: 主キーの“真部分”による従属なら部分関数従属、候補キー以外の属性を介して従属するなら推移的従属です。本問は前者です。
Q: 分解するときに「経過日数」をどちらに入れるか迷います。
A: 「経過日数」は主キーの一部であり、{体脂肪率、筋肉量、体重、腹囲} に完全従属するため、目標2に残すのが正解です。
A: 「経過日数」は主キーの一部であり、{体脂肪率、筋肉量、体重、腹囲} に完全従属するため、目標2に残すのが正解です。
関連キーワード: 第3正規形、関数従属、部分関数従属、正規化、主キー
設問3：関係“予約時間割”について、（1）～（3）に答えよ。
（1）関係“予約時間割”は、更新時に不都合なことが生じる。 その状況を、表2を基に60字以内で具体的に述べよ。
模範解答
・会員 ID＝A1の予約をすべて削除すると、スタッフ ID＝S1が担当するメニューID＝M1の情報もなくなる。
・会員 ID＝C1の予定日時の変更時に、複数行の予定日時をすべて変更しなければ不具合が生じる。
・会員 ID＝A1の予約がないと、スタッフ ID＝S1が担当するメニューID＝M1の情報も登録できない。
解説
解答の論理構成
- 主キー候補を確認
表2から「予約枠 ID」が時間帯・担当スタッフ・メニューを識別しているが、同じ枠に複数会員が入るため一意にならない。
➔ 実質的なキーは {予約枠 ID, 会員 ID}。 - 関数従属性の把握
予約枠 ID → {予定日時、スタッフ ID, メニューID} が成立。
ところが 会員 ID はこの決定要素に含まれず、部分関数従属が発生。 - 生成される更新異常
- 削除異常
「会員 ID＝A1 を削除すると スタッフ ID＝S1 が メニューID＝M1 を担当する枠 R1 の情報も失われる」 - 更新異常
「会員 ID＝C1 の予定日時を修正する際、R3 と R4 の両行を変更しないと食い違いが発生」 - 挿入異常
「スタッフ ID＝S1 が メニューID＝M1 を担当する新枠を追加したくても、対応する 会員 ID が決まらないと行を挿入できない」
- 削除異常
- したがって「一つの関係に複数の事実（予約枠情報と予約参加者情報）が混在している」ことが不都合の原因となる。
誤りやすいポイント
- 「予約枠 ID が主キー」と思い込み、重複行を見落とす
- 更新異常＝重複行だけと誤解し、挿入・削除異常を忘れる
- 具体例に 別 ID を混ぜる／数字を改変する と減点対象
FAQ
Q: なぜ 予定日時 を主キーに含めないのですか？
A: 同じ日時に異なる枠が存在し得るため、一意性を保証できません。表2でも 2011-04-01 19:00 に R2 が複数行あります。
A: 同じ日時に異なる枠が存在し得るため、一意性を保証できません。表2でも 2011-04-01 19:00 に R2 が複数行あります。
Q: 第3正規形にするにはどう分割しますか？
A: 「予約枠（予約枠 ID, 予定日時、スタッフ ID, メニューID）」と「予約参加者（予約枠 ID, 会員 ID）」に分ければ、各関係は主キーに完全関数従属し更新異常を解消できます。
A: 「予約枠（予約枠 ID, 予定日時、スタッフ ID, メニューID）」と「予約参加者（予約枠 ID, 会員 ID）」に分ければ、各関係は主キーに完全関数従属し更新異常を解消できます。
Q: 多対多を別関係に分けるメリットは？
A: 重複がなくなり行数削減・整合性向上・インデックス利用効率化など、性能と保守性の両面で有利です。
A: 重複がなくなり行数削減・整合性向上・インデックス利用効率化など、性能と保守性の両面で有利です。
関連キーワード: 第3正規形、関数従属性、更新異常、削除異常、挿入異常
設問3：関係“予約時間割”について、（1）～（3）に答えよ。
（2）表3は、関係 “予約時間割” を分割した関係 “クラス” の具体例であり、自明でない多値従属性が含まれている。 その自明でない多値従属性を、図2中の凡例の欄に示した表記法に従って図6に示す。図6中の(a)〜(c)に入れる属性名を答えよ。 （b, cは順不同）
模範解答
a：予約枠ID
b：会員ID
c：スタッフID
解説
解答の論理構成
- 自明でない多値従属性とは
凡例［例4］によれば、 ──≫ は「 が同じなら と が互いに独立に複数値を取る」ことを示します。 - 表3 の観察
- 「予約枠ID」が同じ “R2” には、 「会員ID」＝“B1”、“B2” と 「スタッフID」＝“S2” の組合せが列挙されています。
- 「予約枠ID」が同じ “R4” には、 「会員ID」＝“C1”、“C2”、“C3” と 「スタッフID」＝“S2”、“S3” の組合せが列挙されています。
- いずれも “会員” と “スタッフ” の全組合せが存在しており、例えば “C1–S2” と “C1–S3” の双方が登録されています。
- キーの特定
表3 の行を一意に識別できるのは「予約枠ID」「会員ID」「スタッフID」の組であり、そのうち多値従属性の左側に置ける候補キーは「予約枠ID」。 - 多値従属性の成立
「予約枠ID」＝“R4” という同一値で、- 「会員ID」は {“C1”、“C2”、“C3”}
- 「スタッフID」は {“S2”、“S3”}
が独立に出現する。ゆえに
「予約枠ID」 ──≫ 「会員ID」｜「スタッフID」
が成り立つ。
- 図6 へのマッピング
凡例の形式に従い、左側の箱 (a) に左辺の属性「予約枠ID」、右側上段 (b)・下段 (c) に右辺の二集合「会員ID」「スタッフID」を配置する。順不同なので (b)(c) の入れ替えも正解。
誤りやすいポイント
- 「会員ID」と「スタッフID」が同時に決まると誤認し、関数従属性 {予約枠ID}→{会員ID, スタッフID} と考えてしまう。全組合せが存在するためこれは誤りです。
- 「予定日時」まで含めてキーと見なす勘違い。表3 には掲載されていませんが、「予約枠ID」で一意と設計されている点に注意が必要です。
- 多値従属性と第4正規形の関係を混同し、「分割しなくても第3正規形を満たす」などと判断を止めてしまう。
FAQ
Q: 関係 “予約時間割” を第4正規形にするにはどうすれば良いですか？
A: 多値従属性「予約枠ID」──≫「会員ID」「スタッフID」を解消するために、表3 のように “クラス（予約枠ID, 会員ID, スタッフID）” を2つの関係 “予約枠-会員（予約枠ID, 会員ID）” と “予約枠-スタッフ（予約枠ID, スタッフID）” に分割します。
A: 多値従属性「予約枠ID」──≫「会員ID」「スタッフID」を解消するために、表3 のように “クラス（予約枠ID, 会員ID, スタッフID）” を2つの関係 “予約枠-会員（予約枠ID, 会員ID）” と “予約枠-スタッフ（予約枠ID, スタッフID）” に分割します。
Q: 「予定日時」が表に無いのはなぜですか？
A: 「予定日時」は「予約枠ID」→「予定日時」という関数従属性で従属しているため、分割後の関係においては「予約枠ID」のみに保持し、他の表に重複して持たせる必要がないからです。
A: 「予定日時」は「予約枠ID」→「予定日時」という関数従属性で従属しているため、分割後の関係においては「予約枠ID」のみに保持し、他の表に重複して持たせる必要がないからです。
関連キーワード: 多値従属性、第4正規形、候補キー、関数従属性、正規化
設問3：関係“予約時間割”について、（1）～（3）に答えよ。
（3）表3の関係 “クラス” を第4 正規形に分解した関係の具体例を、表3に倣って次の二つの表に示せ。
なお、表の欄はすべて埋まるとは限らない。
模範解答
解説
解答の論理構成
- 多値従属性の確認
表2には「予約枠 ID」が “R4” で「会員 ID」が “C1”“C2”“C3” と複数示され、同じく “R4” に「スタッフ ID」が “S3” “S2” と複数示されています。これは【問題文】の
「表2は、関係 “予約時間割” の具体例である。」
に基づき、1 つの「予約枠 ID」から “会員 ID” と “スタッフ ID” が相互に無関係に増える構造であると読み取れます。 - 第4正規形の判定
第4正規形は「候補キー以外の多値従属性を禁止」する形式です。主キー候補が単独属性「予約枠 ID」のとき、 予約枠 ID ──≫ 会員 ID
予約枠 ID ──≫ スタッフ ID
はどちらも候補キーを左辺に持つ自明でない多値従属性であり、4NF 違反が確定します。 - 分解手順
4NF では “X──≫Y” が成立するとき、関係 R(X,Y,Z) を
R1(X,Y) と R2(X,Z)
に分解するのが原則です。本問では
X = 予約枠 ID
Y = 会員 ID
Z = スタッフ ID
となるため、解答例の 2 つの関係に分かれます。 - 完全性の検証
分解後も両関係を自然結合すれば元の射影（「予約枠 ID, 会員 ID, スタッフ ID」）を復元でき、損失分解でないことが保証されます。
誤りやすいポイント
- 「予定日時」や「メニュー ID」まで含めた 3 表以上の分割を考えてしまう
→ 多値従属性は独立同士だけを扱う点に注意します。 - 主キーを複合（例: 「予約枠 ID, 会員 ID」）だと誤認し、3NF で止めてしまう
→ 表2のデータ重複が示すとおり「予約枠 ID」は一意です。 - 重複行（“R4”“C3” が 2 行ある）を見て異常と判断しがち
→ データ品質の話であり、正規化判定そのものには影響しません。
FAQ
Q: 「予定日時」や「メニュー ID」は正規化に無関係ですか？
A: 本設問は多値従属性だけを題材にしており、「予定日時」「メニュー ID」には独立した多値従属性が見られないため、4NF 分解の対象外です。
A: 本設問は多値従属性だけを題材にしており、「予定日時」「メニュー ID」には独立した多値従属性が見られないため、4NF 分解の対象外です。
Q: 2 つに分解した関係で重複行は禁止ですか？
A: 候補キーが「予約枠 ID, 会員 ID」や「予約枠 ID, スタッフ ID」となるため、それぞれの組合せは一意であり、重複行は発生しません。
A: 候補キーが「予約枠 ID, 会員 ID」や「予約枠 ID, スタッフ ID」となるため、それぞれの組合せは一意であり、重複行は発生しません。
Q: 自然結合で元の関係を復元するとき、不要な組合せが増える心配は？
A: 分解条件が “同一左辺” であるため、自然結合後も元の「予約枠 ID」「会員 ID」「スタッフ ID」の組合せしか生成されず、擬似組合せは生じません。
A: 分解条件が “同一左辺” であるため、自然結合後も元の「予約枠 ID」「会員 ID」「スタッフ ID」の組合せしか生成されず、擬似組合せは生じません。
関連キーワード: 第4正規形、多値従属性、損失なし分解、候補キー、自然結合
