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

キーワード・論点の整理

• 候補キー（Candidate Key）：関係内のタプルを一意に識別できる最小の属性集合。
• 社員所属 関係の属性例（図2より想定）

  属性名	意味
  社員コード	社員を識別するコード
  社員所属組織コード	所属する組織を識別するコード
  社員所属組織名	所属する組織の名称
  （その他属性）	例：報告先社員コードなど

• 組織コード⇔組織名 の一意性
  • 「組織は,組織コードで識別し, 組織名をもつ。 組織名は重複しない。」
    ⇒ 組織コードから組織名を一意に決定できる（組織コード→組織名）
    ⇒ 組織名から組織コードを一意に決定できる（組織名→組織コード）

解答の論理的説明

1. 社員所属を一意に識別するためには 社員 と 組織 の識別子が必要
   • 「社員は, 社員コードで識別し…」
   • 「組織は,組織コードで識別し…」
2. 属性集合として最小限にする（最小性）
   • {社員コード, 社員所属組織コード}
     • 社員コード＋組織コード の組み合わせで重複なくタプルを識別可能
   • 組織コードから組織名が一意に決まるため、社員所属組織名を使っても同様に識別可能
   • {社員コード, 社員所属組織名}
     • 社員コード＋組織名 の組み合わせでも重複なくタプルを識別可能
3. 冗長性を排除
   • {社員コード, 社員所属組織コード, 社員所属組織名} は最小性を欠くため候補キーに含まない

{社員コード, 社員所属組織コード}
{社員コード, 社員所属組織名}

誤りやすいポイント

• 「社員所属組織名は重複しない」ことを見落として、組織名を候補キーに使えないと判断する
• 氏名や役職名など、重複し得る属性を含めてキーを検討してしまう
• 最小性（余分な属性を含まないこと）を忘れて {社員コード, 社員所属組織コード, 社員所属組織名} を挙げる

試験対策のポイント

• 候補キーの定義：一意性 と 最小性 を必ず確認する
• 関連エンティティの主キーをヒントに、関係スキーマのキーを検討する
• 問題文中の「識別」「重複しない」「識別子」などの文言は、キー設定の根拠になる
• 属性間の関数従属性（例：組織コード⇔組織名）を見つけて、キー候補を増やせるか検討する

1. キーワード／論点の整理

2. なぜ「第1正規形」と判定されるのか

社員は複数の組織に所属し得る。
同一組織で複数の役職には就かない。

3. 受験者が誤りやすいポイント

4. 3NF への分解例（模範解答）

5. 試験対策まとめ

1. 正規形チェック手順
   ① 属性が原子値か → 1NF
   ② 複合キーの場合 “部分関数従属” が無いか → 2NF
   ③ 主キー以外の属性を経由する “推移的関数従属” が無いか → 3NF
2. 候補キーの決定は業務ルールから読み取る。
3. 2NF違反：複合キーを持つテーブルでは最頻出。
4. 3NF違反：コード⇔名称など典型的。マスタ切り出しで解消。
5. 午後Ⅰは“主キー下線・外部キー破線”が減点ポイントになりやすい。図・表記ルールを試験直前に再確認！

模範解答の核心となるキーワード・論点整理

• エンティティ間の欠落リレーションシップ：
  「試作案件品目」と「見積依頼」の間のリレーションシップ
• リレーションの名称：
  「要請」（見積依頼を行う主体が試作案件品目であることを表現）
• カーディナリティ：
  １つの試作案件品目に対して、複数の見積依頼が発生し得る（1：多）

なぜその解答になるのか

“見積依頼には, 見積依頼番号を付与し, …どの試作案件に対する見積依頼かが分かるようにしておく。”【問題文 7.(1)①】
“品目ごとに見積依頼明細番号を付与し, 必要調達数量, 希望納入年月日を提示する。”【問題文 7.(1)③】

受験者が誤りやすいポイント

• 「見積依頼」は「品目」ではなく「試作案件品目」を起点に行われる点
  → 単に「品目」エンティティとの関連とすると、どの試作案件の品目についての見積依頼か判別できなくなる。
• モデル構成品目（モデルごとの数量）と混同しやすい点
  → 見積依頼は「試作案件品目」単位で行うため、「モデル構成品目」ではなく「試作案件品目」へのリレーションを設ける。

試験対策として覚えておくべきポイント

1. “○○依頼” や “○○発注” といったエンティティは、必ず「どの明細（品目・サービス単位）に対してか」を起点にリレーションを張る。
2. 文中の「品目ごと」「モデルごと」は、そのままエンティティ名ではなく、定義済みの明細エンティティを指すことが多い。
3. リレーションシップ名は業務上の動詞（例：「要請」「発注」「入荷」）を用いて、関係性がひと目で分かるようにする。
4. カーディナリティは、業務要件（複数社への見積／分納の可能性など）を読み取って決定する。

1. 模範解答のキーワード・論点整理

2. なぜこの解答になるのか ～問題文引用による論理的説明

「この数量を得意先支給数量としてもつ。合計所要数量から得意先支給数量を減じた必要調達数量をもつ。」
→ 得意先支給数量, 必要調達数量 を属性として追加します。

「仕入先は、幾つものブランドを扱っており、同じブランドを異なる仕入先から調達することができる。仕入先ごとに、どのブランドを取り扱っているかを登録している。」
→ 多対多をそのまま使わず、連関表を設けます。連関表には、仕入先を識別する取引先コードと、ブランドを識別するブランドコード（図中では試作案件番号となっていますが、問題文の意図はブランドコード）が外部キーとして入ります。

「見積回答の明細には、見積依頼とは別の複数の品目が提案として返ってくることがある。その場合、その品目の提案理由が記載されている。」
「…一つの品目に対して複数の調達条件が返ってくることがある…ロットサイズ…」
→ どの見積依頼に対する提案かを示す見積依頼番号を主キーとして下線で、提案された品目を示すメーカー型式番号を外部キーで、提案条件としてロットサイズと提案理由を一般属性で持ちます。

「選定した調達条件に対応する見積回答明細を発注明細に記録し、発注ロット数…を決める。」
→ 発注明細に記録するため、対応する見積依頼→見積回答明細を示す見積依頼番号, 見積回答明細番号を外部キーで、発注明細固有の数量として発注ロット数を一般属性で持ちます。

3. 受験者が誤りやすいポイント

• (b)で「必要調達数量」をうっかり忘れやすい
• (c)で「多対多を連関表にする」ことは覚えていても、“どの属性を入れるか（取引先コード＋ブランドコード）”を混同しやすい
• (d)で「提案理由」だけ入れ、ロットサイズを抜け落とすケースがある
• (e)で「見積回答明細番号」を入れずに、発注明細に紐づく見積回答を特定できない設計にしてしまう

4. 試験対策として覚えておくべきポイント

1. 主キーか外部キーか一般属性か
   ・「～で識別する」は主キー
   ・「～を参照する」は外部キー
   ・それ以外で業務的に保持する値は一般属性
2. 多対多関係は必ず連関表
   ・連関表には両側の主キーを外部キーとして並べる
3. 一対多関係は外部キーだけ
   ・子側の関係スキーマに親側の主キーを外部キーとして持たせる
4. 問題文中の数量や条件
   ・「得意先支給数量」「必要調達数量」「発注ロット数」「ロットサイズ」などはすべて見落としやすいので一覧化して整理する
5. 関係スキーマのキー表示
   ・主キーは下線、外部キーは破線下線で示す練習をして、設問の指定に対応できるようにしておきましょう。

1. キーワード・論点整理

2. 解答に至る論理的説明

2.1 問題文の確認

「品目分類を大分類 中分類 小分類のような階層的な構造にしたい。当面は3階層でよいが、将来的には階層を増やす可能性がある。」

2.2 概念データモデル側 (a)

• 子の品目分類は必ず一つの親品目分類に属するため「1対多」
• “自己参照” を使うことで親―子を同一エンティティ内で表現

2.3 関係スキーマ側 (b)

3. 受験者が誤りやすいポイント

4. 試験対策まとめ

1. 階層構造をRDBで表す基本テクニック
   • Adjacent List（親キー方式）
   • Nested Set / Path Enumeration など
   → IPA午後Ⅰでは親キー方式（自己参照FK）が頻出。
2. 自己参照リレーションシップ
   • ER図：エンティティから自分自身へ 1対多
   • テーブル：自テーブル内外部キー＋NULL許容でルートを表す。
3. 試験の制約を確認する習慣
   • 「多対多は使わない」「30字以内」「主キー・外部キーの下線指定」など指示は必ず守る。
   • 制約を満たさない案は即失点につながる。
4. 列名の付け方
   • 意味が一意に分かる名、省略し過ぎない（例：上位品目分類コード）
   • FKを示す場合、名前か下線種別で見分けられるようにする。
5. 将来拡張を意識した設計回答
   • 要件文の “～する可能性がある” はほぼ確実にヒント。ハードコーディング的な設計はNG。

1. キーワード・論点整理

• 分納（partial delivery）の要望
• 「発注明細」と「入荷明細」のリレーションシップを 1:1 → 1:多 へ変更
• 関係スキーマへの属性追加
  • 発注明細 … 発注残ロット数
  • 入荷明細 … 入荷ロット数

2. 解答になる理由の説明

「一部の仕入先から1件の発注明細に対する納品を分けたいという分納要望が出てきた。分納要望に応えつつ、未だ納入されていない数量である発注残ロット数も記録するようにしたい。」

1. 分納を実現するには，1件の発注明細に対して 複数回の入荷 を許容しなければなりません。
2. 現行モデルでは「発注明細 ↔ 入荷明細」が1対1なので，分納した場合に2件目以降の入荷をモデル化できません。
3. そこで概念データモデル上，「発注明細」と「入荷明細」のリレーションシップを 1対1から1対多へ変更 します。
4. 未納数量を管理するため，発注明細に「発注残ロット数」を追加します。
5. 各分納毎の入荷数量を管理するため，入荷明細に「入荷ロット数」を追加します。

3. 受験者が誤りやすいポイント

• 発注残ロット数を入荷明細側に追加してしまう
• リレーションの多重度変更を「発注 ↔ 仕入先」など別の組み合わせで考えてしまう
• 問題文の「分納」「未納数量」というキーワードと，モデリングすべき対象（発注明細・入荷明細）を結び付けられない

4. 試験対策：覚えておくべきポイント

• 「分納」「部分配達」の要件は，1対1→1対多のリレーション変更で対応
• 属性の配置先は，管理すべき情報の単位（発注単位か入荷単位か）で判断
• 問題文にある要望文を手がかりに，モデリングの変更点（多重度・属性追加）を逆算する

回答例