www.youtube.com 本動画では、令和7年度 秋期 応用情報技術者試験 午後問6（データベース）を題材に、英会話オンライン教育サービス企業が「ビジネス英会話」に加えて「日常英会話」を新設することに伴い、受講管理システムを改修する事例を、E-R図の読解と修正、スーパータイプ／サブタイプ設計、定義域制約の扱い、DDLによるテーブル定義変更、参照整合性制約、そして複合主キーを前提としたJOIN条件の組み立てという観点から、与えられた過去問題と解答例に沿って解説します。本問で合否を分けるのは、SQL文法の知識量というより、業務要件の差分をデータモデルへ正しく反映する設計判断と、その判断が主キー・外部キー・結合条件に一貫して現れるように答案を組み立てられるかです。採点講評で評価されやすい答案は、属性名を当てるだけでなく、なぜその属性を親に残さず子へ分離するのか、なぜ複合主キーの全要素を外部キーや結合条件に含めるのかを、要件と整合する理由として説明できています。 設問1はE-R図の完成で、まず「受講予約・結果」エンティティの主キーの構成要素を補う問題が出ます。親である「開催スケジュール」が「講座コード」と「開催番号」の複合主キーで一意に識別される以上、子である「受講予約・結果」は、どの回の開催に対する予約・結果なのかを特定するために、親の主キーを外部キーとして保持しなければなりません。もし「講座コード」と「受講者コード」だけでは、同一講座が複数回開催される前提の下で対象回を識別できず、参照整合性も設計として成立しません。したがって不足する主キー要素は「開催番号」になります。続く多重度の設問は、1つの開催スケジュールに対して複数の受講者が予約を入れるので、開催スケジュール1に対して受講予約・結果が多となる関係を、図の表記規則に従って矢印方向で示すものです。ここでの難所は、ER図の見た目の矢印に引っ張られることではなく、業務として「1開催に複数予約が乗る」という事実を起点にカーディナリティを決めることです。 設問2はスーパータイプ／サブタイプの導入で、本問の中心論点になっています。ビジネス英会話と日常英会話は、どちらも「講座」という上位概念に属する一方で、表1に示されるように、レベルやジャンルといった一見共通に見える属性でも、取り得る値の範囲が異なり、さらに日常英会話にのみ年齢層の概念が存在します。ここで問題文は、講座の種類ごとに表1に沿った値以外を格納できないよう定義域制約を適用することを求めています。したがって、定義域が講座区分によって異なる属性をスーパータイプに残してしまうと、単一の列に対して講座区分別の異なる制約を適用しにくくなり、要件で求められる制約の厳密さが担保できません。このため、定義域の差が明確な「レベル」と「ジャンル」はサブタイプ側へ移し、ビジネス用・日常用でそれぞれ適切なCHECK制約等を掛けられる設計にする、という判断になります。さらに日常英会話講座にのみ存在する固有属性としては「年齢層」が該当し、これは日常英会話のサブタイプにのみ追加するのが自然です。午後問題で差が付くのは、スーパータイプ／サブタイプを「属性が違うから分ける」という一般論ではなく、「同名属性でも定義域が違うため分ける」という設計上の必然を説明できるかであり、ここが採点講評で強調されやすい論点です。 設問3はテーブル定義変更のSQLで、既存テーブルに列を追加・削除する操作が含まれるため、DDLとして用いるコマンドはALTER TABLEとなります。ここは単純な穴埋めに見えますが、改修案件で頻出の「既存テーブルをどう変えるか」という文脈で、CREATEではなくALTERであることを確実に押さえておく必要があります。 設問4は参照整合性で、勤務可能時間テーブルが勤務日テーブルを参照する外部キーを定義する場面です。参照先である勤務日の主キーが複合主キーである以上、外部キー制約でも参照先の主キー列を全て指定しなければ整合性は成立しません。したがって参照先列は「勤務年月日」と「講師コード」の両方になります。さらに、親である勤務日の行が削除されたとき、子である勤務可能時間の行も自動削除されるという要件は、ON DELETE CASCADEで実現されるため、キーワードはCASCADEになります。この設問の難所は、複合主キーの片方だけを参照してしまう誤りと、削除時の動作をSET NULLなどと混同する誤りで、どちらも「主キーは一式で識別」「要件が自動削除ならCASCADE」という原則を徹底すれば回避できます。 設問5はJOIN条件で、開催スケジュールと講座担当割当を結合して、指定日に特定講師が担当している講座コードを取得するSQLを完成させます。ER図上、両テーブルは開催単位で対応付くため、結合は開催スケジュールを一意に識別するキー、すなわち「講座コード」と「開催番号」の組で行う必要があります。したがって結合条件は、t0.講座コード=t1.講座コードかつt0.開催番号=t1.開催番号という複合条件になります。午後データベース問題の頻出失点は、結合条件を講座コードだけで済ませてしまい、開催番号の違う行が誤結合してしまうことなので、ここは複合主キーの全要素をJOINに含めるという姿勢がそのまま得点に直結します。 令和7年度 秋期 応用情報技術者試験 午後問6は、業務要件の差分をデータモデルへ反映し、制約で品質を担保し、複合主キーを前提に参照整合性と結合条件を一貫させるという、データベース設計とSQL実装の基礎体力を総合的に問う問題です。難所は、同名属性でも定義域が異なるならサブタイプへ分離するという判断、親が複合主キーなら子もJOINも必ずその全要素を持つという一貫性、そして削除時の動作を要件どおりCASCADEで表現する点にあります。本動画を見ることで、ER図の修正、スキーマ設計、DDL、参照整合性、JOINが一つの設計判断の連鎖として理解できるようになり、同種の改修案件型DB問題でも、与件から制約とキーを抽出して安定して得点するための再現性の高い解き方が身に付きます。最後に、この動画を視聴する意義は、単発の穴埋めを暗記することではなく、定義域の差を設計で表現する発想と、複合主キーの一貫運用という午後試験の頻出落とし穴を確実に回避する思考手順を獲得し、データベース分野で合否を分ける設計系設問を得点源に変える点にあります。
