【デスペ】平和31年春午後1問1の解説（データベーススペシャリスト）
このNoteでは、DB平成31年春PMI問1の解説をします。
データベース設計は、問題文からスキーマとER図を完成させる作業がメインですが、後半に派生問題が追加されるパターンもあります。
よくあるのはデータベースの改良によるスキーマとER図の訂正、プログラム処理の条件やスキーマの権限を表現した決定表です。
今回の問題では、スキーマとER図の作成に加えて、データベースの改良と決定表が出ました。PMIIでよく出るので良い練習になりますよ。
このNoteは、私が独学合格した経験と、IT専門学校での授業のノウハウで書いています。合格のお手伝いに少しでもなったら嬉しいです。
それでは始めましょう！
設問1(1) | 問題文→スキーマ
3つのスキーマ「主催者」「種目」「種目分類」が組めます。穴埋めaも解決しますね。種目と種目分類が分かりにくいですが具体例もあるので理解できます。
2つスキーマ「大会」「運営サービス」が組めます。穴埋めbも解決します。それ以外に特記事項はありません。組んで終わりです。
「～ごとに複数」だと組合わせ、つまり複合主キーにしろというメッセージ。
「大会ごとに一つ以上」から「1対多」、1つの運営サービスは複数の大会で使われるのは常識で判断でき「1対多」、したがって「多対多」なので複合主キーの連関エンティティを作るパターンです。＞合格必須のER図パターン解説Note
「エントリ枠」スキーマを組みます。幾つか未解決もありますが、穴埋めcは埋まるので大丈夫で。
「エントリ枠」の続き。穴埋めではないですが、複合主キーになる理解をしましょう。
「抽選エントリ枠」スキーマを確認します。なお、抽選年月日＞募集終了年月日はマーキングしておきます。あとで処理の問題で使うかもしれませんから。常識レベルではありますが。
2つのスキーマ「アイテム」「大会アイテム」の確認をします。「～ごと～複数」に注目して複合主キーに。
「会員」スキーマの確認をします。特記事項はありません。
「参加申込み」スキーマが組めます。穴埋めdとeが解決し、複合主キーになることを理解しましょう。どの会員がどの大会に申し込むかですから。fとgは保留です。
また「エントリ枠」スキーマに「参加申込数」を追加する修正もします。
「参加申込み」スキーマに「抽選結果」が入っているのは良いのですが、「入金年月日」と「使用ポイント」をどこに記録するかは、文章からは判断できません。しかし残りの穴埋めがfとgしかないので、入れるしかないので入れておきます。
「エントリ枠」「会員ポイント」の確認。
1つだけ気になったのは実際の支払い金額を記録する項目がなかったこと。「エントリ枠の参加費用」と「参加申込みの使用ポイント」から計算はできますが、支払い金額は重要な値なので記録したいです。
支払い額は、「支払い」スキーマに、支払い金額と支払い方法などと一緒に記録することが多いですよね。＞R03秋午後1問1の解説Note
設問1(1) | スキーマ→ER図
完成したスキーマ（エンティティ）を1つずつ見て、外部キーを参考にリレーションを繋げるか判断していきます。
「種目分類の種目分類コード」を「種目の種目分類コード」が見ています。個数対応は2(1)(2)にて、種目分類：ランニングに、種目：フルマラソンとハーフマラソンが属していそうなので「1対多」。
「主催者の主催者番号」を「大会の主催者番号」が見ています。1つの主催者は多くの大会を実施する、と常識的に判断して「1対多」。
「運営サービスの運営サービスコード」を「大会運営サービスの運営サービスコード」が見ています。1つの運営サービスは、複数の大会で使われるので「1対多」。
「アイテムのアイテムコード」を「大会アイテムのアイテムコード」が見ています。1つのアイテムは、複数の大会で使われるので「1対多」。
「主催者」も「種目分類」も外部キーはないので、リレーションの追加はありません。
「エントリ枠」はたくさんの外部キーがあります。
種目の種目コード：1種目は色んな大会で使われるので「1対多」。
大会の大会番号：1つの大会に複数のエントリがあるので「1対多」。6頁5(1)「大会ごとに一つ以上のエントリ枠を登録」より。
先着順抽選区分で先着/抽選の分類を記録します。「抽選エントリ枠」と「股なし△」で繋げます。なお先着で独自に記録する項目がないため「先着エントリー枠」スキーマは作っていないと思われます。
「抽選エントリ枠」はすでに「エントリ枠」と繋げました。エントリ枠の複合主キー「大会番号とエントリ枠番号」を参照しています。
「会員」には外部キーがないので、リレーション追加はありません。
「会員の会員番号」を「参加申込みの会員番号」が見ています。1人の会員は多くの大会に参加申込みするので「1対多」。
参加申込みは各大会の各エントリにします。「エントリ枠の高い番号&エントリ枠番号」を見ています。ある大会のある種目へのエントリに、多くの会員が参加申込みするので「1対多」。
「会員の会員番号」を「会員ポイントの会員番号」が見ています。ある会員の会員ポイントを記録しているので「1対1」。
ただし「会員ポイント」に今までのポイントの履歴を記録したいとき、複合主キー（会員番号, 年月日）とすると「1対多」になります。ポイントの付与と消費の履歴を記録することはよくあるので、手法として知っておきましょう。＞R03年秋午後1問1の解説Note
設問2 | 決定表（処理条件）
データベース設計や実装では、しばしば処理条件やアクセス権限をまとめた決定表が出題されます。PMIIでは、最近良く出てきます。PMIの段階で練習しておく良い機会でした。
表の空欄は解けるとこから攻めます。
②～⑤は大丈夫ですね。エントリ枠の状態から特定できます。
①については、「そりゃ募集期間前があるでしょ」「左から前・中・後でしょ」「先着順でも前が一番左だし」のメタ読みで大丈夫です。
一番右の「超過」は、募集や抽選が終わった後、未来永劫の話。⑤が抽選日当日なので抽選日後という意味。
これら2つは文章に明記がないので、考え落とさぬように注意が必要です。
設問3 | データベースの改良
改良は、まず問題文を読んで「自分だったらこんな風に改良するなぁ」と考えると良いです。下手に穴埋めや問題文を見ると混乱します。ゼロベースである程度考えておく方が私は良いです。考える力も鍛えられますからね。
設問3(1) | 多段階抽選
まずはゼロベースで考えたこと。
「多段階抽選の対象のエントリ枠には、後続エントリ枠を一つ設定する」から、「エントリ枠」スキーマに後続エントリ枠を指す「エントリ枠番号」を追加すると良さそうです。
参加希望者は参加申込みをするので、「参加申込み」スキーマに変更が必要か考えます。ひとまずは最初の抽選のエントリ枠が記録されていれば良いので、変更は必要なさそう。落選したら、後続エントリ枠の行を追加すれば良いでしょう。
「落選した会員は、後続するエントリ枠の抽選対象に加える」より、抽選結果の記録が必要です。元々「参加申込み」の各行に抽選結果があるので大丈夫でしょう。問題文の「抽選毎に抽選結果を登録する」は満たしています。
では設問を読んで考えます。
私の推測では、後続エントリ枠の追加、抽選結果の記録の2つがポイントでした。
設問3(1)①について。「エントリ枠」スキーマに後続エントリ枠を指す「エントリ枠番号」を追加。
設問3(1)②について。私は、削除する項目は思い当たりませんでした。しかし次の設問3(1)③で新たなスキーマを作るので、何か項目を独立させる（項目削除&スキーマ新設）ようだと考えると、いじってないのは「抽選結果」のみ。
よって、抽選結果スキーマを新設すると考え至ります。
設問(1)②で、「参加申込み」から「抽選結果」を削除。設問(1)③で、「抽選結果（退会番号, 会員番号, エントリ枠番号, 抽選結果）」を追加。
設問3(2) | ポイントの履歴
ポイントの有効期限制度の追加について、ゼロベースで考えたこと。
現状ポイントに関わっているのは「会員ポイントのポイント残高」「参加申込みのポイント利用」のみ。
有効期限は付与してから1年で固定値なので、少なくとも付与年月日とポイント数を記録する必要があります。「会員ポイント」を改良するか、新たに「ポイント付与」スキーマを設けるなどで対応します。
では設問を読んで考えます。
設問3(2)では「会員ポイント（会員番号, ポイント残高）」を変更するとのこと。
少なくとも、付与年月日と付与ポイントは必要と考えていたので「会員ポイント（会員番号, 付与年月日, 付与ポイント）」。ポイント残高は、付与ポイントを合計すれば算出できます。
問題文で「ポイントの使用は有効期限の近いものから行う」より、消費したポイントの記録が必要なので、「会員ポイント（会員番号, 付与年月日, 付与ポイント, 消費ポイント）」。ここで付与ポイント≧消費ポイントにする制約は必要です。
模範解答も「会員ポイント（会員番号, 付与年月日, 付与ポイント, 使用済ポイント）」なのでOK。
なお、ポイント残高はない方が良いですね。各行にポイント残高を記録するのは冗長ですから。とはいえ、できれば「会員」スキーマに「ポイント残高」を追加しておきたい所ではあります。
まとめ
お疲れ様でした！
ER図のリレーションがノーヒントでしたが、全く問題なく解ける適度な難易度でした。データベース改良もまずまず解けます。
特にポイント付与・消費の設計は、今後も遭遇するので「こんな記録の仕方をするんだな」と学びにしてください。
以下は＞前々回 と同じ学習にお薦めNoteの紹介です。データベース設計の基盤を作る重要な3Noteです。
データベース設計をがっちり固めたいなら、1文1文がっつり見ながらの演習を一度やってみてください。＞DBR04年秋PM1問1の解説Note
今回のER図はシンプルで、連関エンティティ程度でした。サブクラスや自己回帰型などの色んなパターンもでます。＞ER図のパターン解説Note
今回「ポイント後付け」に正解できたでしょうか？長文問題からヒントを探すコツがあります。＞長文問題の解法テクニック６のNote
後は問題演習と復習を繰り返して、問題文→スキーマ→ER図の作成手順の効率化を極めていってください。データベース設計は早さと正確さが高得点に重要です。
ぜひデータベース設計で得点を稼いで、他の実装系やSQLのフォローをしつつ、データベーススペシャリスト試験に合格していってくださいね！
私が合格してきた勉強法についてもNoteにしました。まずは書籍の読み倒し方、AMIIの勉強だけでも参考にして頂ければ、嬉しいです。
p.s. 普段は >> 専門学校とIT就職のブログ << をやってます。
でわでわ（・ω・▼）ノシ
いいなと思ったら応援しよう！
