デスペ令和7年秋午後1問2の解説（データベーススペシャリスト）

このNoteでは「データベーススペシャリスト 令和7年秋午後1問2」の解説をします。

問1に続いて問2も設計なのは良かったです。問3はSQLなので、私は即切り。

とはいえ、結構綱渡りな部分も多く、点数幅は広いかも。

設問1の正規形の定義/論理は、デスペならではですね。久々に見ました。「部分関数従属」や「推移的関数従属」など、テキストで読み飛ばし、感覚で正規化してきた方は、しっかり覚えましょう（私も受験勉強時に1敗して考え改めました💦）

さらに今回の問題。未完成/間違ったスキーマがあります。半端に載せるぐらいなら、空欄にして埋めさせて欲しいと思いました。間違いを理解する方が面倒。ゼロベースから組んだ方が速いですから。

このNoteには、ガッチリ解き筋を書きました。

私のNoteは、独学合格した経験と、IT専門学校での授業内容を基に作っています。

私の午前/午後解説や4ヶ月勉強記録に興味が出ましたらどうぞ。

＞14個のDB午前テーマ別解説Note
＞DB午後問題の解説Note
＞4ヶ月の勉強記録Note

ひとまずいつもの設計の手順で

設問1(1)が【商談参加従業員E】のスキーマ設計なので、問題文を読んでDBの目的/設計思想を理解せねばなりません。

結局、問1設計と同じく、問題文からスキーマを組み立て、スキーマと個数対応からER図を仕上げる手順 は変わりません。

なお、問題文を読む時はマーキングをして下さい。＞長文問題を読む６つのテクニックNote（３－４）

• 四角：エンティティ、項目

• 丸囲：個数対応（リレーションで使う）

• 丸囲：制約の記述（一意など）

詳しいマーキングや解法は、＞【決定版】デスペ令和4年秋午後1問1（図解59枚）の解説Note

1(1) | なんで【従業員E】作らんの？

問題なしですが、スキーマもER図もないので違和感あり。最初の最初なので、今後の取り扱い次第かなと。大したことないかもだけど一応保留で◀印。＞長文問題を読む６つのテクニックNote（３－３）

そしてちゃんと設問に絡んできました…。◀印しといて良かった。＞長文問題を読む６つのテクニックNote（３－３）

1(2) | 完成済みは軽く確認, 今後は外部キーに注意

スキーマ完成済みで問題なし。

ER図に接続があるので、接続先【得意先担当者E】に【得意先コード】が外部キー（兼主キーなので実線表記）設定されてる確認。個数対応も複合主キーで「1対多」となり妥当。

留意事項「取引」絡みのエンティティが今後登場するでしょう（実際、案件, 見積, 契約などあり）。◀印するかはお好みで、私はこれぐらいならしないかなぁ。どうせ後述されるでしょうし。

【得意先E】が他エンティティにも繋がる可能性は残ります。ないと言える根拠がないので。【得意先E】の主キーが、他エンティティにあれば要検討。

1(3) | 複合主キーへの表現

スキーマに問題なし。「ごと」「識別」から複合主キーにも納得。

留意❶【得意先担当者E】が他エンティティと繋がる可能は残る。

留意事項❷「1対多」なので、【得意先C】【担当者C】に更に主キーを追加するはず。でも網掛けなので、最後まで分からなそう。
※多分【案件コード】【商談開始年月日時分】を加えた4個。

2(1)(2) | 項目名の特定

スキーマ完成に問題なし。少し解釈しますが。

一瞬、仕様絡み（配合比率, 添加物）の設置に迷うけど、2(2)で解決したので良かったです。

2(3) | 保留項目と少しの推測

【契約E】に契約した製品や得意先が組み込まれてない。

たぶん外部キーにした【見積E】経由で引っ張ってくるんでしょう。【見積E】の記述待ち。

3(1) | 問題文に忠実に/少し疑問残る

スキーマの書き起こしに問題なし。

しかし発生が、問合せ→案件→契約&販売 だと思うけど、記録するのが問合せ開始（=案件開始）と販売終了（=案件終了）で広すぎでは？ 契約できなかった場合の記憶などは大丈夫かな？ 【契約E】の記述次第かな？

などなど疑問が出ます（結局解決しませんでしたが）。

3(1)② | 個数対応の表現

【製品E】→【案件E】の「1対多」は、問題文を読んでまぁ大丈夫。

問題は【得意先担当者E】から【案件E】に繋ぎたくなる件。保留。

3(1)② | 得意先から接続は難しいなぁ

解くのが難しい、というか正直反論したいです。

復習なので、模範解答の理解から始めます。

問題文によると【得意先担当者E】から「1対1」で繋いで、【案件E】の【空欄b】に【得意先コード, 担当者コード】を外部キー組込みすれば良いように思えます❶。

しかし❷❸のように主体/DB更新事情に注目すれば、人ベースの担当者よりも、組織ベースの得意先であるべきとは理解できます（できなくもない程度）。

でもふと、"案件から問合せしてきた得意先担当者を特定できないよなぁ"と思いました。100%商談に進むから記録する必要がないのかなぁ。

でも"いついつに商談しましょう！"って打診できないですよね。得意先に"～製品について問合せを頂い担当者様へのお取次ぎをお願いします"とは言えないですよね。"弊社の誰でしょう"と聞かれて"分かりません"って。

すみません。解決しませんでした（時間があったら再考しますね＊）。

3(1)③ | NULL値への考慮

特に問題はないかなと。

3(2)①② | 物語のコア（案件）

3(2)①は理解できます。【従業員E】がないので作業なしですが。

3(2)②のスキーマ確認も問題なし。ただキー設定がない。ER図を繋ぐ時に検討すれば良いのかな。

ただしちょっと気持ち悪い部分もあり。