データベーススペシャリスト 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回だけできる。できる。各質問に対する講師からのコメントは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に表示されていないエンティティタイプは考慮しなくてよい。
模範解答

解説
解答の論理構成
-
コース購入に関するリレーションシップ
- 【問題文】「受講生は、コースを検索して、…購入する。購入情報…受講生アカウント# は,PF 上に記録される。」
- 上記から購入主体は「受講生」であり、PK である「アカウント#」が外部キー (a) として「コース購入」に入る。
- さらに「アカウント#」はスーパータイプ「アカウント」に属するため、①「アカウント」―「コース購入」と②「受講生」―「コース購入」が必要。
- 【問題文】「クーポンを使用する際は、クーポン#を指定して、購入の手続を行う。」より③「クーポン」―「コース購入」も必須。
-
セクションとテスト
- 【問題文】「セクションは、…高々一つのテストから成る。」
- 1:0‒1 関係で④「セクション」―「テスト」を追加。
-
コンテンツの受講状況
- 【問題文】「受講生は、購入したコース…どのコンテンツから受講してもよい。」
- 受講事実を保持する「コンテンツ受講」に対し、「コンテンツ#」が外部キーとなるため⑤「コンテンツ」―「コンテンツ受講」が成立。
-
テスト結果の格納
- 【問題文】「コンテンツ受講…テストについては全設問に解答した時点…最高獲得点数を記録できる。」
- したがって「コンテンツ受講」と「テスト結果」は 1:0‒1 で結ばれる⑥。
- さらに【問題文】「受講生は、…選択した各設問の選択肢と解答日時を確認することができる。」
→ 選択肢の PK が「テスト結果詳細」に外部キー (b) として入るため⑦「テスト設問選択肢」―「テスト結果詳細」が必要。
誤りやすいポイント
- 「アカウント」経由で全て繋がると誤解し、「受講生」―「コース購入」を省略してしまう。購入主体があくまでサブタイプのため要注意。
- 「セクション」―「テスト」は “高々一つ” の表現を読み落としてしまい、リレーションシップを作らないミス。
- 「テスト結果詳細」は選択肢単位の履歴である点を見逃し、「テスト設問選択肢」との関係を欠落させてしまう。
FAQ
Q: 「アカウント」―「コース購入」と「受講生」―「コース購入」を両方描くのは冗長では?
A: 「購入情報」に保存するキーはスーパータイプの「アカウント#」ですが、購入できるサブタイプは「受講生」に限定されています。したがって両方のリレーションシップが必要です。
A: 「購入情報」に保存するキーはスーパータイプの「アカウント#」ですが、購入できるサブタイプは「受講生」に限定されています。したがって両方のリレーションシップが必要です。
Q: 「セクション」―「テスト」は 1:1 ではなく 1:0‒1 と判断した理由は?
A: 【問題文】「高々一つのテスト」とあるため、テストが存在しないセクションも許容しています。
A: 【問題文】「高々一つのテスト」とあるため、テストが存在しないセクションも許容しています。
Q: 「テスト結果詳細」に直接「テスト設問」を繋がず、「テスト設問選択肢」を繋ぐのはなぜ?
A: 詳細には「選択した各設問の選択肢」を保持すると明記されています。選択肢を特定するには PK 「選択肢#」を持つ「テスト設問選択肢」とのリレーションが必要です。
A: 詳細には「選択した各設問の選択肢」を保持すると明記されています。選択肢を特定するには PK 「選択肢#」を持つ「テスト設問選択肢」とのリレーションが必要です。
関連キーワード: 正規化、外部キー、汎化・特化、1対多関係、エンティティ設計
設問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に表示されていないエンティティタイプは考慮しなくてよい。
模範解答

解説
解答の論理構成
- 子エンティティの外部キー確認
- 【図4】「(い)(企業#、アカウント#、d)」の d は【図2】で主キーとなる「コース#」である。
- 同様に「(う)(企業#、グループ#、e)」の e、「(え)(企業#、f, …)」の f も「コース#」。
- 「(お)(企業#、コース#、セクション#、コンテンツ#、g)」の g は「研修カリキュラム#」。
- 親エンティティの確認
- 「コース#」の親は「コース」、「研修カリキュラム#」の親は「研修カリキュラム」であることは【図4】と【問題文】の記述「研修カリキュラムは、企業ごとに研修カリキュラム#で識別」により明白。
- 業務要件との突合
- 【問題文】「研修カリキュラムに含まれるコースには、受講順を設定する」
→ コースと(え)の接続が必須。 - 「企業は、法人受講生に対して…研修カリキュラムを受講させる」かつ「受講を開始すると…記録される」
→ コースと(い)・(う)への接続が必要(法人受講生/グループの受講記録にコース#が入る)。 - 「研修カリキュラムごとに各テストの合格基準点を設定できる」
→ 研修カリキュラムと(お)の接続が必要。
- 【問題文】「研修カリキュラムに含まれるコースには、受講順を設定する」
- “多対多禁止”規則への適合
- ①〜④はいずれも子エンティティを介した 1 対多構造なので条件を満たす。
誤りやすいポイント
- 子エンティティ名ではなく属性名(コース# 等)から親を推定する手順を忘れる。
- 「法人受講生⇔コース」など直接線を引きたくなるが、問題指示「“多対多” のリレーションシップを用いないこと」に反する。
- 「研修カリキュラム⇔テスト」だけを追加し、「コース⇔(え)」を失念しやすい。
FAQ
Q: 太線・細線の違いは採点対象ですか?
A: 多重度を表す補助記号なので、親子関係を正しく示せば減点対象になりませんが、見やすさのためサンプル解答と同じ表記が推奨されます。
A: 多重度を表す補助記号なので、親子関係を正しく示せば減点対象になりませんが、見やすさのためサンプル解答と同じ表記が推奨されます。
Q: 「企業#」が全ての子エンティティに入っている理由は?
A: 企業向けサービス全体が「企業」スコープで完結するため、複合主キーに「企業#」を含めて一意性と参照整合性を同時に確保しています。
A: 企業向けサービス全体が「企業」スコープで完結するため、複合主キーに「企業#」を含めて一意性と参照整合性を同時に確保しています。
関連キーワード: ER図、外部キー、リレーションシップ、正規化、参照整合性
設問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: 問題要件は「グループ単位で割当てを行う。」と限定しているため、直接の割当てはモデル化していません。
関連キーワード: 正規化、多対多解消、ブリッジテーブル、外部キー、主キー
設問3:受講生からの要望に対応するために、図2の関係スキーマの関係 “コメント”の主キーとして “コメント#” を新たに設け、“質問#” は外部キーへ変更した上で、次の変更を行う。
(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図
設問3:受講生からの要望に対応するために、図2の関係スキーマの関係 “コメント”の主キーとして “コメント#” を新たに設け、“質問#” は外部キーへ変更した上で、次の変更を行う。
(2)図1の概念データモデルに新しくリレーションシップを二つ追加する。どのようにリレーションシップを追加すべきか。具体的なエンティティタイプ名を挙げ、それぞれ 40字以内で答えよ。
模範解答
①:アカウントとコメントとの間に1対多のリレーションシップを追加する。
②:コメントに自己参照型の1対多のリレーションシップを追加する。
解説
解答の論理構成
- 要望分析
【問題文】では「誰がコメントしたかを特定できるように」「既出のコメントを指定してコメントできる」とあります。 - エンティティの特定
①「誰がコメントしたか」は “アカウント” と “コメント” の関係で示す必要がある。
② 「コメントへのコメント」は “コメント” が親‐子関係をとる自己参照で実装するのが自然。 - リレーションシップ形態
・一人のアカウントは複数のコメントを投稿できるため 1対多。
・一つのコメントに複数の返信が付くため自己参照も 1対多。 - 多対多を避ける
問題指示「“多対多” のリレーションシップを用いないこと」より、いずれも 1対多 と確定します。
誤りやすいポイント
- 「コメント」⇔「質問」を多対多に追加してしまう
→既に「質問#」外部キーで従属しているので不要です。 - 自己参照を“多対多”と解釈する
→返信側が親コメントを 1 つだけ参照すれば十分。 - 「講師」のみと結び付ける
→要望は「他の講師及び受講生」も対象です。必ず共通の「アカウント」を使います。
FAQ
Q: 自己参照リレーションシップは別テーブルで実装すべきですか?
A: 問題指示は概念モデルなので、エンティティ「コメント」内に外部キーとして “親コメント#” を持たせる形で 1対多 を表せば十分です。
A: 問題指示は概念モデルなので、エンティティ「コメント」内に外部キーとして “親コメント#” を持たせる形で 1対多 を表せば十分です。
Q: 既存の「コメント」エンティティに属性を追加する必要はありますか?
A: 主キーを “コメント#” に変更し、親コメントを示す外部キー “親コメント#” を追加するだけで要件を満たせます。
A: 主キーを “コメント#” に変更し、親コメントを示す外部キー “親コメント#” を追加するだけで要件を満たせます。
Q: 「アカウント」が不要で「受講生」「講師」と直接結んでもよいですか?
A: 受講生・講師の両方が投稿者になり得るので、上位の「アカウント」と結ぶのが正解です。
A: 受講生・講師の両方が投稿者になり得るので、上位の「アカウント」と結ぶのが正解です。
関連キーワード: 自己参照リレーションシップ、1対多、外部キー、主キー、データモデリング


