【デスペ】令和2年秋午後1問1の解説（データベーススペシャリスト）
このNoteでは、DB令和2年秋PMI問1の解説をします。
データベース設計は、問題文からスキーマとER図を完成させる作業がメイン。今回は2回やる形でした。＞令和5年午後1問2の解説Note と同じ形態。
大きな特徴は「発注」「納入」「生産」「配送」にそれぞれ「明細」があり、かつそれぞれの絡みも考える点。そもそも繋げるのか「1対1」「1対多」なのかはケースバイケースなので、問題文から注意深く情報を集めねばなりません。
ER図も午後2のように多重で複雑なものです。より多くのスキーマとリレーションを扱う練習になる問題でした。
ぜひ午後2のデータベース設計へのステップのために生かして欲しい問題です。丁寧にじっくり解いて、深く復習してくださいね。そしてゆくゆくは手早く正確に解けるようになりましょう。
このNoteは、私が独学合格した経験と、IT専門学校での授業のノウハウで書いています。合格のお手伝いに少しでもなったら嬉しいです。
それでは始めましょう！
説明1(2) | 問題文→スキーマ
設問1(1)がER図完成、設問1(2)がスキーマ完成で、他に変わった施文がないのを確認したら、順番を変えて「スキーマ完成→ER図完成」で解いていきます。なぜならER図でリレーションを繋ぐかどうかは、スキーマ内の外部キーで判断しますからね。
読み進めれば、穴埋めaとcは自然と埋まります。
今回特徴的なのは「拠点コード」。拠点に製造工場と店舗があるので、IDを共有しています。つまり、ある拠点の店舗を指す時も、工場を指す時も同じ拠点コードで指します。
また配送ルートについて「2～3時間」「3～6店舗」は数値なので丸囲み。何か問われたり変更したりしたら面倒だなぁと思いつつ。
穴埋めbができます。順番が前後しましたが、よくあることです。
2(3)の工場での自社商品の生産について。
生産（工場拠点コード, 生産商品コード）かなと思いますが、「工場は全ての自社商品を生産する」より、不要だと理解します。工場と販売を各拠点で独立で行っているんですね。
午後1レベルなら「拠点区分」など問題文に明記するので、追加するかは慎重に判断します。午後1「ていど」なら、書いてない項目を追加することは、まずないです。
穴埋めア：発注とd、イ：発注明細とeが埋まります。
3(1)②で「多分、発注と発注明細なんだろうな」と思いつつも自信がなかったので、3(1)④になって確定したので良かったです。
「締め時刻」は、配送を受ける時間なので、実質注文を受け付ける時間になりますね。「締め時刻」を記録すべきか考えましたが、毎日固定の時間だと判断して項目にはしません。
「発注数量にマイナスの値を設定」は、一度入力したデータを訂正・取り消しする際の「王道」処理。一度登録した情報をごちゃごちゃ変更するのはトラブルの元ですし、取引の経緯を残しておきたいので。
ただし、発注数量の合計がマイナスにならないかはチェックが必要です。
マイナスの値は数量だけではありません。支払い金額でも、払い戻しの場合にも使えます。
穴埋めfとgが解決します。
この問題でスキーマの穴埋めは「～に一つ又は複数の適切な属性名を入れ」なので、1つだけとは限りません。fとgに1つだけ入りましたが、「他に入れるべき属性はないかな」と油断しないよう注意です。
発注を集計する処理、生産数を決定する処理が書かれています。SQLやプログラム系の問題が出る場合に備えて「▼マーキング」をしておくと良いですね。
穴埋めhとgが決まります。gは前回解決していますが「矛盾してないか」確認はします。
ここでも発注を集計する処理があります。一応マーキング。
なお「発注明細」スキーマに「配送番号」を記録する旨もあります（次でまとめておきます）。
3(1)で作った「発注明細」に属性を追加します。
後の記述になって項目追加はよくあること。「設計終わったー」と気を抜かないでくださいね。
これにてスキーマは完成です。
既に完成しているスキーマは軽く確認・変わったことがないか確認。未完成のスキーマは問題文の明記されているスキーマ名と項目で構成します。キー制約も「識別」なら主キー、他スキーマと見ているなら外部キーにします。個数対応は次のER図作成で考えるので流してOKです。
説明1(1) | スキーマ→ER図
スキーマが完成したので、外部キーを見ながらER図を作っています。
ER図作りは、「Ａスキーマ（Aエンティティ）から発するリレーションあるかな」と1つずつ見ていきます。「AエンティティとBエンティティを繋ぐかな」と組み合わせでは見ません。
組み合わせで見ると作業量が増えてしまいます。AスキーマとBスキーマを見る作業、AスキーマとCスキーマを見る作業、BスキーマとCスキーマを見る作業で、スキーマを見る作業が組み合わせで6回になってしまいます。一方、1つずつ見るなら3回で済みます。
では「拠点スキーマ」。「区分」があるので「股あり△」があるか確認。次の「生産工場スキーマ」には、外部キーはないので繋ぎません。
「生産工場」からリレーションは繋ぎませんでしたが、図のように「配送ルート」「生産」と繋がっているので、外部キー参照されているはずです。今回だけチラっと見ておきましょうか。
配送ルート（ルート番号, ルート名称, 製造工場拠点コード）
生産（生産番号, 製造工場拠点コード, 生産完了予定日時, 生産完了日時）
ちゃんとありますね。なので「ER図でつながってるけど」と思いつつも、「後で確認するので放置」でOK。「配送ルート」と「生産」を考える時に解けば良いです。
「店舗」スキーマ。拠点コードは「拠点」スキーマから引き継いでるので、主キーであり外部キーでもあります。
スキーマでは、主キーは下実線、外部キーは下破線ですが、主キーでも外部キーでもある時は下実線（下破線なし）です。5頁の2-(1)③に明記されています。DBでは常識なので「主キーは外部キーでもあるかも」と注意。
「自社商品」に外部キーなし。模範解答では3本引かれてますが、気にせず進めてください。
「配送ルート」に外部キーがあるので、「製造工場」と繋がっているのを確認します。この時点では「店舗」と繋げるべきかは分かりません。「店舗」スキーマを見た時に判断します。
「発注」と「発注明細」。新たに引くリレーションが多いです。
簡単な「発注」から。「店舗拠点コード」があるので、店舗と繋ぎます。1つの店舗から多くの発注がでるはずなので「1対多」。
「発注明細」行きます。多いですね。
「発注」の「発注明細」なので「1対多」
1つの「自社商品」が多く発注されるので「1対多」
1つの「生産明細」は、色んな店舗からの発注を集計した指示なので各店舗ごとの「発注」及び「発注明細」と「1対多」（7頁3(2)①、10頁2(4)①と②）。またはそもそも発注明細が1つの発注で減らしたりキャンセルしたりで複数登録される可能性が高いこと（7頁3(1)②）。
1つの「配送明細」は、発注明細が1つの発注で減らしたりキャンセルしたりで複数登録される可能性が高いこと（7頁3(1)②）。店への配送は1回ですが、1商品でも発注明細は複数登録される可能性があります。
明細から明細への「1対多」は、かなり難しい判断でした。
簡単な「生産」から。「生産工場」で多くの生産が行われるので「1対多」。
次は「生産明細」。「生産」の明細なので「1対多」。1つの「自社商品」が多く生産されるので「1対多」。
「配送」は、1つの「店舗」から多くの「配送」がされるので「1対多」。
「配送明細」は、「配送」の明細なので「1対多」。1つの「自社製品」が多く配送されるので「1対多」。
以上で、スキーマ→ER図の作業は終わります。
図のように、考えたスキーマのリレーション部分に印を付けると良いです。
設問2 | 問題文→スキーマ
基本的には、問題文→スキーマ→ER図 の順番で解くと良いですが、既に完成してるER図や区分程度なら確認しても大丈夫です。
「自社仕様商品」が「自社商品」「委託商品」に分類されていると読み取れます。
「工場」も「自社工場」と「委託工場」で親子になっています。
各サブクラス（委託工場, 自社工場）に独自に記録する項目があるかは重要です。
拠点コードに「物流センタ」の採番も追加する話。今まで「工場（委託工場と自宅工場）」の2股だったので3股にします。
「股あり△」でサブクラスを作る時、親クラスに「区分」項目を作るのが一般的です。
しかし、図4で既に完成している「工場」スキーマにありません。そもそも各拠点に工場と店舗が混在しているので「この拠点には工場、この拠点には店舗」と区別する必要がないので、今回の物流センタの区分も不要だったのだと解釈します。
「納入ルート」「配送ルート」を追加する話。「納入ルート」の説明が書かれているのでスキーマを作ります。「配送ルート」は、記述と出会うまで保留です。
オとカのどちらが「納入ルート」「配送ルート」かは迷いますが、完成しているER図がヒントなのかなと推測し、店舗と工場のどちらに繋がっているかで判断しておきます。後で矛盾が出たら訂正します。
「納入」と「納入明細」のスキーマは既に完成しているので確認程度。「変わったことはないかな」と少し考えるぐらい。
「発注明細」に「納入番号」が追加されるのは、問題文にマーキングして図4にもすぐに書き込んでください。忘れますから。
「納入ルート」で保留にしていた「配送ルート」を完成させます。「配送ルート」は元々図2で完成していましたが、「納入ルート」の追加によって、「ルート」を親クラス・子クラスに「配送ルート」「納入ルート」として再構成します。
スキーマの再構成によって、「ルート」に「ルート名称」があるので、「配送ルート」から「ルート名称」を削除、問題文により「物流センタの拠点コード」を追加します。
説明2 | スキーマ→ER図
スキーマが完成したので、外部キーを参考に繋げていきます。個数対応は問題文に特別な記述がないか確認して、なければ一般常識で判断します。
「ルート」「配送ルート」「納入ルート」は既に仮置きしました。
「工場」「委託工場」「自社工場」の親子クラスもすでに書きましたね。「区分」項目がないのは珍しいケース。
「物流センタ」の「拠点コード」は「拠点」を見ているので繋がっています。「ルート」には外部キーがないので追加で繋ぐ必要はありません。
「配送ルート」は「ルート番号」が「ルート」を見ており、「物流センタ拠点コード」が「物流センタ」を見ています。個数対応は、1つの「物流センタ」は多くの「配送ルート」を持つので「1対多」。
すごく難しい話をします。飛ばしてもOK、というか飛ばしてください。ものすごく混乱しますよ。
「配送ルートEと納入ルートEに物流センタ拠点コードがあるなら、まとめてルートEに入れれば良い」と思わなかったですか？
これは最後の設問2(3)にも絡むのですが、自社工場生産品の配送と委託工場生産品の配送が違うからです。
この時点では、「図4で既に完成しているルートEに物流センタ拠点コードがないから、しゃーないから配送ルートEと納入ルートEに入れとくか。設計間違いじゃねーのか？」ぐらいで判断して良いです。
「納入」「納入明細」は、既に完成したスキーマなので、間違えたくないですね。1つの「納入ルート」は多くの「納入」で使われるので「1対多」。「納入」は多くの「納入明細」を持つので「1対多」。
1つの「発注」は多くの「店舗」にされるので「1対多」。1つの「発注」は多くの「発注明細」を持つので「1対多」。1つは「自社仕様商品」は多くの「発注」でなされるので「1対多」。
「生産番号」に反応して「発注明細と生産」、「配送番号」に反応して「配送」と繋げるのは少し軽率です。
「発注明細」を「生産明細」「配送明細」と繋ぐ理由は、「どの商品がどの発注と対応するか」を商品単位で特定するからです。「商品コードと生産番号」「商品コードと配送番号」で紐づけています。
データベース設計で、「発注」と「発注明細」が「1対多」なのはほぼ確定です。問題は「発注」「発注明細」と「生産」「生産明細」などの関係。今回は「発注」と「生産」は繋がりませんでしたが、繋がる場合もあります。問題文と完成したスキーマから新町人判断する重要ポイントです。＞ER図のパターン解説Note
「生産」と「生産明細」が「1対多」なのは定石通り。
1つの「商品」が多くの「生産明細」で表れるので「1対多」も一般常識で判断。
「配送」と「配送明細」が「1対多」なのは定石。
「配送明細」と「自社商品」も「生産」と同様に「1対多」。
以上で、各スキーマを見てER図を完成させました。
設問2(3) | カーディナリティ
この問題の正答は本試験無理です。捨て問にして、今までのスキーマとER図で8～9割稼ぎましょう。
「工場」と「オ：納入ルート」の話なのでスキーマ。
工場（拠点コード, 生産能力）
納入ルート（ルート番号, 工場拠点コード, 物流センタ拠点コード）
納入ルート・納入について問題文から情報を集めます。必要に応じて芋づるで。
1(6)：自社工場から物流センタへ、委託工場から物流センタへ、商品を運ぶことを納入と云う。
2(1)①：各自社工場と自社工場内の物流センタの組を納入ルートと云う。→自社工場1×自社工場内の物流センタ1
2(1)①：各委託工場と各物流センタの組を納入ルートと云う。→委託工場1×物流センタ3 ※6頁の1(3)：自社工場は3か所。
自社商品の場合は、自社工場で生産し、同じ自社工場内の物流センタを使うので、1対1。
委託商品の場合は、委託工場で生産し、自社工場内のの物流センタ（3か所）を使うので、1対3。
特にも解釈できる文章はありますし、「委託工場が5か所」の記述もあるので、初見正解は無理と思います。私もできません。
とはいえ、「カーディナリティは、具体的な個数のことなんだな」と学びにはなりましたね。よく問われたのは「0を含む/含まない」でしたが、こんなこともあるんだと。
まとめ
お疲れ様でした！
以下は＞前回 と同じ学習にお薦めNoteの紹介です。データベース設計の基盤を作る重要な3Noteです。
データベース設計をがっちり固めたいなら、1文1文がっつり見ながらの演習を一度やってみてください。＞DBR04年秋PM1問1の解説Note
今回のER図はシンプルで、連関エンティティ程度でした。サブクラスや自己回帰型などの色んなパターンもでます。＞ER図のパターン解説Note
今回「ポイント後付け」に正解できたでしょうか？長文問題からヒントを探すコツがあります。＞長文問題の解法テクニック６のNote
後は問題演習と復習を繰り返して、問題文→スキーマ→ER図の作成手順の効率化を極めていってください。データベース設計は早さと正確さが高得点に重要です。
ぜひデータベース設計で得点を稼いで、他の実装系やSQLのフォローをしつつ、データベーススペシャリスト試験に合格していってくださいね！
私が合格してきた勉強法についてもNoteにしました。まずは書籍の読み倒し方、AMIIの勉強だけでも参考にして頂ければ、嬉しいです。
p.s. 普段は >> 専門学校とIT就職のブログ << をやってます。
でわでわ（・ω・▼）ノシ
いいなと思ったら応援しよう！
