令和5年度 秋期 データベーススペシャリスト試験 午後I 問1 関数従属性と正規形の判定
テクノロジデータベース
この問題は2023(R5)秋 データベーススペシャリスト 午後Iに出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。
本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。
学習ガイド
電子機器の製造受託会社A社の調達システムを題材に、関係"社員所属"の候補キーと正規形を問う午後Iの問題です。社員が複数の組織に所属し、組織ごとに役職や報告先が決まるという業務ルールが、そのまま関数従属性の複雑さに直結します。候補キーの全列挙は一つでも見落とすと正規形の判定までずれるため、この記事では従属関係を整理してから候補キーを導き、該当する正規形を根拠とともに確定する手順をたどります。
この記事で押さえる論点
- 関係"社員所属"の関数従属性を洗い出して候補キーを全て導出する
- 複数属性から成る候補キーを{ }表記で正しく列挙する
- 第2正規形・第3正規形・ボイスコッド正規形のどれに該当するかを根拠つきで判定する
- 部分関数従属・推移関数従属の有無から正規化の余地を説明する
出題情報
- 出題
- 2023(R5)秋 データベーススペシャリスト 午後I 問1
- 配点
- 50点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
データベースの設計では,業務内容や業務で取り扱うデータなどの実世界の情報を総合的に理解し,データモデルに反映することが求められる。
本問では,電子機器の製造受託会社における調達システムを題材として,関数従属性,正規化理論などの基礎知識を用いてデータモデルを分析する能力,業務要件をデータモデルに反映する能力,設計変更によるデータモデル及び関係スキーマの適切な変更を行う能力を問う。
問1では,電子機器の製造受託会社における調達システムを題材に,正規化理論に基づくデータモデル分析,業務要件に基づくデータベース設計について出題した。全体として正答率は平均的であった。
問題本文
電子機器の製造受託会社における調達システムの概念データモデリングに関する次の記述を読んで,設問に答えよ。
基板上に電子部品を実装した電子機器の製造受託会社であるA社は,自動車や家電などの製品開発を行う得意先から電子機器の試作品の製造を受託し,電子部品の調達と試作品の製造を行う。今回,調達システムの概念データモデル及び関係スキーマを再設計した。
〔現行業務〕
組織
(1) 組織は,組織コードで識別し,組織名をもつ。組織名は重複しない。
(2) 組織は,階層構造であり,いずれか一つの上位組織に属する。役職
役職は,役職コードで識別し,役職名をもつ。役職名は重複しない。社員
(1) 社員は,社員コードで識別し,氏名をもつ。同姓同名の社員は存在し得る。
(2) 社員は,いずれかの組織に所属し,複数の組織に所属し得る。
(3) 一部の社員は,各組織において役職に就く。同一組織で複数の役職には就かない。
(4) 社員には,所属組織ごとに,業務内容の報告先となる社員が高々 1 名決まっている。得意先と仕入先
(1) 製造受託の依頼元を得意先,電子部品の調達先を仕入先と呼ぶ。
(2) 得意先と仕入先とを併せて取引先と呼ぶ。取引先は,取引先コードを用いて識別し,取引先名と住所をもつ。
(3) 取引先が,得意先と仕入先のどちらに該当するかは,取引先区分で分類している。得意先と仕入先の両方に該当する取引先は存在しない。
(4) 仕入先は,電子部品を扱う商社である。A社は,仕入先と調達条件(単価,ロットサイズ,納入可能年月日)を交渉して調達する。仕入先ごとに昨年度調達金額をもつ。
(5) 得意先は,昨年度受注金額をもつ。品目
(1) 試作品を構成する電子部品を品目と呼び,電子部品メーカー(以下,メーカーという)が製造している。
① 品目は,メーカーが付与するメーカー型式番号で識別する。メーカー型式番号は,メーカー間で重複しない。
② メーカー各社が発行する電子部品カタログでメーカー型式番号を調べると,電子部品の仕様や電気的特性は記載されているが,単価やロットサイズは記載されていない。
(2) 品目は,メーカーが付けたブランドのいずれか一つに属する。
① ブランドは,ブランドコードで識別し,ブランド名をもつ。
② 仕入先は,幾つものブランドを扱っており,同じブランドを異なる仕入先から調達することができる。仕入先ごとに,どのブランドを取り扱っているかを登録している。
(3) 品目は,品目のグループである品目分類のいずれか一つに属する。品目分類は,品目分類コードで識別し,品目分類名をもつ。試作案件登録
(1) 得意先にとって試作とは,量産前の設計検証,機能比較を目的に,製品用途ごとに,性能や機能が異なる複数のモデルを準備することをいう。得意先からモデルごとの設計図面,品目構成,及び製造台数の提示を受け,試作案件として次を登録する。
① 試作案件
・試作案件は,試作案件番号で識別し,試作案件名,得意先,製品用途,試作案件登録年月日をもつ。
② モデル
・モデルごとに,モデル名,設計図面番号,製造台数,得意先希望納入年月日をもつ。モデルは,試作案件番号とモデル名で識別する。
③ モデル構成品目
・モデルで使用する品目ごとに,モデル1台当たりの所要数量をもつ。
④ 試作案件品目
・試作案件で使用する品目ごとの合計所要数量をもつ。
・通常,品目の調達はA社が行うが,得意先から無償で支給されることがある。この数量を得意先支給数量としてもつ。
・合計所要数量から得意先支給数量を減じた必要調達数量をもつ。見積依頼から見積回答入手まで
(1) 品目を調達する際は,当該品目のブランドを扱う複数の仕入先に見積依頼を行う。
① 見積依頼には,見積依頼番号を付与し,見積依頼年月日を記録する。また,どの試作案件に対する見積依頼かが分かるようにしておく。
② 仕入先に対しては,見積依頼がどの得意先の試作案件によるのか明かすことはできないが,得意先が不適切な品目を選定していた場合に,仕入先からの助言を得るために,製品用途を提示する。
③ 品目ごとに見積依頼明細番号を付与し,必要調達数量,希望納入年月日を提示する。
④ 仕入先に対して,見積回答時には対応する見積依頼番号,見積依頼明細番号の記載を依頼する。
(2) 仕入先から見積回答を入手する。見積回答が複数に分かれることはない。
① 入手した見積回答には,見積依頼番号,見積有効期限,見積回答年月日,仕入先が付与した見積回答番号が記載されている。見積回答番号は,仕入先間で重複し得る。
② 見積回答の明細には,見積依頼明細番号,メーカー型式番号,調達条件,仕入先が付与した見積回答明細番号が記載されている。回答されない品目もある。見積回答明細番号は,仕入先間で重複し得る。
③ 見積回答の明細には,見積依頼とは別の複数の品目が提案として返ってくることがある。その場合,その品目の提案理由が記載されている。
④ 見積回答の明細には,一つの品目に対して複数の調達条件が返ってくることがある。例えば,ロットサイズが1,000個の品目に対して,見積依頼の必要調達数量が300個の場合,仕入先から,ロットサイズ 1,000個で単価 0.5円,ロットサイズ1個で単価2円,という2通りの見積回答の明細が返ってくる。発注から入荷まで
(1) 仕入先からの見積回答を受けて,得意先と相談の上,品目ごとに妥当な調達条件を一つだけ選定する。
① 選定した調達条件に対応する見積回答明細を発注明細に記録し,発注ロット数,指定納入年月日を決める。
② 同時期に同じ仕入先に発注する発注明細は,試作案件が異なっても,1回の発注に束ねる。
③ 発注ごとに発注番号を付与し,発注年月日と発注合計金額を記録する。
(2) 発注に基づいて,仕入先から品目を入荷する。
① 入荷ごとに入荷番号を付与し,入荷年月日を記録する。
② 入荷の品目ごとに入荷明細番号を発行する。1件の発注明細に対して,入荷が分かれることはない。
③ 入荷番号と入荷明細番号が書かれたシールを品目の外装に貼って,製造担当へ引き渡す。
〔利用者の要望〕
品目分類の階層化
品目分類を大分類,中分類,小分類のような階層的な構造にしたい。当面は3階層でよいが,将来的には階層を増やす可能性がある。仕入先からの分納
一部の仕入先から1件の発注明細に対する納品を分けたいという分納要望が出てきた。分納要望に応えつつ,未だ納入されていない数量である発注残ロット数も記録するようにしたい。
〔現行業務の概念データモデルと関係スキーマの設計〕
現行業務の概念データモデルを図1に,関係スキーマを図2に示す。

図の説明テキスト
現行業務の概念データモデルを示すER図。「取引先」は「得意先」と「仕入先」をサブタイプとして持つ。その他、「ブランド」「品目分類」「品目」「取扱いブランド」「試作案件」「モデル」「試作案件品目」「モデル構成品目」「見積依頼」「見積回答」「発注」「入荷」「見積依頼明細」「見積回答明細」「発注明細」「入荷明細」の各エンティティと、それらを結ぶリレーションシップが実線および矢印で描画されている。

図の説明テキスト
現行業務の関係スキーマ(未完成)を記述した枠。社員所属、取引先、得意先、仕入先、ブランド、品目分類、品目、取扱いブランド、試作案件、モデル、モデル構成品目、試作案件品目、見積依頼、見積依頼明細、見積回答、見積回答明細、発注、発注明細、入荷、入荷明細の各リレーションについて、属性のリストが括弧内に記載されている。主キーには実線の下線、外部キーには破線の下線が引かれている。「モデル」と「モデル構成品目」にはa、「試作案件品目」にはb、「見積依頼」にはc、「見積回答明細」にはd、「発注明細」にはeが設けられている。
解答に当たっては,巻頭の表記ルールに従うこと。ただし,エンティティタイプ間の対応関係にゼロを含むか否かの表記は必要ない。エンティティタイプ間のリレーションシップとして“多対多”のリレーションシップを用いないこと。属性名は,意味を識別できる適切な名称とすること。関係スキーマに入れる属性を答える場合,主キーを表す下線,外部キーを表す破線の下線についても答えること。
設問と解答・解説
設問1
図2中の関係“社員所属”について答えよ。
(1)
関係“社員所属”の候補キーを全て挙げよ。なお,候補キーが複数の属性から構成される場合は,{ }で括ること。
模範解答
{社員コード,社員所属組織コード}
{社員コード,社員所属組織名}
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 「社員コードと社員所属組織コード」および「社員コードと社員所属組織名」の2つの候補キーを両方とも正確に識別できている。
- 1点: 1つの候補キーのみ正確に識別できている。
- 0点: 正確な候補キーを識別できていない。
論理性(構造)(2点)
- 2点: 複合キーの構成要素が論理的に正しく組み合わされている。
- 1点: 構成要素の組み合わせに一部誤りがある。
- 0点: 構成要素の組み合わせが論理的に誤っている。
解説
解答の導出と根拠
関係“社員所属”の関数従属性から候補キーを導出します。候補キー とは、関係中の組を一意に識別できる属性の極小集合を指します。
設問の状況記述から、社員は複数の組織に所属し、それぞれの組織で特定の役職を持つことが分かります。そのため、社員を一意に識別する「社員コード」と、所属する組織を一意に識別する「社員所属組織コード」または「社員所属組織名」の組み合わせが組を一意に決定します。
高得点のポイント
候補キーとなる2つの組み合わせを過不足なく全て挙げていること。
複数属性から構成されるキーを
{ }で括るという形式指定を遵守していること。
(2)
関係“社員所属”は,次のどの正規形に該当するか。
模範解答
選択肢イ: 第1正規形
配点 3点
解説
解答の導出と根拠
関係“社員所属”には繰返し項目が存在しないため、少なくとも 第1正規形 を満たしています。しかし、複合キーの一部である「社員コード」に関数従属する「社員氏名」などが存在するため、部分関数従属性を持ちます。したがって第2正規形以降の条件を満たしません。
各選択肢の解説
ア: 繰返し項目がないため、非正規形ではありません。
イ: 正解。繰返し項目がないが部分関数従属性が存在するため、第1正規形に該当します。
ウ: 部分関数従属性が存在するため、第2正規形の条件を満たしていません。
エ: 部分関数従属性が存在するため、第3正規形の条件を満たしていません。
(3)
その根拠を,具体的な属性名を挙げて60字以内で答えよ。
模範解答
全ての属性が単一値をとり,候補キーの一部である“社員コード”に関数従属する“社員氏名”があるから
全ての属性が単一値をとり,候補キーの一部である“社員所属組織コード”に関数従属する“社員所属上位組織コード”があるから
全ての属性が単一値をとり,候補キーの一部である“社員所属組織名”に関数従属する“社員所属上位組織名”があるから
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 非キー属性が候補キーの一部に関数従属している事実(部分関数従属性)を正しく指摘できている。
- 1点: 部分関数従属性の存在を指摘しているが、具体性が不十分である。
- 0点: 部分関数従属性に関する正しい指摘ができていない。
論理性(構造)(2点)
- 2点: 具体的な属性名を挙げ、論理的な因果関係として説明できている。
- 1点: 具体的な属性名は挙げられているが、因果関係の説明が不明瞭である。
- 0点: 論理的な説明になっていない。
解説
解答の導出と根拠
関係が第2正規形でない理由は、部分関数従属性 が存在するためです。候補キーの一部に関数従属する非キー属性を具体的に指摘する必要があります。
解答としては、「社員コード」に関数従属する「社員氏名」や、「社員所属組織コード」に関数従属する「社員所属上位組織コード」などが挙げられます。
高得点のポイント
部分関数従属性が存在するという事実を正確に指摘していること。
その根拠となる具体的な属性名(候補キーの一部と、それに従属する非キー属性)を挙げていること。
(4)
第3正規形でない場合は,第3正規形に分解した関係スキーマを示せ。ここで,分解後の関係の関係名には,本文中の用語を用いること。
模範解答
社員(社員コード,社員氏名)
組織(組織コード,組織名,上位組織コード)
社員所属(社員コード,所属組織コード,役職コード,報告先社員コード)
役職(役職コード,役職名)
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 部分関数従属性と推移的関数従属性を排除し、4つの関係を正しく導出できている。
- 1点: 正規化の過程に一部誤りや不足がある。
- 0点: 正規化が正しく行われていない。
論理性(構造)(2点)
- 2点: 分解後の関係において、主キーと外部キーの構造が論理的に正しく設計されている。
- 1点: 主キーや外部キーの構造に一部不備がある。
- 0点: 構造の論理的整合性が保たれていない。
解説
解答の導出と根拠
第3正規形への分解は、すべての 部分関数従属性 と 推移的関数従属性 を排除するプロセスです。関係“社員所属”から、「社員」「組織」「社員所属」「役職」の各エンティティに情報を分離し、それぞれ独立した関係スキーマを構成します。
高得点のポイント
社員、組織、社員所属、役職の4つの関係に正しく分解できていること。
それぞれの関係において適切な主キーと非キー属性が設定されていること。
分解後の関係名に本文中の用語を正確に使用していること。
設問2
現行業務の概念データモデル及び関係スキーマについて答えよ。
(1)
図1中の欠落しているリレーションシップを補って図を完成させよ。なお,図1に表示されていないエンティティタイプは考慮しなくてよい。
模範解答
取引先
得意先
仕入先
取扱い
ブランド
ブランド
品目分類
品目
発注
入荷
発注明細
入荷明細
見積回答
見積回答
明細
見積依頼
見積依頼
明細
試作案件
品目
モデル
試作案件
モデル
構成品目
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 欠落している全てのリレーションシップを業務要件に基づいて正しく特定できている。
- 1点: リレーションシップの一部のみ特定できている。
- 0点: 欠落しているリレーションシップを正しく特定できていない。
論理性(構造)(2点)
- 2点: エンティティ間の多重度や依存関係が論理的に正しく設定されている。
- 1点: 多重度や依存関係の一部に誤りがある。
- 0点: 論理的な関係性が設定できていない。
解説
解答の導出と根拠
現行業務の状況記述と概念データモデル(図1)、関係スキーマ(図2)を照らし合わせ、欠落しているリレーションシップを分析します。
特に「仕入先」から「見積依頼」へのリレーションシップや、「品目」から「見積回答明細」へのリレーションシップが不足しがちであるため、業務要件を的確に読み取ることが重要です。
高得点のポイント
状況記述および既存のスキーマから不足情報を正しく分析できていること。
エンティティ間の 対多 のリレーションシップを正確に補完できていること。
(2)
図2中の a に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
試作案件番号
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 試作案件番号が適切に補完されている。
- 1点: 関連する属性を挙げているが正答ではない。
- 0点: 適切に補完されていない。
論理性(構造)(2点)
- 2点: 主キーおよび外部キーの参照関係を論理的に正しく理解して解答できている。
- 1点: 参照関係の理解が部分的に不足している。
- 0点: 参照関係を理解できていない。
解説
解答の導出と根拠
図2の関係スキーマにおける空欄aを補完します。この関係は試作案件に関連する情報を保持するため、主キーあるいは外部キーとして「試作案件番号」が必要となります。
高得点のポイント
- 該当するエンティティの依存関係を理解し、「試作案件番号」を正確に導出できていること。
(3)
図2中の b に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
得意先支給数量,必要調達数量
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 得意先支給数量と必要調達数量の両方が適切に補完されている。
- 1点: どちらか一方のみ適切に補完されている。
- 0点: 適切に補完されていない。
論理性(構造)(1点)
- 1点: エンティティの持つべき情報要素の構造を論理的に理解できている。
- 0点: 構造の論理的理解が不十分である。
解説
解答の導出と根拠
図2の関係スキーマにおける空欄bを補完します。構成品目に関する数量管理情報として、「得意先支給数量」および「必要調達数量」の属性が必要となります。
高得点のポイント
- 構成品目エンティティに必要な数量管理属性を過不足なく補完できていること。
(4)
図2中の c に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
取引先コード,試作案件番号
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 取引先コードと試作案件番号の両方が適切に補完されている。
- 1点: どちらか一方のみ適切に補完されている。
- 0点: 適切に補完されていない。
論理性(構造)(1点)
- 1点: テーブルの依存関係に基づく外部キーの設定を論理的に理解できている。
- 0点: 論理的理解が不十分である。
解説
解答の導出と根拠
図2の関係スキーマにおける空欄cを補完します。見積や手配に関連する情報を特定するため、「取引先コード」および「試作案件番号」が外部キーとして必要になります。
高得点のポイント
- テーブルの依存関係を正しく把握し、必要な外部キー属性を補完できていること。
(5)
図2中の d に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
見積依頼番号,メーカー型式番号,ロットサイズ,提案理由
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 見積依頼番号、メーカー型式番号、ロットサイズ、提案理由の全てが適切に補完されている。
- 1点: 必要な属性の一部が欠落している。
- 0点: 適切に補完されていない。
論理性(構造)(1点)
- 1点: 複合キーの構成および非キー属性の配置が論理的に妥当である。
- 0点: 配置の論理性が欠如している。
解説
解答の導出と根拠
図2の関係スキーマにおける空欄dを補完します。見積回答明細においては、仕入先間で明細番号が重複し得るため、「見積依頼番号」を含めた複合キーとする必要があります。加えて、「メーカー型式番号」「ロットサイズ」「提案理由」が属性として含まれます。
高得点のポイント
見積回答明細の主キーが「見積依頼番号」との複合キーになることを状況記述から正しく読み取れていること。
必要な非キー属性を過不足なく補完できていること。
(6)
図2中の e に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
見積依頼番号,見積回答明細番号,発注ロット数
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 見積依頼番号、見積回答明細番号、発注ロット数が全て補完されている。
- 1点: 属性の一部が欠落している。
- 0点: 適切に補完されていない。
論理性(構造)(1点)
- 1点: 見積回答明細に基づく発注関係のデータ構造が論理的に正しく構成されている。
- 0点: データ構造の論理性が不十分である。
解説
解答の導出と根拠
図2の関係スキーマにおける空欄eを補完します。発注処理に関する明細情報として、「見積依頼番号」「見積回答明細番号」および「発注ロット数」が必要となります。
高得点のポイント
- 発注と見積回答明細の関連性を理解し、参照関係に基づく適切な属性を導出できていること。
設問2では,(1)の正答率が低かった。“仕入先”から“見積依頼”,及び“品目”から“見積回答明細”への1対多のリレーションシップが記入できていない解答が散見された。状況記述や概念データモデル,関係スキーマから不足している情報を的確に分析し,解答するようにしてほしい。また,(2)dの正答率が低かった。主キー属性として見積依頼番号を記述できていない解答が目立った。見積回答明細番号は仕入先間で重複し得ることから,“見積回答明細”の主キーは,見積依頼番号との複合キーとなることを状況記述から読み取ってほしい。
設問3
〔利用者の要望〕への対応について答えよ。
(1)
“1. 品目分類の階層化”に対応できるよう,図1の概念データモデルでリレーションシップを追加又は変更する。該当するエンティティタイプ名を挙げ,どのように追加又は変更すべきかを,30字以内で答えよ。
模範解答
品目分類に自己参照型のリレーションシップを追加する。
品目分類に再帰リレーションシップを追加する。
品目分類から自分自身へ1対多のリレーションシップを追加する。
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 品目分類の階層化に必要な自己参照型リレーションシップの追加を正しく指摘できている。
- 1点: 階層化の意図は理解しているが、リレーションシップの表現に不備がある。
- 0点: 適切に理解していない。
論理性(構造)(2点)
- 2点: 対象となるエンティティタイプ名と変更内容が論理的かつ指定文字数内で正しく記述されている。
- 1点: エンティティタイプ名か変更内容のいずれかに論理的な誤りがある。
- 0点: 論理的に正しく記述されていない。
解説
解答の導出と根拠
「品目分類の階層化」に対応するためには、品目分類自身の中で親子の階層関係を表現する必要があります。これには、同一エンティティ内で上位のレコードを参照する 自己参照型(再帰)リレーションシップ の追加が適しています。
高得点のポイント
「品目分類」エンティティを対象とすることを明記していること。
自己参照型リレーションシップ(または再帰リレーションシップ)を追加する旨を簡潔に表現していること。
(2)
“1. 品目分類の階層化”に対応できるよう,図2の関係スキーマにおいて,ある関係に一つの属性を追加する。属性を追加する関係名及び追加する属性名を答えよ。
模範解答
関係名: 品目分類
属性名: 上位品目分類コード
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 関係名「品目分類」と追加属性「上位品目分類コード」の両方を正しく特定できている。
- 1点: 追加すべき関係名と属性名のいずれかが誤っている。
- 0点: 正しく特定できていない。
論理性(構造)(2点)
- 2点: 階層構造を実現するための自己参照外部キーの構造を論理的に正しく定義できている。
- 1点: 階層構造の論理的定義に一部誤りがある。
- 0点: 論理的に正しく定義できていない。
解説
解答の導出と根拠
自己参照型リレーションシップを関係スキーマに実装するためには、親となるレコードの主キーを外部キーとして自テーブルに持たせる必要があります。したがって、「品目分類」関係に「上位品目分類コード」という属性を追加します。
高得点のポイント
属性を追加する関係名として「品目分類」を正しく挙げていること。
追加する属性名として階層関係を示す「上位品目分類コード」を正しく挙げていること。
(3)
“2. 仕入先からの分納”に対応できるよう,図1の概念データモデルでリレーションシップを追加又は変更する。該当するエンティティタイプ名を挙げ,どのように追加又は変更すべきかを,45字以内で答えよ。
模範解答
発注明細と入荷明細との間のリレーションシップを,1対1から1対多へ変更する。
採点基準(配点 4点)
知識・理解度(内容)(2点)
- 2点: 発注明細と入荷明細間のリレーションシップを1対1から1対多に変更すべきことを正しく指摘できている。
- 1点: 対象エンティティは特定できているが、多重度の変更内容が不明瞭である。
- 0点: 正しい変更内容を指摘できていない。
論理性(構造)(2点)
- 2点: 分納対応に伴うデータ構造の変化を論理的かつ適切に説明できている。
- 1点: 説明の論理展開に一部飛躍や不足がある。
- 0点: 論理的な説明になっていない。
解説
解答の導出と根拠
「仕入先からの分納」に対応するためには、1回の発注に対して複数回の入荷が行われることを許容する必要があります。現状の概念データモデルでは発注明細と入荷明細が 対 になっていますが、これを 対多 に変更することで分納を表現できます。
高得点のポイント
発注明細と入荷明細のリレーションシップを対象とすることを明記していること。
リレーションシップの多重度を 対 から 対多 に変更する旨を論理的に説明していること。
(4)
“2. 仕入先からの分納”に対応できるよう,図2の関係スキーマにおいて,ある二つの関係に一つずつ属性を追加する。属性を追加する関係名及び追加する属性名をそれぞれ答えよ。
模範解答
①
関係名: 発注明細
属性名: 発注残ロット数
②
関係名: 入荷明細
属性名: 入荷ロット数
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 発注残ロット数と入荷ロット数の追加対象関係を両方とも正しく特定できている。
- 1点: 一方の追加対象関係のみ正しく特定できている。
- 0点: 正しく特定できていない。
論理性(構造)(1点)
- 1点: 発注と入荷の差分管理に必要な属性の配置が論理的に妥当である。
- 0点: 属性配置の論理性が欠如している。
解説
解答の導出と根拠
分納に伴う発注残数を管理するためには、全体の状況を保持する「発注明細」側に「発注残ロット数」を、個別の入荷実績を記録する「入荷明細」側に「入荷ロット数」をそれぞれ追加する必要があります。これにより、入荷の都度発注残を更新する業務プロセスが実現可能になります。
高得点のポイント
発注明細に「発注残ロット数」を追加することを正しく特定できていること。
入荷明細に「入荷ロット数」を追加することを正しく特定できていること。
設問3では,(2)(b)の正答率が低かった。分納によって発注残ロット数を導出するためには,入荷ロット数を新たに追加する必要がある。利用者の要望を受けてデータモデルを変更することは,実務でもよくあることである。利用者の要望に応えるために必要な情報は何か,不足はないか,日常業務でも常に考えてみてほしい。