【14個の特異点】デスペ令和6年秋午後2問2の解説（データベーススペシャリスト）

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

後半が難しいです。スキーマ作りに直接繋がる記述と、繋がらない/リアル作業の記述が混在し、ノイズに混乱/保留にもやもやしました。さらに「区分」「冗長」「正規化」など珍しい/実データまで考えるケースもあり、ちょいちょい失点します。

次回の令和6年秋の方が素直でした。＞DB令和6年秋午後2問2の解説Note

解説作りも難航し2週間かかりました。いつの間にか図解は100枚超え。周回する度に「そんな意図があったか」「ここまで考えるのか」と深みにどんどんハマりました。

かなり書き込みましたが、まだ勘違いや浅い点があるかもしれません。申し訳ないです。ただ、どこよりも詳しく書けたと思います。

ひとまず75点以上が取れるぐらいに、演習で慣れるのを目標にしてください。失点仕方なしは無視して大丈夫です。本試での時間制限/緊張の中で得点するのは不可能です。

午後2に取り組む前に、必ず午後1を演習してください。

• 問題文→スキーマ

• スキーマ→ER図

• 既存ER図→スキーマ

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

それでは始めましょう！

＞14個のDB午前テーマ別解説Note
＞4ヶ月の勉強記録Note
＞DB午前1の問題解説マガジン
＞DB令和6年秋午後2問2の解説Note

※このNoteは2025/10本試験まで無料公開します。本試験以降はマガジンに統合されます。データベース設計だけ作ります。

Noteの目的

午後2のDB設計は、時間がギリギリです。

問題文からスキーマを設計し、スキーマとER図を「ざっくり」整合させるので精一杯。具体的データで考えたり、ゼロから正規化して同じ設計になるかは確認できません。

解説として理解するために、一部は具体的データや論理で「軽く」考察しますが、あくまで「おまけ」。本試中にそんな時間はなく、あくまで演習経験/地頭育成のために取り扱います。

このNoteの目的は以下です。

• 本試と同じように解く
  問題文を読みながら試験中の思考/作業をなぞります

• 次回は8割以上正解したい
  正解すべき/失点止む無しの優先順を設けます

• 未知問題への解決能力を育成したい
  多少の考察/攻略法を考えます

以下は考えていません。

• ゼロから設計して同じ設計になるか

• 実働の確認・運用効率の確認

このNoteは、以下のような方には合いません。

技術志向の大変高い方「自分だったらこう設計する」「実用考えたらこう設計する」など。「資格者は実務で使えない」「資格は実務に役立たない」など資格試験について懐疑的な方/合格戦略の洗練に抵抗感のある方。持論に反した場合、SNSに流布/批判たい方。専門学校/大学など教育機関に反感をお持ちの方。

私の力不足/役不足で、ご満足いただける解説はできません。大変申し訳ないですが、他サービスをご利用ください。

プライベート時間を全てつぎ込んで、Noteを一所懸命作成させて頂いています。好きで作っているのは確かですが、よそ様に否定される理由もないと考えております。

このNoteは2週間の時間/手間をかけて作成しました。小ばかにする方はご遠慮頂けますと幸甚です。

どうぞご理解下さい。

宜しくお願い致します。

このNoteの魅力

問題文を一緒に読みながら解いていきます。

空欄埋めやER図繋ぎだけでなく、全文/全スキーマ/全ERについて考えて行きます。その上で本試験でどこまで点を狙うか、今後にどう生かすかを提案していきます。

また全体を俯瞰できる図解も用意しました。

まずはミクロ視点ボトムアップ。分からなかった部分が、問題文のどこで判明するのか明記しています。理解を積み上げるご参考に。

次はマクロ視点トップダウン。

ER図全体からスキーマ全体の整合性を見ます。主キー/外部キーの組み方/つなぎ方を図示。明細/サブクラスや1対1/多・連関エンティティなどでの傾向がざっくり分かります。

解説では補強も行います。階層を実現する自己参照モデル、区分/分岐がなかったスキーマなど、別過去問の出題実績を添えて紹介。

Note最後では、この問題ならではの特異点を列挙。今回のスキーマ/ER図の特異な点をノウハウとして手持ちし、今後の奇襲に備えます。

前置きが長くなりました。宜しくお願い致します。

1(1)①② BP | 階層＝自己参照 じゃなかった

BPスキーマは完成済。
問題文から完成できるのを確認。午後1で培った解法ですね。

仕入れ先が3種類あるので「区分」を設けて、ER図も△分岐させると思いました。しかし、完成されたBPスキーマに区分はなく、ER図にも分岐はなさそうです。致命的ではないので構いません。

もし個別の仕入れ先種（例えば製造メーカー）だけで、記録すべき項目があれば、スキーマ/エンティティを作ったでしょう。また今回の在庫管理/配送には、仕入れ先種は関係しないんでしょうね。

1(2)①②③ 配送地域 | 括ったもの

配送地域スキーマは完成済み。問題文との食い違いもありません。

ただし「配送地域は、複数の郵便番号を～」より、別スキーマとの「1対多」の関係が窺えます。1つの配送地域と複数の郵便番号を紐づけるスキーマがあるかなと推測。次節へ。

1(2)①② 郵便番号【ア】

郵便番号絡みはないかなぁと図3スキーマを確認。郵便番号スキーマが見つかります。

ER図で「1対多」で繋がっているので、多側の郵便番号【空欄ア】に外部キー追加。

具体的データを考えて確認も。

補強 | 連関エンティティの可能性

1(3)①② 店舗 | 区分＝ER分岐 じゃなかった

「店舗スキーマ」は未完成。しかし、問題文の項目&キーは全て書かれていました。追加できず残念。

今後の【空欄キ】が焦点。

ER図の話。外部キー「配送地域コード」で「配送地域」と繋がります。ER図で「1対多」で既に繋がってるのでOK。

また「b」や「店舗在庫」とも繋がってますが、今は保留。

「区分」が2つ「床面積区分」「立地区分」。△分岐するか。でも図4見るとありませんでした。残念。

設問(1)～(3)に「エンティティの欠落/補充」の話はないので、追加不要。仕入れ先種と同じ理由で、今回のテーマに無関係なんでしょう。残念。

【空欄キ】,「b」,「店舗在庫」と保留が多いですね。

1(4)① 物流拠点【イ】

「物流拠点スキーマ」は未完成ですが、問題文の情報&キーは、全て書かれてました。前節「店舗」と同じく残念。

ER図では「配送地域」と「1対多」。【空欄イ】には「配送地域コード」が入るでしょう。

1(4)②③④ DC, TC【イ】

②～④では「DC」「TC」を、物流拠点から「フラグ」で繋げるのが分かります。「DC」の【空欄ウ】、「TC」の【空欄エ】への項目情報はなし。

ER図。物流拠点との接続は「フラグ」。<<DCでありTCである場合もある>>旨より「共存的サブタイプ」なので。

補強 | フラグor区分

1(4)⑤ | 一旦保留

TCの役割（積替）。現状スキーマやERへの適用ないので、一旦保留。

要は複数のDCからの荷物を、TCで1台のトラックに積み替えること。

1(4)⑥ TC, DCの個数対応/ER図

「1か所」「複数」の個数対応の記述があるので、ER図と食い違いがないか確認。DC「1対1」、TC「1対多」。問題なし。

以上より、「物流拠点」のスキーマとER図周辺が完成しました。

1(4)⑦⑧ DC, TCの項目【ウ, エ】

「DC」の【空欄ウ】、「TC」の【空欄エ】への項目追加。

「物流拠点E」の一機能なので、主キー「拠点コード」を引き継ぎ、少し改名。また、DCとTCに独自項目「倉庫床面積」「委託先物流業者名」を追加。

「DC」「TC」の主キーに「物流拠点」の「拠点コード」を流用しますが、「DC」では”DCの拠点コードだけ”を主キーにするので「DC拠点コード」と改名。「TC拠点コード」も同様。

「DC」「TC」に更に項目追加するかは、ER図で繋がってる「DC保有アイテム」「a」「b」が完成するまで保留。

1(5)① 幹線ルート/支線ルート【a, b】

組織/施設は終わって、配送ルートの話。

問題文から「幹線ルート」は<<「DC」と「TC」を紐づける＝ER図でリレーションで繋がるはず>>と推測。2つ繋がるのが「DC」、ER図の「a」。

「a=幹線ルート」「b=支線ルート」で良さそう。

「DC」と「a」、「TC」と「a」「b」のリレーション/個数対応は3(1)まで保留。

1(5)① 幹線ルート【オ】

「幹線ルート」スキーマは、残念ながら決まり切りません。

保留が溜まってきたので、少しでもER図から推測しておきます。

DC→幹線ルートの個数対応について。
分かりにくいので、なんとなく「1対多」で繋いでもOKです。形から「連関エンティティっぽいのでDC[1]-[多]a[多]-[1]TC」と推測できますし。

分かりにくいですが、弱い根拠として1(4)⑤。
「TCは、各店舗に複数のDCから～到着する混乱を防止するために、積み替える」は、<<1つのTCから1店舗に配送する>>旨、<<1つのDCは複数店舗に配送する>>旨と解釈できます。後者の解釈が「1対多」をサポートはします。

1(5)② 支線ルート【カ】

1(5)②で「支線ルート」の項目が分かります。「幹線ルート」がもやもやしたので助かりますね。

問題文からスキーマを組み上げ、キーが他スキーマと共通かを見て、ER図を接続すべきか考える流れ。

「TCごと」「支線ルートコードで識別」から複合主キー。

「TC」と「支線ルート」は「1対多」。1つのTCから複数の支線ルートが出る。例えば1つの郵便局からポストを巡回するルートが複数あるようなもの。

1(5)② 支線ルートの2項目【キ】

ただし「配送先店舗」と「配送順」を、「支線ルート」に組込むのはかなり考え物。非正規形になってしまいます。

しかし、道順らしきスキーマ/エンティティは見当たりません。

データを具体的に考えて、やっと考え至りました。とはいえ、本番ではそんな暇はないし、仮に導けても自信をもって解答できるか微妙…。

既存ER図の通り「支線」と「店舗」は「1対多」なのも納得。

2(1)①⑤ 商品カテゴリー【ク, ケ, コ】

商品カテゴリーの項目は問題文から確定。

「階層」構造なので、リレーションを自分に返す「自己参照」かと予測しますが…。ER図では、商品カテゴリーの各種（部門, ライン, クラス）が個別に書かれてました。

シンプルに描きます。
①3種類だから分岐する
②階層構造だから「1対多」で繋げる

スキーマ。
①共通項目を「商品カテゴリー」に残す。
②各種に独自項目を追加。「部門」に「売上比率」、「ライン」「クラス」に上位カテゴリーへの外部キー。

ER図を見て、現状繋がってるものはないので、一旦終了。接続があれば外部キーを組み込むか考えましたが。

2(1)②③④

おそらく、2(1)①「木構造」で「1対多」と発想できなかった人のために、具体例で「1対多」になることを教えてくれたのかも。

私は<<具体例で、直接はスキーマ/ER図に関係しないのでスルー>>と判断しました。

補強 | 分岐書きと自己参照

階層構造をもつデータについて、今回の分岐書きと自己参照での具体的データを見てみます。どちらでも実現可能なのを学びたいです。

まずは模範解答の分岐書き。4つの表を作る実現法。

次は自己参照。表は1つだけです。

＞DB令和5年秋午後1問1の解説Note

＞DB令和6年秋午後2問2の解説Note