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

解答の論理構成

1. 組織エンティティの一意性
   「組織は、組織コードで識別し、… 組織名は重複しない」─コードと名称のいずれでも一意識別が可能。
2. 社員と組織の多対多関係
   「社員は、いずれかの組織に所属し、複数の組織に所属し得る」ため、主キーには社員も組織も必要。
3. 行の定義
   図2の「社員所属」関係は1レコード＝“ある社員がある組織に所属する”事実を保持。
4. キー候補の導出
   (社員コード＋組織コード) または (社員コード＋組織名) でレコードが一意に決まり、他の属性では一意にならない。
   よって両組合せが候補キー。

誤りやすいポイント

• 組織名はラベルと考えて非キーと決めつける。問題文で「組織名は重複しない」と明言されているため候補キーになり得ます。
• 「社員コード」単独でキーと思い込む。複数組織に所属可能なので行が重複し、主キー要件を満たしません。
• 上位組織や役職コードをキーに含める。所属の一意性には不要であり、正規化の観点からも冗長です。

FAQ

解答の論理構成

1. “社員所属” の構成
   “社員所属” には
   “社員コード”、“社員氏名”、“社員所属組織コード”、“社員所属組織名”、
   “社員所属上位組織コード”、“社員所属上位組織名”、
   “社員役職コード”、“社員役職名”、
   “報告先社員コード”、“報告先社員氏名”
   が含まれ、下線は “社員コード” のみです。
2. 主キー（候補キー）の確認
   【問題文】「社員は、いずれかの組織に所属し、複数の組織に所属し得る。」
   したがって “社員コード” 単独ではレコードが一意にならず、候補キーは ｛社員コード, 社員所属組織コード｝ と ｛社員コード, 社員所属組織名｝ です（組織名も組織を一意に識別するため）。
3. 部分関数従属の有無
   ・“社員氏名” は “社員コード” のみに関数従属。
   ・“社員所属上位組織コード” は “社員所属組織コード” のみに関数従属。
   ・“社員所属上位組織名” は “社員所属組織名” のみに関数従属。
   → 候補キーの一部に依存する属性が存在し、第１正規形止まり。
4. 第３正規形へ分解
   関係名・属性名は本文中の用語を用いて、次の4関係に分解します（解答例と同じ）。
   ・社員（ 社員コード , 社員氏名 ）
   ・組織（ 組織コード , 組織名 , 上位組織コード ）
   ・社員所属（ 社員コード , 所属組織コード , 役職コード , 報告先社員コード ）
   ・役職（ 役職コード , 役職名 ）
   上位組織の名前は、上位組織コードで“組織”を参照すれば分かるので、“組織”に上位組織名はもたせません。報告先社員の氏名も、報告先社員コードで“社員”を参照すれば分かります。社員所属の 所属組織コード は主キーの一部であると同時に“組織”を参照する外部キー、上位組織コード・役職コード・報告先社員コード も外部キーです。
   以上で、主キーに対する部分／推移的関数従属が排除され第３正規形となります。

誤りやすいポイント

• “社員コード” を主キーと決め打ちし、複数組織所属を見落とす。
• 「社員氏名は社員コードに従属しているから問題ない」と考え、第２正規形の判定を忘れる。
• “社員所属上位組織コード” と “社員所属上位組織名” が組織コードに従属する推移的依存を見逃す。
• 分解時に “社員役職名” を元の “社員所属” に残したままにしてしまい、第３正規形に到達しない。

FAQ

解答の導き方

1. 取引先／得意先／仕入先の関係を確定する
   • 根拠：「得意先と仕入先の両方に該当する取引先は存在しない。」
   • 考え方：この記述は「取引先」をスーパタイプとし、「得意先」「仕入先」を排他的なサブタイプとしてモデル化すべきことを示します。したがって図1では「取引先」から「得意先」「仕入先」へ派生（サブタイプ）リレーションシップを明示します。
2. 仕入先→取扱いブランド→品目 の関係を明確にする
   • 根拠：「仕入先は、幾つものブランドを扱っており、同じブランドを異なる仕入先から調達することができる。仕入先ごとに、どのブランドを取り扱っているかを登録している。」および「品目は、メーカーが付けたブランドのいずれか一つに属する。」
   • 考え方：仕入先とブランドの対応は中間エンティティ（取扱いブランド）で表現し、ブランドは品目に属するため、図1では「仕入先」→「取扱いブランド」→「ブランド」→「品目」という経路（取扱いブランドから品目へも線を引くことで、仕入先が扱える品目群が辿れることを示す）を補完します。
3. 試作案件 → モデル → モデル構成品目 → 試作案件品目 の流れを確認する
   • 根拠：「モデルで使用する品目ごとに、モデル1台当たりの所要数量をもつ。」および「試作案件で使用する品目ごとの合計所要数量をもつ。...合計所要数量から得意先支給数量を減じた必要調達数量をもつ。」
   • 考え方：モデルごとの所要数量（モデル構成品目）を集約して試作案件単位の合計（試作案件品目）ができ、それが必要調達数量の起点になります。図1ではこれらの階層的な矢印（試作案件→モデル→モデル構成品目、および試作案件→試作案件品目）を明確にします。
4. 試作案件品目／得意先 → 見積依頼 の関係を補う
   • 根拠：「見積依頼には、...どの試作案件に対する見積依頼かが分かるようにしておく。」および「品目ごとに見積依頼明細番号を付与し、 必要調達数量、 希望納入年月日を提示する。」
   • 考え方：見積依頼は内部的にどの試作案件のためかを管理する必要があるため、図1では「試作案件（または試作案件品目）」から「見積依頼」へ線を引き、かつ見積依頼の明細（見積依頼明細）が試作案件品目（必要調達数量）を起点として作られることを示します。得意先情報（どの得意先の案件か）も内部的に関連付けられるため、得意先→見積依頼の線を補います（外部の仕入先には得意先を明かさない運用ルールは別途扱いますが、概念モデル上は関連を保持します）。
5. 見積依頼（ヘッダ／明細） ↔ 見積回答（ヘッダ／明細）の二重参照を入れる
   • 根拠：「入手した見積回答には、見積依頼番号、...が記載されている。」および「見積回答の明細には、見積依頼明細番号、メーカー型式番号、調達条件、...が記載されている。」
   • 考え方：見積回答のヘッダは見積依頼番号で見積依頼（ヘッダ）を参照し、見積回答明細は見積依頼明細番号で見積依頼明細を参照します。したがって図1では「見積依頼」→「見積回答」および「見積依頼明細」→「見積回答明細」という二重の接続を補います。これにより、回答がどの依頼・どの明細に対するものかを正確に結び付けられます。
6. 見積回答明細 → 発注 → 発注明細 の連鎖をつなぐ
   • 根拠：「選定した調達条件に対応する見積回答明細を発注明細に記録し、発注ロット数、指定納入年月日を決める。」
   • 考え方：発注は採用した見積回答明細を基に発注明細を作るため、図1では見積回答明細から発注（ヘッダ）につなぎ、その下に発注明細を置く流れを補完します。
7. 発注明細 → 入荷 → 入荷明細 の流れを入れる（現行ルール）およびモデル構成品目との紐付け
   • 根拠：「入荷の品目ごとに入荷明細番号を発行する。1件の発注明細に対して、入荷が分かれることはない。」および「入荷番号と入荷明細番号が書かれたシールを品目の外装に貼って、 製造担...」
   • 考え方：現行業務では発注明細単位で入荷が完了するため、図1では「発注明細」→「入荷」→「入荷明細」と直線的に結びます。さらに、どのモデルの構成品目に対する発注／入荷かを追跡するために、図1では「モデル構成品目」から発注明細および入荷明細へ繋がる線を補います。理由は、モデル構成品目の「モデル1台当たりの所要数量」が発注数・入荷数の発生源であり、発注明細／入荷明細はどのモデル分を調達・受領したかを記録する必要があるためです。
8. 品目→見積依頼（および見積回答明細→品目）を明示する
   • 根拠：「品目を調達する際は、当該品目のブランドを扱う複数の仕入先に見積依頼を行う。」および「見積回答の明細には、...メーカー型式番号...が記載されている。」
   • 考え方：見積依頼／見積回答明細は特定の品目（メーカー型式番号）に紐づくため、図1では品目から見積依頼（ヘッダ）や見積回答明細へ矢印を引き、回答明細がどの品目についての調達条件かを示します。

• 「得意先」と「仕入先」は「取引先」の排他的サブタイプである（どちらか一方に属する）。
• 「モデル構成品目（1台当たりの所要数量）」が発注・入荷の追跡の起点になるため、図1上でモデル構成品目 → 発注明細／入荷明細のリレーションシップを必ず補うこと。

誤りやすいポイント

• 試作案件品目とモデル構成品目を混同する
  • 試作案件品目は試作案件単位の合計所要数量／必要調達数量で、モデル構成品目はモデル単位の1台当たり所要数量です。見積依頼明細は必要調達数量（試作案件品目由来）を提示します。
• 見積依頼と見積回答の参照がヘッダと明細の両方で存在することを見落とす
  • 見積回答は見積依頼番号（ヘッダ参照）と見積依頼明細番号（明細参照）の両方を持つため、両方向の対応を図示する必要があります。
• モデル構成品目→発注明細／入荷明細の線を入れない（トレース不可にする）
  • 発注明細や入荷明細で「どのモデル分か」を記録できなくなり、実務的に誤りになります。
• 取引先のスーパ／サブタイプを排他的に扱わない（得意先と仕入先を同時に許容する）
  • 原文に「得意先と仕入先の両方に該当する取引先は存在しない。」とあるため、排他性を確保する必要があります。
• 見積回答明細が別品目を提案する・同一品目で複数調達条件を返す点を無視する
  • これを無視すると見積回答明細の属性設計や発注選択の表現が不十分になります。

FAQ

解答の論理構成

1. (a) モデルの主キー
   【問題文】「モデルは、試作案件番号とモデル名で識別する。」
   よって (モデル名、試作案件番号) が複合キーになり、(a)＝試作案件番号。
2. (b) 試作案件品目の数量属性
   【問題文】「得意先支給数量」「必要調達数量」を保持するとある。
   既存項目に無いので (b)＝得意先支給数量・必要調達数量。
3. (c) 見積依頼の参照先
   ・誰に依頼したか：仕入先＝取引先なので「取引先コード」が要る。
   ・どの試作案件のためか：【問題文】「どの試作案件に対する見積依頼かが分かるようにしておく。」
   よって (c)＝取引先コード・試作案件番号。
4. (d) 見積回答明細の追加列
   ・複数ロットを返す：【問題文】「ロットサイズ1,000個…ロットサイズ1個…という2通りの見積回答」。→ロットサイズ
   ・別品目の提案：【問題文】「その場合…提案理由」。→提案理由
   ・識別強化：仕入先発番の「見積回答明細番号」は重複するため、親番号「見積依頼番号」を主キー側に追加。
   ・品目を示す：【問題文】「メーカー型式番号」が明細に記載。
   よって (d)＝見積依頼番号・メーカー型式番号・ロットサイズ・提案理由。
5. (e) 発注明細の参照と数量
   ・発注明細は「選定した調達条件に対応する見積回答明細を発注明細に記録」する。→見積依頼番号・見積回答明細番号
   ・発注時に決める数量：【問題文】「発注ロット数」を保持。
   よって (e)＝見積依頼番号・見積回答明細番号・発注ロット数。

誤りやすいポイント

• 「見積回答番号」「見積回答明細番号」は仕入先内だけで一意。テーブルの主キーに直接使うと重複エラーを見落とす。
• 見積依頼先は仕入先だが、属性名は「仕入先コード」ではなく統一語彙の「取引先コード」。
• 発注明細で試作案件番号を持たせたくなるが、業務では「同時期に同じ仕入先に発注を束ねる」ため非キー属性になる恐れがある。外部キーは見積系に遡るのが正解。

FAQ

解答の導き方

1. 可能な設計案の比較
   • 各階層（大分類・中分類・小分類）ごとに別エンティティを作ると、当面は問題なくても将来階層数が変わるたびにスキーマを変更する必要があり柔軟性に欠けます。
   • 一つのエンティティに自己参照（再帰／自己参照リレーションシップ）を持たせ、各分類が親分類を指す形にすると、任意の深さの階層を表現でき、拡張に強い設計になります。設問の「将来的には階層を増やす可能性がある」に合致します。
2. 概念データモデルでの変更（ER上の対応）
   • 対象エンティティタイプは「品目分類」です。ここに「品目分類」自身を親とする自己参照の1対多のリレーションシップ（親：1、子：多）を追加します。
   • 親を持たない最上位分類は親参照をNULL許容とします。
   • このリレーションは「多対多」を用いず、1対多として表現できます（図1の方針に抵触しません）。
3. 関係スキーマでの変更（物理表への反映）
   • 図2にある関係「品目分類（品目分類コード、 品目分類名）」に属性を1つ追加します。追加属性名は「上位品目分類コード」です。
   • ここで重要な参照関係は、上位品目分類コード（外部キー）が品目分類コード（主キー）を参照する、という向きです。つまり上位品目分類コード → 品目分類.品目分類コード。最上位はNULLを許容します。
   • 追加属性のデータ型は品目分類コードと同一にし、参照制約（外部キー）を設定します。運用上は親が削除された場合に上位参照をNULLにする（ON DELETE SET NULL）等のポリシーを検討します。
4. 最終の簡潔な解答
   • (a) 品目分類に自己参照の1対多リレーションシップを追加する
   • (b) 関係名：品目分類　属性名：上位品目分類コード
     （関係表記例） 品目分類（品目分類コード、 品目分類名、 上位品目分類コード）
     上位品目分類コードは外部キーで、_品目分類コード_を参照（NULL許容）。

誤りやすいポイント

• 「大分類／中分類／小分類を別テーブルにする」設計にして将来拡張時にスキーマ変更が必要になる点を見落とす。
• 参照の向きを逆に記述する（誤：品目分類コードが上位品目分類コードを参照する）。正しくは「上位品目分類コード（外部キー）が品目分類コード（主キー）を参照」する。
• ルート（最上位）の親参照をNOT NULLにしてしまい、最上位ノードを表現できなくなる。NULL許容が必要。
• 階層検索手段を考慮しない（再帰問い合わせや補助テーブルの必要性を無視）。
• 外部キー制約や削除時の挙動（ON DELETE）を未定義のままにし、運用で矛盾を起こす。

FAQ

解答の論理構成

1. 分納ニーズの把握
   【問題文】7(2)②では「1件の発注明細に対して、入荷が分かれることはない。」と明示されていました。
   しかし〔利用者の要望〕2には「一部の仕入先から1件の発注明細に対する納品を分けたい」とあるため、この業務ルールが変更となります。
2. 概念データモデルへの反映
   • 旧ルール：発注明細⇔入荷明細 が“1対1”。
   • 新ルール：1つの発注明細に対して複数の入荷明細を許容する“1対多”が必要。
     よって「発注明細」と「入荷明細」のリレーションシップを変更します。
3. 関係スキーマへの反映
   (1) 入荷側
   分納単位で入荷数量を記録するため、“入荷ロット数”を入荷明細に追加。
   (2) 発注側
   分納が進むにつれて残りを把握するため、“発注残ロット数”を発注明細に追加。
4. 追加属性の所在
   • 発注明細：発注残ロット数
   • 入荷明細：入荷ロット数

誤りやすいポイント

• 「入荷ロット数」を発注明細に置き、「発注残ロット数」を入荷明細に置く逆配置ミス。
• リレーションシップを“多対多”で表現してしまう誤設計。問題指示に「“多対多” のリレーションシップを用いないこと」とある。
• 関係スキーマに追加した属性へ主キーや外部キーの下線を引き忘れる記述ミス。

FAQ