【失点小鉢】デスペ令和3年秋午後1問1(データベーススペシャリスト)
このNoteでは、DB令和3年秋PMI問1の解説をします。
>前回< は、1文1文がっつり解きました。今回は、私が本試験でテキパキと解くときの速度で解説しています。
データベース設計は、問題文からスキーマとER図を完成させる作業がメイン。問題文を読み解いて、矛盾ない設計をするには時間がかかります。
データベース設計では、速く・正確に解くことが重要です。
すでに確定しているスキーマの記述は軽くチェックで流し、設計に重要な記述を見落とさない注意力も必要。実際に運用した時の不具合と改修にも、考え及ばねばなりません。
このNoteの解説には、問題文の何に注目して設計しているか、ER図を矛盾なく設計する解法テクニックを添えました。
前回よりは、さくっと読めますので、通常の復習に使って頂けたら嬉しいです。
それでは始めましょう!
私の4ヶ月の勉強法に興味が出たらどうぞ。私が独学合格した経験と、IT専門学校での授業内容を基に作っています。
設問1(1) | 問題文→スキーマ
会員表は問題文通り。
特段注意すべき情報も疑問点もないので進めますね。

企業と店舗についてはよくあるパターンですね。
店舗の主キーが、企業コードと店コードなのもオーソドックス。

ただ、図2で全スキーマを見ても企業スキーマがないので「企業名を記録しないって珍しいな」とは思いました。「店舗名」列に「A
社B支店」と記録するつもりなんでしょうか。
データベース設計で「違和感」「感覚」は結構役立ちます。後に「企業」「商品」絡みのスキーマを新しく作る設問が出てきます。
商品のスキーマ。
問題文で、主キーが企業コード+商品コードと明記されていますが、図2には下線が引いてません。「下線を引かせる設問でもあったかな?」と少し疑問になりました。
忘れないうちに、スキーマの2項目に主キーの下実線をつけておきましょう。

また、企業コードと商品コードなので、店コードを使っていません。店舗スキーマで話題にしましたが、「なおのこと、企業スキーマが必要だったんじゃないかなぁ」と思い返します。
あと「JANコード(いわゆるバーコード)も主キーになりそうだなぁ」「横断分析用商品コードってなんだ?」とも思っておきます。
疑問だった横断分析用商品コードについてすぐに記述があるのでラッキー。同じ商品なんですね。販売元は違うけど、製造元は同じなケースなどでしょう。

また、コードは主キーになるけど、商品名は「一意ではない」ので「主キーにはなれない」ってメッセージも受け取ります。
更に横断分析用商品コードの説明です。
念入りに記述してきたので設問になってくるのでしょう。

上図のように、
同じ商品があれば、それと同じ横断分析用商品コードを付与
同じ商品がなければ、新たに横断分析用商品コードを採番
とのこと。読んだだけでは分からないので、具体的な値を考えました。
さらに横断分析用商品コード絡み。
「ここまでシツコイと何かあるんだな」と確信します。かなり疑っています(図でも橙や赤になりました)。

「数日を要する」。これは課題点。「絶対障害になるか改善を問うてくるでしょ」と▼マーク。
私たちの感覚だと「ほーん」「数日ぐらいかかっても問題なさそう」ぐらいに思っちゃうんですが、試験的・IT的には大問題。必ず▼マークしてください。>長文問題の解法Note(その4:怪しいポイント)
次はポイントの話になるので、頭を切り替えます。スキーマの穴埋めもできるようになりますね。
如何にも項目になりそうな記述(緑枠)、主キーになる記述(赤枠)が「支払いスキーマ」にあるのをチェック。
穴埋めa, bはちょっと難しいかもですが、「ポイントの利用場所の記録」と思い至って解きます。(私は、イマイチ特定できなかったのでc, d, eの後に埋めました)

「a:加盟企業コード」、「b:店舗コード」に外部キーの下破線を忘れずに。
今回は優しいです。設問文に「主キーは実線、外部キーは破線」の旨が明記されているので。大抵は「図2の書き方に従って~」などアバウト目な書き方がされます。キーの下線は忘れずに。
次はポイントの付与。
支払いでポイント付くのは分かりますが「商品によっても付くのは珍しいなぁ」と思いました。
dは自信ないかもですが、「購入数」をとりあえず入れます。何でもかんでも保留にすると覚えきれないし進みませんからね。後になって見返しても問題ないので確定させました。

「購入数×商品単価×ポイント付与率=付与ポイント だけど、付与率が載ってないなぁ」と疑問に思いつつ進めます。「なんかクーポンもあるから、付与率を管理するスキーマがあるんだろうな」と。
支払方法のスキーマ。現金だけでなく、クレジットカードや電子決済もありますからね。
cに「支払金額」を入れます。「支払方法コードから付与率ひっぱってきて、付与率×支払金額=付与ポイント」なんでしょう。

なお、レシート番号+支払方法コードで複合主キーなので、「1つの支払いで複数の支払い方法が選べるってめっちゃ珍しいな」と驚きました。
いよいよポイント付与率の管理スキーマ。
fが「ポイント付与率」。特段問題はありませんね。

支払方法スキーマが、ポイント設定からポイント付与率を引っ張ってこれるように外部キーを作ります。下破線を忘れずに。

これで「付与率が、ポイント設定→支払方法→支払い方法明細・購入商品明細まで伝わって、付与ポイントの計算ができるな」と思って次へ進みます。
次はクーポンの話。再度、頭を切り替えます。「ポイント付与率が変わる話があったなぁ」と。
まずはクーポンを定義するスキーマ。問題文から穴埋めgは特定できませんでした。まだまだ記述があるので保留にして、読み進みましょう。

クーポンの種類の話。2種類のクーポンの詳細スキーマがあるのを確認しましたが、穴埋めgはまだ特定できません。

クーポンの利用記録について。
「どのクーポンをどの支払いで利用したか」なので、
どのクーポンを→クーポンコード:j
どの支払いで→レシート番号:k
あとはキー設定。
「1回の支払いで複数のクーポン」の記述から「1対多」。あと想像で逆視点「1つのクーポンは色んな人の支払いで使われるよな」から「1対多」。つまり「多対多」なので複合主キーにして連関エンティティにします。>ER図の代表パターンNote

クーポンの配布の話。
「同じ会員に同じクーポンを配布しない」旨から、「配布したら記録しないとね」と考えます。
配布された会員を特定するのは「会員コード」、配布したクーポンを特定するのは「クーポンコード」。

キー設定は「クーポン利用」と同じ考え方。
1人の会員に複数のクーポンは配布するだろう:「1対多」
1種のクーポンは複数の会員に配布するだろう:「1対多」
つまり会員とクーポンは「多対多」
両項目を複合主キーにした連関エンティティを作る
以上より「h:会員コード」「i:クーポンコード」。模範解答と逆ですが順不同なのでOK。
最後の最後に穴埋めgの記述がありました。

「なんか見落としたかなぁ」と不安になりつつ、「結構解けたからまぁいいか」と思ってもいました。
設問1(2) | 問題文&スキーマ→ER図
ここから先は

DB午後1解説(図解が豊富です)
【必ずリストを見てからご購入下さい】 データベーススペシャリスト「午後1」の解決Noteです。 取りこぼさないためのマーキング・スキー…
この記事が参加している募集
学習方法・問題特集のNoteは全て無料提供を続けます▼ もしご覧になったNoteが有益だったり、私の志に共感されたりしましたら、サポート頂けますと励みになります▼ もちろんコメントでも結構です(・ω・▼)ノシ
