猫でもわかるWebプログラミング

試行錯誤しながらエンジニア(プログラマー)として働く猫のブログ。技術的な話や、働き方の話、読書録とか、試行錯誤している日常の話。

過去問解説 データベーススペシャリスト 平成31年度春期 午後I問1

f:id:yoshiki_utakata:20181004212834j:plain

過去問のダウンロード場所

DBスペシャリストの過去問を解いたので解説を書きます。

過去問はIPA公式サイトからダウンロードできます。

www.jitec.ipa.go.jp

以下、解答と解説なので、先に問題を解いてから読んでください。

問1 解説

まず、問題をざっと見ると、明らかに、「概念データモデル」と「関係スキーマ」を答えさせる問題が出てきているので、ここは問題を読みながら埋めていったほうが良い。

また、「大会運営サービス」や、「大会アイテム」という関係が肝になってくる。これは文章中には出ていない。

4. 運営サービス を読むと、一つの大会で複数の運営サービスを使う可能性があることがわかる。一つの運営サービスでは複数の大会を運営することが想像できるので、「運営サービス」と「大会」は N対Nの関係となる。N対Nの関係を表すには中間テーブルが必要なので、その中間テーブルが「大会運営サービス」という名前の関係である。

「大会アイテム」については 6.アイテム に書いてある。

関係スキーマについて

a については、[大会の登録から参加申込受付の準備まで] の 2. 種目と種目分類(2) にあるとおり、「種目は、 種目コードで識別し、種目分類コードで、ランニング、自転車レースなどに分類する。」とあり、a に入るのは「種目分類コード」である。

スキーマには「種目分類」があるので、a に入る種目分類コードは外部キーになることになるので、点線を引く必要がある。

b については、3. 大会 に「主催者番号を登録する」と書いてあり、明らかに主催者番号は足りていないので、これが正解になる。主催者番号は外部キーになっているので点線を引く。

c は 5. エントリ枠 (1) に「種目コード」を登録すると書いてあるので、c は種目コードになる。種目コードは「種目」にある外部キーになっているので、点線を引く。

d, e, f, g は順不同。まず、[大会の参加申込から参加費用の入金まで] の 2.参加申込及びエントリ枠状態の設定 (2) にある通り、「参加申込は、大会番号、会員番号で識別し」なので、大会番号と会員番号が入る。主キーなので、実践を引く。

さらに、 4.参加費用の入金及びポイントの付与 で、 (2) に「入金年月日を登録し」とあるので、一つは「入金年月日」。(4) に「使用ポイントを登録し...」とあるので、残りの一つは「使用ポイント」になる。

概念データモデルについて

f:id:yoshiki_utakata:20201010123029p:plain [大会の登録から参加申込受付の準備まで]

  1. 種目と種目分類
    • (2) 種目には種目分類があり、一つの分類に対して複数の種目があるため、種目分類1:n種目、になる。
  2. 大会
    • 大会には主催者番号を登録する。一つの大会につき主催者は一つ。主催者一つにたいして大会の数の制限は無い。大会n:1主催者
  3. 運営サービス
    • (3) 大会一つにつき一つ以上(つまり複数)の運営サービスが対応する。運営サービス一つにつき大会一つの制約は特に無いのでn:nの関係になる。中間テーブルを使って、 大会1:n大会運営サービスn:1運営サービス
  4. エントリ枠
    • (1) 大会に対して複数のエントリ枠を設定する。大会1:nエントリ枠 また、エントリ枠には種目コードを入れることが書いてある。
    • (2) いくつかのエントリ枠に同じ種目を登録できる。 種目1:nエントリ枠
  5. アイテム
    • 一つのアイテムはいろんな大会で使われるし、一つの大会で色んなアイテムが使われる。 中間テーブルを使って、大会1:n大会アイテムn:1アイテム

[大会の参加申込から参加費用の入金まで]

  1. 参加申込及びエントリ枠状態の設定
    • (3) 参加申込は大会番号と会員番号で識別するとある。会員は複数の大会に申込できるので、会員1:n参加申込n:1大会 と、なりそうだが、解答には、大会 -> 参加申込の線は無い。そもそも、エントリ枠の主キーに「大会番号」が入っているので、エントリ枠1:n参加申込n:1会員、となる。これだと1つの大会につき1つという制限が表現できていないが、テーブルの設計には含めない情報で、これより後もこの制約に触れられるようなことはない。。。
  2. 参加費用の入金及びポイントの付与
    • 会員はポイントを持っており、会員1:1ポイント

決定表

f:id:yoshiki_utakata:20201010124150p:plain

[大会の参加申込から参加費用の入金まで] 2. 参加申込及びエントリ枠状態の設定 (5) にすべて書いてある。

太線の部分を左から1列づつ見ていく。

1列め、特になにもないのは、募集期間前の状態である。

2列め、エントリ枠状態が募集中になるのは、募集期間中である。抽選の場合は、募集期間中であれば、申込数が定員を超過しても募集は続く。

3列め、エントリ枠状態が参加者確定になる条件は2つある

(A) 募集期間後で、定員以下だった場合 (B) 募集期間後で、抽選も終わった場合

一番右の列が(B) なので、この列は(A) のことを書く。

4列め、エントリ枠状態が抽選中になるのは、募集が終わって、参加申込数を超過しており、抽選前であるときである。

5列め、抽選を実施するのは、募集が終わって、参加申込数が超過していて、抽選年月日当日である。

6列めは、先程のベタ通り、抽選を行った後の話なので、募集後で、参加申込数は超過していたはずである。

新たな要件の追加

多段階抽選の対象エントリ枠には、後続のエントリ枠を一つ設定する必要があるので、(1)①は、「エントリ枠」に「後続エントリ枠番号」を追加する必要がある。

さらに、エントリ枠の抽選ごとに抽選結果を登録する必要があるので、一つの参加申込に対して複数の抽選結果が必要になる。

そこで、エントリ枠1:n抽選結果n:1参加申込 のようにする必要があるため、まず、参加申込から抽選結果の属性を削除する。

その後、抽選結果属性を追加する。エントリ枠ごとの結果を保存する必要があるので、エントリ枠の主キーを含める。参加申込にも紐付ける必要があるので、参加申込の主キーも含める。当然抽選結果も保存する必要がある。

抽選結果(大会番号, エントリ枠番号, 会員番号, 抽選結果)

ポイントに有効期限をもたせるには、有効期限ごとにポイントのレコードを保存する必要があるので、会員1:n会員ポイントになるようにして、ポイントと、有効期限がわかるような属性をつける。