平成31年度春期 データベーススペシャリスト 午後Ⅰ 問1

要件記述と設計の対応を丁寧に追う

設問に答える前に、業務要件の一文ごとに、それが設計のどこにどう表現されているかを対応づける習慣をつけましょう。記述と成果物の対応を追うことで、見落としや思い込みによる判断を避けやすくなります。

この問題で問われていること

問われている箇所が、業務要件のどの記述に由来するのかを特定することに焦点を当てます。設問の対象を一つ定め、その根拠となる記述を本文中から探し出し、根拠と照らし合わせて判断する姿勢が求められます。

視点

データベース設計の成果物は、どれも業務要件を別の角度から書き表したものです。そのため、設計上の判断には必ず要件側に根拠となる記述があるはずだと考えて読み進めます。一般常識や過去に見た類似事例で補わず、本文に書かれた条件だけを手掛かりにすることが大切です。要件が追加・変更される場面でも同じで、新しい記述が既存の設計のどこに関わるのかを一つずつ対応づけて確かめます。

確認ポイント

• 判断の根拠にしている要件の記述を、本文中の具体的な箇所として示せるか
• 本文に書かれていない前提や一般的な業務知識で補って考えていないか
• 追加・変更された要件が、既存の設計のどこに関わるかを対応づけて確かめたか

解説

スポーツ大会の運営サービスを題材に、業務記述から関係スキーマの属性とリレーションシップを完成させる問題です。あわせて、エントリ枠状態の遷移を決定表で整理し、多段階抽選とポイント有効期限という新しい要件に合わせてデータモデルを拡張します。出題趣旨では、データモデリング、外部キーの設定、決定表による要件整理、要件変化への対応力を問うと示されています。

問題の全体像

A社は大会運営サービス会社で、主催者・大会・運営サービス・エントリ枠・アイテム・会員・参加申込み・ポイントを扱う大会運営システムを新しく構築します。B君が図1の概念データモデルと図2の関係スキーマを設計し、それをC部長の指摘で作った表1の決定表で補います。さらに多段階抽選方式とポイント有効期限という新しい要件が加わります。出題趣旨では、業務要件を理解してデータモデリングを行う力、リレーションシップと外部キーを適切に設定する力、決定表で要件を整理する力、ビジネス要件の変化に合わせてデータモデルを拡張する力を問うとされています。採点講評によると全体の正答率は高かった一方、設問3は正答率が低かったとされています。

設問1(1)(a)

問題文には「種目は、種目コードで識別し、種目分類コードで、ランニング、自転車レースなどに分類する」とあります。種目分類は独立した関係「種目分類（種目分類コード、種目分類名）」として存在するので、種目はどの分類に属するかを参照する属性を持つ必要があります。そのため公式解答例では、aを「種目分類コード」とし、外部キーを表す破線の下線を付けています。採点講評では、下線を記入していない答案が散見されたと指摘されているので、下線まで書くことが必要です。

設問1(1)(b)

大会の記述は「大会番号で識別し、大会名、開催年月日、開催場所の都道府県コード、主催者番号を登録する」です。図2の関係「大会」には、主催者番号以外の属性はすでにそろっています。したがって公式解答例では、bを主催者を参照する外部キー「主催者番号」（破線の下線）としています。

設問1(1)(c)

エントリ枠では「エントリ枠名、エントリ枠説明、種目コード、定員、参加費用、募集期間…などを登録する」とされています。図2で欠けているのは種目コードだけです。一つの大会で複数のエントリ枠に同じ種目を登録することがある、という記述からも、エントリ枠が種目を参照する構造だと分かります。公式解答例では、cを「種目コード」（破線の下線）としています。

設問1(1)(d)

「参加申込みは、大会番号、会員番号で識別し」とあるので、参加申込みの主キーは大会番号と会員番号の組です。これは「会員は一つの大会について一つのエントリ枠だけ参加申込みできる」という制約を主キーで表したものでもあります。公式解答例では、dを主キーの一部として実線の下線を付けた「大会番号」としています。この大会番号は、破線の下線が付いたエントリ枠番号と組み合わせて、エントリ枠（大会番号、エントリ枠番号）を参照する役割も持ちます。d～gは順不同です。

設問1(1)(e)

(d)と同じく、参加申込みの識別子のもう一方が会員番号です。公式解答例では、eを実線の下線付きの「会員番号」としています。これにより、会員から参加申込みへの1対多のリレーションシップが成り立ちます。d～gは順不同です。

設問1(1)(f)

〔大会への参加申込みから参加費用の入金まで〕の4.(2)に「A社は、会員の参加費用の支払を確認して入金年月日を登録し」とあります。入金は参加申込みごとに発生するので、参加申込みの属性になります。公式解答例では、fを「入金年月日」としています（d～gは順不同）。

設問1(1)(g)

4.(4)に「会員は、ポイントを使用する場合、使用ポイントを登録し、参加費用から使用ポイントを差し引いた額を支払う」とあります。使用ポイントは参加費用の支払、つまり参加申込み1件ごとに決まる値です。公式解答例では、gを「使用ポイント」としています（d～gは順不同）。

設問1(2)

図2の外部キーを一つずつ確認し、参照される側を1、参照する側を多とする矢印を引きます。公式解答例のリレーションシップは次のとおりです。種目分類→種目、主催者→大会、大会→大会運営サービス、運営サービス→大会運営サービス、大会→大会アイテム、アイテム→大会アイテム、大会→エントリ枠、種目→エントリ枠、エントリ枠→参加申込み、会員→参加申込み、会員―会員ポイント（1対1）。エントリ枠と抽選エントリ枠のスーパータイプ／サブタイプ関係は、最初から図1に描かれています。参加申込みの大会番号はエントリ枠を参照する複合外部キーの一部なので、大会から参加申込みへの直接の線は引いていません。会員ポイントは主キーが会員番号だけなので、会員と1対1になります。採点講評では、大会運営サービスを運営サービスのサブタイプ、大会アイテムをアイテムのサブタイプとする誤りが散見されたと指摘されています。これらの主キーは（大会番号、運営サービスコード）と（大会番号、アイテムコード）の複合キーなので、サブタイプではありません。大会と運営サービス、大会とアイテムの多対多の関係を解消する連関エンティティです。

設問2

抽選の列（太枠）は、4.(5)の②と④に沿って埋めます。前提として、抽選年月日は募集終了年月日より後の日付です。そのため、募集期間の前や期間中であれば、抽選年月日に対して本日は必ず「前」になります。逆に抽選年月日の当日や後であれば、募集期間に対して本日は必ず「後」です。公式解答例の6列は次のとおりです。

① 募集期間：前、参加申込数：－、抽選年月日：－（前も可）。動作はなく、状態は‘募集前’のままです。

② 募集期間：中、参加申込数：－、抽選年月日：－（前も可）。‘募集中’にします。抽選の場合は定員を超えても募集を続けるので、参加申込数は条件になりません。

③ 募集期間：後、参加申込数：以下、抽選年月日：－。‘参加者確定’にします。

④ 募集期間：後、参加申込数：超過、抽選年月日：前。‘抽選中’にします。

⑤ 募集期間：－（後も可）、参加申込数：超過、抽選年月日：当日。抽選を実施し、‘参加者確定’にします。

⑥ 募集期間：－（後も可）、参加申込数：超過、抽選年月日：後（この値は問題の表に記載済み）。‘参加者確定’にします。

先着順の列では参加申込数に未満／到達を使っていますが、抽選では問題文④の表現に合わせて以下／超過を使います。この使い分けに注意してください。

設問3(1)①

仕様は「多段階抽選の対象のエントリ枠には、後続のエントリ枠を一つ設定する」です。後続の枠も抽選で参加者を決める枠であり、同じ大会の中の枠です。そのため、大会番号は自分の値を使い、エントリ枠番号だけを追加すれば後続の枠を指せます。公式解答例では、関係「抽選エントリ枠」に「後続エントリ枠番号」（破線の下線）を追加しています。これは同じ関係を参照する再帰的な外部キーです。採点講評では、後続するエントリ枠が抽選エントリ枠と再帰的な関係にあることを読み取れていない答案が散見されたと指摘されています。

設問3(1)②

多段階抽選では、地元優先枠で落選した会員が一般枠の抽選対象にもなります。つまり、一つの参加申込み（大会番号、会員番号）に対して抽選結果が複数発生します。参加申込みに抽選結果の属性が一つあるだけでは、これを記録できません。仕様でも「エントリ枠の抽選ごとに抽選結果を登録する」とされています。そこで公式解答例では、関係「参加申込み」から属性「抽選結果」を削除し、③の新しい関係に移しています。

設問3(1)③

抽選結果は、会員とエントリ枠の組ごとに決まります。公式解答例では「抽選結果（大会番号、会員番号、エントリ枠番号、抽選結果）」とし、大会番号・会員番号・エントリ枠番号の3つに実線の下線を付けて主キーにしています。同じ大会で同じ会員が複数の枠の抽選に関わるため、エントリ枠番号まで含めないと一意に識別できません。採点講評では、抽選結果が会員ごとに決まることを読み取れていない答案が散見されたと指摘されています。会員番号を落とさないよう注意してください。

設問3(2)

要件は、ポイントの有効期限が付与日から1年で、期限を過ぎたものは消失し、期限の近いものから使用する、というものです。そのため、ポイントを付与の単位ごとに管理する必要があり、会員単位のポイント残高一つだけでは対応できません。公式解答例では、変更後の属性を「会員番号、ポイント付与年月日（この2つが実線の下線の主キー）、付与ポイント、使用済ポイント」としています。有効期限はポイント付与年月日から導けます。付与ポイントから使用済ポイントを引けば、付与単位ごとの残りが分かります。これで、期限の近い順に使用する処理と、期限切れで消失させる処理が可能になります。答案では、主キーの下線と、付与単位を識別する日付属性を必ず含めてください。

学習のポイント

主キーと外部キーから、リレーションシップの向きやサブタイプかどうかを判断することが重点です。さらに、日付条件の前後関係からあり得ない組合せを除外すること、そして抽選ごと・ポイント付与ごとのように管理単位が変わったときに主キーを見直すことを練習しましょう。