【AP】令和7年秋午後問6データベースの解説（応用情報技術者試験）

このNoteでは「応用情報技術者試験 令和7年秋午後問6（データベース）」の解説をします。

AP問06は地雷が多いですが、今回は大丈夫な方でした。積極的に点数を稼ぎたいです。

SQL-ALTER文の登場は驚いたので、SELECT文以外のSQLについて全体的に補強する節も作ったんので、是非参考にして下さいね。このNoteで復習労力を少しでも省力できたら嬉しいです。

このNoteでは、私がIT以外の学生時代にAPに独学合格した経験と、大学・IT専門学校で応用情報技術者試験の対策授業を担当した経験を詰め込んで作りました。

それでは始めましょう！

※このNoteは後日有料になります。お早めにお読みください。その後はマガジンに追加されます。マガジンも値上げしますので、お早めにご購入ください。

ほぼマーキングしなくても良かった

今回はあまりマーキングはしなかったですね。
＞長文問題を読む６つのテクニックNote（３）

データベース設計は問題文の仕様を、ER図とスキーマ（表, 項目）に書き出す作業です。

• エンティティ（表）になりそうなら四角囲み

• 項目になりそうなら四角囲み

• キーが分かりそうなら四角囲み
  　※「一意」「識別」→主キー

• リレーションになりそうなら丸囲み
  　※「1つ」「複数」など

でも今回は表1にまとまってて、問題文は少ないのでマーキングも少なくなりました。マークしなくても正解できますが、練習・習慣なので気を抜かずに取り組んで欲しいです。

設問1b | ヒントないので常識で目星

正答は「←」

bの方が最初に決まり易かったので、解説順を変えました。

浅く簡単に解きます。本試験でも短時間で「←」だと判断して、少し確認したら解答して良いですよ。次々節でがっつり考えます。

印象として、【受講予約・結果】多←1【開催スケジュール】じゃないと困るんですよね。1つの開催に多くの予約が紐づくはずなので。

図1までの問題文、念のため図1直後の問題文を見ても、記述がないので常識で目星付けるしかないです。

ER図で「多対多（↔）」は考えません。

データベースは第三正規形を目指しますが、多対多は、1対多と多対1に分解します。

間に「連関エンティティ」をクッションとして組み入れます。もし「多対多」が存在する時、必ず分割する問題が出ます。＞【DB】ER図のパターンNote（連関エンティティ）

設問1a | 多側に「1側主キー」＋「新主キー」

正答は「開催番号」。主キーを示す「下実線」も忘れずに。

【空欄b=「←」】が成立するように、考えます。

1対多では、1側の主キーを、多側の主キーにし、更にもう1つ主キーを追加します。例えば【発注（発注番号）】→【発注明細（発注番号, 明細番号）】のように。

【開催スケジュール（講座コード, 開催番号）】の主キー2つがコピーされてるか。【受講予約・結果（受講者コード, 講座コード）】なので「愛妻番号」がありません。

【空欄a=開催番号】、しかも主キーを示す「下実線」、だと判断できます。

なお【受講者（受講者コード）】→【受講予約・結果（受講者コード, 講座コード, 開催番号）】は問題ありません。

受講者コードが両方にあるし。1つの受講者コードに対して、多くのパターンが、講座コードと開催番号で作られますので。

詳細 | 主キーと実務で考える

【注文】→【注文明細】の場合、主キーは【注文（注文番号）】→【注文明細（注文番号, 明細番号）】のように、多の方の主キー（明細番号）が増えるのが普通。＞【DB】ER図のパターンNote（1対多）

1対1の場合、主キーが同じ（個数も同じ）である場合が王道。

図1。【開催スケジュール（講座コード, 開催番号）】ー【講座担当割当（講座コード, 開催コード）】は、主キーが同じ（個数も2個で同じ）。

1対多の場合、多側の主キーは、1側の主キーに追加されるのが王道。

図1。【講師（講師コード）】→【講座担当割当（講師コード, 開催番号）】。他にも、【講座（講座コード）】→【開催スケジュール（講座コード, 開催番号）】。【講師（講師コード）】→【勤務日（勤務年月日, 講師コード）】

図1に既にある【受講者】→【受講予約・結果】から、【空欄a】を考えて見ます。

現状でも【受講者（受講者コード）】→【受講予約・結果（受講者コード, 講座コード）】なので、問題ない感じ。

実務を考えても問題なし。1人の【受講者】が多くの【受講予約・結果】をもつのは自然。各講座での「出席」が記録され「評価」「アドバイス」が講師によって入力される。

少なくとも、今は【空欄a】の必要性は感じませんね。

【空欄b=「ー」】の場合。

現状【受講予約・結果（受講者コード, 講座コード）】ー【開催スケジュール（講座コード, 開催番号）】では不充分。個数は一致するけど、主キーが一致しない。受講者コードと開催番号が同じ役割を果たすとは思えないので、追加が必要。

【空欄a】に受講者コードor開催番号の追加が必要かな。

でも実務を考えると違和感あり。

「－」だと、1つの【開催スケジュール】に1つの【受講予約・結果】しか紐づけできない。【受講予約・結果】の主キーに受講者コードがあるので、1人しか予約できない。

逆方向は問題なし。1つの【受講予約・結果】に1つの【開催スケジュール】が紐づくのは自然。

よって
【受講予約・結果】ー【開催スケジュール】ではなさそう。
【受講予約・結果】←【開催スケジュール】の可能性が高い。
【空欄b=「←」】の可能性が高い。

【空欄b=「←」】の場合。

現状【受講予約・結果（受講者コード, 講座コード）】←【開催スケジュール（講座コード, 開催番号）】では不充分。

開催番号（主キー）追加が必要。

【受講予約・結果（受講者コード, 講座コード, 開催番号）】←【開催スケジュール（講座コード, 開催番号）】

実務を考えます。

1つの【開催スケジュール】、多くの【受講予約・結果】が紐づくのは自然。複数人が受講するので。

【受講予約・結果】←【開催スケジュール】と判断。
【空欄b=「←」】だと判断。
【空欄a=開催番号】の可能性が高い。

【空欄b=「→」】の場合。もう必要ないですけどね。

現状【受講予約・結果（受講者コード, 講座コード）】→【開催スケジュール（講座コード, 開催番号）】は不充分。

【開催スケジュール】に「受講者コード」を主キー追加する必要あり。「受講者コード」の役割を「開催番号」が果たすとは思えない。でも項目追加するための空欄なし。

実務を考えます。

「ー」の時と同じ疑問が出ます。1つの【開催スケジュール】に1つの【受講予約・結果】しか紐づけできない。1開催に1人しか予約できない。

最後に【空欄a=開催番号】が問題ないか、最初に考えた【受講者】→【受講予約・結果】で考えてみます。空欄aの主キー追加で問題発生したら意味ありませんから。

【受講者（受講者コード）】→【受講予約・結果（受講者コード, 講座コード, 開催番号）】。問題ありません。

設問2(1)cd | 共通するのは？

正答は「レベル」「ジャンル」。
※順不同

図2で、【空欄c】【空欄d】が【ビジネス英会話講座】【日常英会話講座】の両方にあります。

表1で両方ある項目っぽいものを考えます。
○「レベル」
○「ジャンル」
×「年齢層」
受講形態：内容は人数制限のように見えます。図1の【講座】に「最大受講者数」がある。たぶんこれかなぁ。
予約方法：両方で違いそう。

以上から「レベル」「ジャンル」かなと。理由は次設問2(2)。

設問2(2) | 自分なりの言葉で

模範解答は「定義域が講座区分によって異なるから」

例えば、同じ表にジャンル15種類と10種類がゴチャるの嫌ですね。しかも【日常英会話講座】は「変更の可能性あり」なので、後で削除や変更なども大変そう。

模範解答を解釈してみます。「定義域が講座区分によって異なるから」。

「定義域」とは取りえる範囲。例えば「xが1～3の値を取る」など。

模範解答は、講座によって「レベル」と「ジャンル」が違う値を取るから、という意味。レベルは3種類と6種類、ジャンルは15種類と10種類のように、取りあえる値が異なることを指してます。

設問2(3)e | 片方だけに必要な項目は？

模範解答は「年齢層」

図2【空欄e】は【日常英会話講座】にしかない項目ですね。

表1を見ると「年齢性」だと判断できます。

「年齢層」は【ビジネス英会話講座】では「なし」なので項目不要。【日常英会話講座】では、3種類の区分を記録。

設問3f | SQL以外も覚えていきたい

正答は「ALTER」

知らなければ無理なので、今後正解できるようになりましょう。

ALTER文の中で、更にADD（項目追加）, DROP（項目削除）, RENAME（項目名を変更）を使って操作を指定します（wikipediaに例示あり）。

補強 | SQLをまとめた

SQLについて、視野を広げて体系的にまとめます。

今後ALTER以外が出る可能性が高くなりましたから。

SQLには「3種類」

SQL文には、3種類あります。wikipedia

SQL=SELECT文=データの抽出 のイメージですが、他のSQLもあります。

表や項目を作ったり消したり、データを入れたり消したり変更したり、表へのアクセスを制御するSQLなどなど。

役割で3種類に分類されます。
※覚えておきたい/覚えやすいSQLは「太字」。

• DDL：表や項目を「定義」する文
  表・項目を設定する（データ入力ではない）
  「CREATE」, 「ALTER」, 「DROP」, RENAME

• DML：データを「操作」する
  データを抽出, 更新, 追加, 削除する
  「SELECT」, 「UPDATE」, 「INSERT」,「DELETE」
  ※DROPじゃなくてDELETEなの注意。

• DCL：「権限」を制御する
  表への利用者のアクセス許可/拒否を設定
  「GRANT」, REVOKE

基本情報技術者試験（FE）科目Aに出てます。「CREATE TABLE」「CREATE VIEW」「UPDATE」「INSERT」「GRANT」「DELETE」は＞【FE】SELECT以外のSQLのNote

ALTERが属すDDL

今回の「ALTER」が属するDDLだけピックアップ。

• CREATE：表（テーブル）、ビューを作成
  CREATE TABLE, CREATE VIEW

• ALTER：既存の表の構造（項目など）を変更
  ALTER TABLE 表名 の後に「ADD」「DROP」で項目の追加/削除。 

• DROP：表を削除

• RENAME：表名、項目名を変更

ALTERの使い方

ALTER TABLE 表名 の後に「ADD」「DROP」で項目の追加/削除。

wikipedia例示から2文。

ALTER TABLE 従業員 ADD 生年月日 DATE;
既にある表「従業員」に項目「生年月日」を日付型（DATE）で追加（ADD）。

ALTER TABLE 従業員 DROP COLUMN 生年月日;
既にある表「従業員」にある項目「生年月日」を削除（DROP）。

テキストやwikipedia（SQL文例8個）をざっくり見ると良いですね

設問4g | 外部キーと参照制約

正答は「勤務年月日, 講師コード」

FOREIGN KEYは「外部キー」のこと、REFERENCESが「参照」する先を指定。

図4の「FOREIGN KEY（勤務年月日, 講師コード）」は、表「勤務可能時間（CREATE TABLEで指定済み）」の項目「勤務年月日」「講師コード」が外部キーであり、別表の項目を参照するよ、という意味。

外部キーが参照する先は「REFERENCES 勤務日（【空欄g】）」に書かれます。表「勤務日」の項目「【空欄g】」。

図1【勤務日】を見ると、項目は「勤務年月日」「講師コード」だけ。【勤務可能時間】の「勤務年月日」「講師コード」と一致してるので、紐づければOK。

設問4h | 答えを書いてくれてた

正答は「CASCADE」

ヒントはありました。図3に「CASCADE」。

図3を解釈していれば正解できます。分からなくても勘でも書けばOK。空欄よりはマシ。

図3のSQL3行は、
・表【講座】に項目「講座区分」を追加
・表【講座】の項目「レベル」を削除
・表【講座】の項目「ジャンル」を削除

末尾の「CASCADE」は、表【講座】の項目「レベル」や「ジャンル」を、別表の項目が参照している時、参照制約（かつてCREATE文でREFERENCESで指定してた）を解除すること（wikipedia-cascade）。

設問5i | AP常連のJOIN&ON

正答は「ON t0.講座コード = t1.講座コード AND t0.開催番号 = t1.開催番号」

正解して下さい。APはJOIN大好きですからね。外部結合で良く出てきました。直近4回中で3回も。
＞【AP】令和07春問6のNote
＞【AP】令和06秋問6のNote
＞【AP】令和06春問6のNote

「JOIN」があるので、結合する条件を指定する「ON」があります。しかし図5には「ON」がありません。

「WHERE」を見ると、t1（表：講座担当割当）とt0（表：開催スケジュール）の項目に条件を付けて「SELECT」文で結果表示。

つまり「SELECT文」を走らせるためには、t1とt0の結合（JOIN）が必要だというこおｔ。

t1（表：講座担当割当）とt0（表：開催スケジュール）を結合「JOIN」するために、紐づける項目を考えます。

図1より
t1【講座担当割当】（講座コード, 開催番号, 講師コード）
t0【開催スケジュール】（講座コード, 開催番号, 開催年月日, 開始時刻, 終了時刻）

したがって模範解答は理解できます。
「ON」：JOINのための条件
「t0.講座コード = t1.講座コード」：主キーでの紐づけ
「AND」：主キーが2つあるので、条件を追加
「t0.開催番号 = t1.開催番号」：主キーでの紐づけ

まとめ

お疲れ様でした！

ALTER（とCASCADE）は不意打ちでしたが、6割は切らず7～9割ですかね。SQLのまとめ補強もできたから演習成果はありました。

APのデータベース問題は正直「地雷」である回が多いです。私は御三家として積極的に解きたいのですが、さすがに警戒するようにになりました。

今回は問題文を眺めれば地雷ではなさそうだと目星つくので、チャンスとして積極的に点数をゲットしたい所です。

私のNoteではIP～SC, DB, NWまで幅広く解説しています。全て私が解いて手作りしてますので、合格者/先生の視点として参考になったら嬉しいです。良かったらまた覗きに来てくださいね。お待ちしてます。

APには、解説以外の戦略Noteも準備しました。

• ＞午後問題を選ぶ3つの視点Note

• ＞午後問題の時間配分Note

• ＞試験当日の持ち物と当日の行動Note

＼全ての無料Noteへのリンク！／

＼全てのAP系Noteが読めます／