データベーススペシャリスト 2024年 午後1 問01
オンライン学習プラットフォームの概念データモデリングに関する次の記述を読んで、設問に答えよ。
教育事業者のA社は、オンライン学習プラットフォーム(以下、PFという)を運営している。このたび、新規要件の追加に伴い、データベースを再設計した。
〔現行業務〕
1．アカウント
(1) PFを利用する個人をアカウントと呼び、アカウント番号 (以下、番号を#で示す) で識別する。
(2) PF上で学習教材を受講するアカウントを受講生と呼ぶ。受講生としてアカウントを登録する際、学習教材を購入するための支払情報を登録する。 後述する講師としてのアカウントを既に保持している場合、再度アカウントを登録する必要はなく、支払情報を追加で登録する。
(3) PF上で受講生に提供する学習教材を制作するアカウントを講師と呼ぶ。 講師としてアカウントを登録する際、自身のプロフィールを登録する。 受講生としてのアカウントを既に保持している場合、再度アカウントを登録する必要はなく、自身のプロフィールを追加で登録する。
2．コース
(1) コースは、講師がPF上で受講生に提供する一連の学習教材を指し、コース#で識別する。各コースの制作は1名の講師が行い、制作した講師が分かるようになっている。 全て有料であり、標準価格を設定している。
(2) コースは、複数のセクションから成る。セクションは、コースごとにセクション#で識別する。
(3) セクションは、一つ又は複数の講義動画と、講義動画を視聴した後の理解度を確認する高々一つのテストから成る。 講義動画とテストとを併せてコンテンツと呼び、セクションごとにコンテンツ#で識別する。
・テストは、複数の設問から成る。 設問は、テストごとに設問#で識別する。
・設問は、全て単一選択式であり、設問ごとに設問文と配点を設定する。
・設問の各選択肢は、設問ごとに選択肢#で識別し、選択文と正解フラグを設定する。
3．コース購入
(1) 受講生は、コースを検索して、受講したいコースを購入する。 コースの購入は、コース購入#で識別する。 購入情報 (購入年月日、購入価格及び受講生アカウント#)は、PF上に記録される。
(2) 受講生は、PF上で利用できるクーポンを使用すると、標準価格より安くコースを購入できる。クーポンを使用する際は、クーポン#を指定して、購入の手続を行う。 クーポンの併用はできない。
・クーポンは、講師が自身のコースの販売促進を目的に発行している。
・クーポンは、クーポン#で識別し、割引率や値引額、クーポンの適用期間及び同一クーポンの使用可能人数をもつ。 使用可能人数は最大1,000名であり、クーポン使用者数が使用可能人数の上限に達すると、適用期間にかかわらず、クーポンの使用は不可となる。
(3) 受講生は、お薦めしたいコースがある場合、アカウントをもっている相手にコースをプレゼントすることができる。 受講生がコースをプレゼントするには、相手のアカウントと対象のコースをそれぞれ一つ指定して購入の手続を行う。
4．コース受講
(1) 受講生は、購入したコース及びプレゼントされたコースを、いつでも受講することができる。
① コンテンツの受講の完了は、講義動画については視聴を終えた時点、テストについては全設問に解答した時点である。セクション内の全コンテンツの受講が完了するとセクションの受講が完了となり、全セクションの受講が完了するとコースの受講が完了となる。
② 自己研鑽が目的なので、どのコンテンツから受講してもよい。 テストに合格基準点はなく、どのコンテンツも繰り返し受講することができる。
③ コースの受講中又は完了後、5段階評価と感想を登録することができる。
④ 受講生は、自分が最後に実施したテストで選択した各設問の選択肢と解答日時を確認することができる。また、自分が過去に実施したテストについては、最高獲得点数と、全設問の合計点数の履歴を確認できる。
(2) 受講生は、コンテンツの内容に疑問があれば、PF上で講師に質問することができる。各質問に対する講師からのコメントは1回だけできる。
5．購入実績及び受講の確認
講師はPF上で、自分が制作したコースを購入した受講生の購入情報、クーポンを使用した場合のクーポン#、受講生による5段階評価及び感想を確認することができる。
〔企業向けサービスの追加〕
PFに、次のような企業向けのサービスを追加することにした。
1．受講生の登録
企業は、研修対象の従業員を受講生としてアカウントを登録する。これを法人受講生と呼び、現行業務の受講生とは区別する。既に個人でアカウントを保持していても、法人用のアカウント#を新たに付与する。
2．研修カリキュラムの登録
(1) 企業は、受講させる一つ以上のコースをまとめた研修カリキュラムを作成する。研修カリキュラムは、企業ごとに研修カリキュラム#で識別し、研修カリキュラム名をもつ。研修カリキュラムに含まれるコースには、受講順を設定する。
(2) 企業は、法人受講生に対して一つ以上の研修カリキュラムを受講させる。
(3) 研修カリキュラムへの法人受講生の割当てでは、あらかじめ複数の法人受講生を束ねたグループを作成し、グループ単位で割当てを行う。 グループは、企業ごとにグループ#で識別し、グループ名をもつ。 また、同じ研修カリキュラムでも、割り当てられるグループによって、受講開始可能年月日及び受講完了期限年月日が異なる場合がある。
(4) テストを含むコースについては、研修カリキュラムごとに各テストの合格基準点を設定できる。
3．法人受講生によるコース受講
(1) 法人受講生は、指定された研修カリキュラムを期限までに受講する。 受講を開始すると、研修カリキュラム受講開始日時が記録される。 全てのコースの受講が完了すると、研修カリキュラムが完了となり、研修カリキュラム受講完了日時が記録される。
(2) 現行業務のコース受講と同じサービスを提供するが、企業が合格基準点を定めているテストについては、合格基準点に達しないとテストの受講は完了とならない。
〔受講生からの要望〕
受講生から、学習に対する理解を深めるために、次の要望があった。
・コースを提供する講師だけではなく、他の講師及び受講生も質問に対して回数に制限なくコメントできるようにしてほしい。
・その際、誰がコメントしたかを特定できるようにしてほしい。
・質問だけではなく、既出のコメントを指定してコメントできるようにしてほしい。
〔概念データモデルと関係スキーマの設計〕
1．〔現行業務〕 に基づく設計
現行業務の概念データモデルを図1に、関係スキーマを図2に示す。
2．〔企業向けサービスの追加〕に基づく設計
企業向けサービスの追加部分の概念データモデルを図3に、関係スキーマを図4に示す。
解答に当たっては、巻頭の表記ルールに従うこと。 ただし、エンティティタイプ間の対応関係にゼロを含むか否かの表記は必要ない。 エンティティタイプ間のリレーションシップとして “多対多” のリレーションシップを用いないこと。 サブタイプが存在する場合、他のエンティティタイプとのリレーションシップは、スーパータイプ又はいずれかのサブタイプの適切な方との間に設定すること。 同一のエンティティタイプ間に異なる役割をもつ複数のリレーションシップが存在する場合、役割の数だけリレーションシップを表す線を記述すること。 属性名は、意味を識別できる適切な名称とすること。 関係スキーマに入れる属性を答える場合、主キーを表す下線、外部キーを表す破線の下線についても答えること。
設問1：〔現行業務〕の概念データモデル及び関係スキーマについて答えよ。
問題文を見る（1）図1の概念データモデルは未完成である。欠落しているリレーションシップを7本補って図を完成させよ。スーパータイプとサブタイプとの間のリレーションシップの本数は、サブタイプの切り口の数に関係なく、スーパータイプとサブタイプとの組ごとに1本と数える。なお、図1に表示されていないエンティティタイプは考慮しなくてよい。
模範解答
解説
解答の論理構成
【問題文】で要求されている業務処理とエンティティを突き合わせると、図１には次の７本のリレーションシップが不可欠です。
１〜３はコース購入処理に関わる主キー／外部キーの欠落を補完し、４〜７は受講・解答・質疑応答といった学習行動を正しくトレースするために必須となります。特に①②のように同一エンティティ間で役割が異なる場合は「役割の数だけリレーションシップを表す線を記述すること」という設計ルールを満たすため、２本の独立した線で表現します。
誤りやすいポイント
- 「受講生」だけを考慮して①を描かずに済ませてしまう。プレゼント機能で“受贈側”にアカウントが必要な点を見落とし易い。
- ⑤を「コンテンツ」―「コメント」の線だけで済ませてしまう。コメントは質問単位で管理されるため「質問」―「コメント」が正しい。
- テスト結果詳細に直接「設問#」を持たせ、⑥の線を忘れる。実際には「選択肢#」をキーにして設問も一意に特定できるので、選択肢と結果詳細を結ぶのが自然。
- 「クーポン」は「コース」にぶら下がっているから③は不要と考えてしまうが、購入時に実際に使われたクーポンを記録する関係が別途必要。
FAQ
Q: 「アカウント」から２本線を引くと多重従属になりませんか？
A: ①は“受贈者”、②は“購入者”という役割を区別しているため多重従属ではなく、要求仕様通りに２本のリレーションシップを持たせるのが正解です。
A: ①は“受贈者”、②は“購入者”という役割を区別しているため多重従属ではなく、要求仕様通りに２本のリレーションシップを持たせるのが正解です。
Q: 「テスト結果詳細」はなぜ「テスト設問」ではなく「テスト設問選択肢」と結ぶのですか？
A: 【問題文】の「選択した各設問の選択肢」をそのまま格納するためです。選択肢を外部キーにすれば、質問文・配点・設問番号は選択肢側からたどれます。
A: 【問題文】の「選択した各設問の選択肢」をそのまま格納するためです。選択肢を外部キーにすれば、質問文・配点・設問番号は選択肢側からたどれます。
Q: コメントが質問にひも付くなら、「コンテンツ」―「コメント」の線は要らないのでは？
A: コメント一覧をコンテンツ単位でも抽出できるようにするために「コンテンツ」―「コメント」の線も維持します。役割が重複せず、検索性と整合性の両立を図れます。
A: コメント一覧をコンテンツ単位でも抽出できるようにするために「コンテンツ」―「コメント」の線も維持します。役割が重複せず、検索性と整合性の両立を図れます。
関連キーワード: 正規化, 外部キー, リレーションシップ, エンティティ, 汎化/継承
設問1：〔現行業務〕の概念データモデル及び関係スキーマについて答えよ。
問題文を見る（2）図2中の(a)と(b)に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
a：クーポン#、受講生アカウント#、プレゼント相手アカウント#
b：設問#、選択肢#
解説
解答の論理構成
-
コース購入(a)
- 必須の購入者識別
- 「購入情報…受講生アカウント#」という記述より、購入者を示す「受講生アカウント#」が必要です。
- クーポン利用有無
- 「クーポンを使用する際は、クーポン#を指定して…」から、「クーポン#」が外部キーとして必要です。
- プレゼント機能
- 「コースをプレゼントするには、相手のアカウント…を…指定して購入の手続を行う」より、贈り先を示す「プレゼント相手アカウント#」が必要です。
- 以上より(a)＝「クーポン#」「受講生アカウント#」「プレゼント相手アカウント#」。
- 必須の購入者識別
-
テスト結果詳細(b)
- 記録対象
- 「選択した各設問の選択肢と解答日時を確認」→“各設問”を識別する「設問#」。
- 選択肢識別
- “選択肢”を識別する「選択肢#」が必要。
- よって(b)＝「設問#」「選択肢#」。
- 記録対象
誤りやすいポイント
- 「クーポン#」を“クーポン使用時だけ必要”と考えNULLで管理しようとして漏らす。
- プレゼント機能を“受講生間の別トランザクション”と誤解し、購入テーブルに含め忘れる。
- テスト結果詳細で「テスト#」を入れれば十分と考え、“設問#”を欠落させる。
- 「選択肢#」を追加せず、設問と選択肢を複合コードで表そうとして正規形を壊す。
FAQ
Q: 「プレゼント相手アカウント#」はNULLを許容しますか？
A: 自分用購入とプレゼント購入を同一テーブルで扱うため、NULL許容で実装する設計が一般的です。
A: 自分用購入とプレゼント購入を同一テーブルで扱うため、NULL許容で実装する設計が一般的です。
Q: テスト結果詳細に得点は入れなくてよいのですか？
A: 得点はテスト結果エンティティで集約管理されています。詳細には“どの選択肢を選んだか”だけを保持し、冗長化を防ぎます。
A: 得点はテスト結果エンティティで集約管理されています。詳細には“どの選択肢を選んだか”だけを保持し、冗長化を防ぎます。
Q: クーポン使用人数の上限管理はどこで行いますか？
A: 使用時にコース購入へ挿入するトランザクション内で、クーポンテーブルの使用可能人数を減算する実装が想定されます。
A: 使用時にコース購入へ挿入するトランザクション内で、クーポンテーブルの使用可能人数を減算する実装が想定されます。
関連キーワード: エンティティ、主キー、外部キー、リレーションシップ、正規化
設問2：〔企業向けサービスの追加〕の概念データモデル及び関係スキーマについて答えよ。
問題文を見る（1）図3の概念データモデルは未完成である。図3中の欠落しているリレーションシップを4本補って図を完成させよ。なお、図3に表示されていないエンティティタイプは考慮しなくてよい。
模範解答
解説
解答の論理構成
-
研修カリキュラムとコース
– 【問題文】「研修カリキュラムに含まれるコースには、受講順を設定する。」
– １つの研修カリキュラムは複数コースをもつ。順序という属性が中間表(あ)に格納されるので、｢研修カリキュラム ― (あ) ― コース｣のリレーションシップを追加する。 -
法人受講生とグループ
– 【問題文】「あらかじめ複数の法人受講生を束ねたグループを作成し、グループ単位で割当てを行う。」
– １人の法人受講生は０以上のグループに所属し、１つのグループには複数の法人受講生が入る。所属情報を保持する中間表(い)を置き、「法人受講生 ― (い) ― グループ」を追加。 -
グループと研修カリキュラム
– 【問題文】「同じ研修カリキュラムでも、割り当てられるグループによって、受講開始可能年月日及び受講完了期限年月日が異なる場合がある。」
– 受講開始可能日・完了期限はグループ単位の属性。中間表(う)で管理するため「グループ ― (う) ― 研修カリキュラム」を追加。 -
研修カリキュラムとテスト
– 【問題文】「研修カリキュラムごとに各テストの合格基準点を設定できる。」
– テストごとに基準点(g)をもつので、中間表(お)が必要。「研修カリキュラム ― (お) ― テスト」を追加。
これで欠落していた４本の線（①研修カリキュラム–コース、②法人受講生–グループ、③グループ–研修カリキュラム、④研修カリキュラム–テスト）が補われ、模範解答の構造と一致します。
誤りやすいポイント
- 研修カリキュラムとテストを直接１対多と勘違いし、中間表を作らない
- 法人受講生を研修カリキュラムへ直接割り当ててしまい、【問題文】にある「グループ単位で割当て」を無視する
- 受講順や期限など“リレーションシップ固有の属性”をエンティティ側へ入れてしまう
- 「合格基準点」をテスト側に置き、研修カリキュラムごとの差異を表現できなくなる
FAQ
Q: 研修カリキュラムに含まれるコースは固定順序なのですか？
A: はい。【問題文】で「受講順を設定する」と明示されているため、順序を属性として持つ中間表(あ)が必要です。
A: はい。【問題文】で「受講順を設定する」と明示されているため、順序を属性として持つ中間表(あ)が必要です。
Q: 法人受講生をグループに入れず直接研修カリキュラムへ割当てても動きませんか？
A: ビジネスルールが「グループ単位で割当て」を要求しています。直接割当てでは開始日・期限をグループ別に変える要件を満たせません。
A: ビジネスルールが「グループ単位で割当て」を要求しています。直接割当てでは開始日・期限をグループ別に変える要件を満たせません。
Q: 合格基準点はテストに１つあれば十分では？
A: 企業ごと・研修カリキュラムごとに異なるため、テスト単体では表現できません。「研修カリキュラムとテスト」のリレーションでg(合格基準点)を管理します。
A: 企業ごと・研修カリキュラムごとに異なるため、テスト単体では表現できません。「研修カリキュラムとテスト」のリレーションでg(合格基準点)を管理します。
関連キーワード: エンティティ間リレーション, 中間表, 多対多解消, 属性付リレーション, ビジネスルール
設問2：〔企業向けサービスの追加〕の概念データモデル及び関係スキーマについて答えよ。
問題文を見る（2）図4中の(c)〜(g)に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
c：研修カリキュラム#、受講順
d：グループ#
e：研修カリキュラム#、受講開始可能年月日、受講完了期限年月日
f：アカウント#、研修カリキュラム#
g：研修カリキュラム#、合格基準点
解説
解答の論理構成
- 研修カリキュラムとコースの対応
「研修カリキュラムに含まれるコースには、受講順を設定する。」から、(あ) のブリッジ表には研修カリキュラム#と受講順が必須。よって (c)＝研修カリキュラム#、受講順。 - 法人受講生とグループの対応
「あらかじめ複数の法人受講生を束ねたグループを作成」より (い) の主キーは企業#、アカウント#、グループ#。既に企業#とアカウント#があるので (d)＝グループ#。 - グループと研修カリキュラムの割当
「…グループによって、受講開始可能年月日及び受講完了期限年月日が異なる」から (う) に研修カリキュラム#、受講開始可能年月日、受講完了期限年月日を追加。従って (e)＝研修カリキュラム#、受講開始可能年月日、受講完了期限年月日。 - 法人受講生の進捗管理
「受講を開始すると、研修カリキュラム受講開始日時が記録される。…研修カリキュラム受講完了日時が記録される。」より、(え) は法人受講生と研修カリキュラムの関係。企業# と日時列は既にあるので (f)＝アカウント#、研修カリキュラム#。 - テストの合格基準点
「研修カリキュラムごとに各テストの合格基準点を設定できる。」から (お) には研修カリキュラム# と合格基準点が必要。よって (g)＝研修カリキュラム#、合格基準点。
誤りやすいポイント
- 受講開始可能年月日／受講開始日時の取り違え
前者はグループ単位の“割当条件”、後者は法人受講生単位の“実績”。 - グループ#の配置ミス
会員‐グループ対応は (い) にまとめ、(え) へは入れない。 - 合格基準点をテスト側属性と誤解
要件では「研修カリキュラムごと」に設定するため、テスト単体には持たせない。
FAQ
Q: 研修カリキュラム# を複数の表に入れるのは冗長ではありませんか？
A: 各表の主キーが異なる（コース割当、グループ割当、受講実績、テスト条件）ため、外部キーとして重複しても非正規化にはなりません。
A: 各表の主キーが異なる（コース割当、グループ割当、受講実績、テスト条件）ため、外部キーとして重複しても非正規化にはなりません。
Q: 受講順を主キーに含める必要はありますか？
A: 受講順はコース並び替え用の業務属性であり、一意性は (研修カリキュラム#、コース#) で確保できます。主キーには含めず普通属性で良い、という設計でも減点対象にはなりにくいと想定されます。
A: 受講順はコース並び替え用の業務属性であり、一意性は (研修カリキュラム#、コース#) で確保できます。主キーには含めず普通属性で良い、という設計でも減点対象にはなりにくいと想定されます。
Q: グループが存在しない場合でも法人受講生を研修カリキュラムへ直接割り当てられますか？
A: 問題要件は「グループ単位で割当てを行う。」と限定しているため、直接の割当てはモデル化していません。
A: 問題要件は「グループ単位で割当てを行う。」と限定しているため、直接の割当てはモデル化していません。
関連キーワード: 正規化、多対多解消、ブリッジテーブル、外部キー、主キー
（1）図1の概念データモデル上のリレーションシップを一つ変更する。どのようにリレーションシップを変更すべきか。具体的なエンティティタイプ名を挙げ、40字以内で答えよ。
模範解答
質問とコメントとの間のリレーションシップを1対1から1対多に変更する。
解説
解答の論理構成
- 現行モデルの把握
図1・図2より “質問” と “コメント” が1本の線で接続され、主キーに “質問#” のみを含むため 1対1 であると分かります。 - 新規要件の確認
【問題文】「質問に対して回数に制限なくコメントできるようにしてほしい」→ “質問” 当たり複数 “コメント” が必要。 - モデルへ与える影響
① 1:多 が必要
② “コメント#” を主キーとし、“質問#” を外部キーへ格下げ
③ 図1のリレーションシップ線を1:多 に描き替える - したがって、変更内容は
「質問とコメントとの間のリレーションシップを1対1から1対多に変更する。」
誤りやすいポイント
- “質問だけではなく、既出のコメントを指定してコメントできる” を読み、「コメント ↔ コメント」の自己参照を追加すると誤解する
- 主キー追加だけで済むと考え、リレーションシップのカーディナリティを書き換え忘れる
- “質問#” を残したまま複合主キーにしてしまい、多重コメントが登録できない構造を作る
FAQ
Q: 主キーを “コメント#” にする理由は何ですか？
A: “コメント#” を独立した主キーにすることで、同じ “質問#” を持つ複数行が登録でき、1:多 関係が実現します。
A: “コメント#” を独立した主キーにすることで、同じ “質問#” を持つ複数行が登録でき、1:多 関係が実現します。
Q: “質問だけではなく、既出のコメントを指定してコメントできる” はどのように対応しますか？
A: “コメント” エンティティに “親コメント#” （自己外部キー）を追加し、ツリー型で管理するのが一般的です。本設問はカーディナリティ変更のみ問われています。
A: “コメント” エンティティに “親コメント#” （自己外部キー）を追加し、ツリー型で管理するのが一般的です。本設問はカーディナリティ変更のみ問われています。
Q: リレーションシップ変更時にER図で注意することは？
A: “質問” 側を1、本来の “コメント” 側を 多（カラスの足）で描き、既存の1:1線を更新することです。
A: “質問” 側を1、本来の “コメント” 側を 多（カラスの足）で描き、既存の1:1線を更新することです。
関連キーワード: カーディナリティ、概念データモデル、外部キー、主キー、ER図
（2）図1の概念データモデルに新しくリレーションシップを二つ追加する。どのようにリレーションシップを追加すべきか。具体的なエンティティタイプ名を挙げ、それぞれ40字以内で答えよ。
模範解答
①：アカウントとコメントとの間に1対多のリレーションシップを追加する。
②：コメントに自己参照型の1対多のリレーションシップを追加する。
解説
解答の論理構成
- 要望分析
【問題文】では「誰がコメントしたかを特定できるように」「既出のコメントを指定してコメントできる」とあります。 - エンティティの特定
①「誰がコメントしたか」は “アカウント” と “コメント” の関係で示す必要がある。
② 「コメントへのコメント」は “コメント” が親‐子関係をとる自己参照で実装するのが自然。 - リレーションシップ形態
・一人のアカウントは複数のコメントを投稿できるため1対多。
・一つのコメントに複数の返信が付くため自己参照も1対多。 - 多対多を避ける
問題指示「“多対多” のリレーションシップを用いないこと」より、いずれも1対多 と確定します。
誤りやすいポイント
- 「コメント」⇔「質問」を多対多に追加してしまう
→既に「質問#」外部キーで従属しているので不要です。 - 自己参照を“多対多”と解釈する
→返信側が親コメントを1つだけ参照すれば十分。 - 「講師」のみと結び付ける
→要望は「他の講師及び受講生」も対象です。必ず共通の「アカウント」を使います。
FAQ
Q: 自己参照リレーションシップは別テーブルで実装すべきですか？
A: 問題指示は概念モデルなので、エンティティ「コメント」内に外部キーとして “親コメント#” を持たせる形で1対多 を表せば十分です。
A: 問題指示は概念モデルなので、エンティティ「コメント」内に外部キーとして “親コメント#” を持たせる形で1対多 を表せば十分です。
Q: 既存の「コメント」エンティティに属性を追加する必要はありますか？
A: 主キーを “コメント#” に変更し、親コメントを示す外部キー “親コメント#” を追加するだけで要件を満たせます。
A: 主キーを “コメント#” に変更し、親コメントを示す外部キー “親コメント#” を追加するだけで要件を満たせます。
Q: 「アカウント」が不要で「受講生」「講師」と直接結んでもよいですか？
A: 受講生・講師の両方が投稿者になり得るので、上位の「アカウント」と結ぶのが正解です。
A: 受講生・講師の両方が投稿者になり得るので、上位の「アカウント」と結ぶのが正解です。
関連キーワード: 自己参照リレーションシップ、1対多、外部キー、主キー、データモデリング
