コンテンツにスキップ

10-6. 演習問題


1-1. DB に保存する対象クラスへ付ける注釈として最も適切なのはどれか。

  • A. @Entity
  • B. @RestController
  • C. @SpringBootApplication
解答と解説

正解:A. @Entity

  • A が正しい。DB に保存する対象を表す。
  • B は誤り。HTTP の入口である。
  • C は誤り。アプリ起動入口である。

1-2. 主キーを表す注釈として最も適切なのはどれか。

  • A. @Id
  • B. @PostMapping
  • C. @RequestBody
解答と解説

正解:A. @Id

  • A が正しい。主キーを示す。
  • B と C は HTTP 処理に関する注釈であり、主キーとは無関係である。

1-3. Spring Data JPA で基本的な CRUD を扱う土台として最も適切なのはどれか。

  • A. JpaRepository
  • B. StringBuilder
  • C. Comparator
解答と解説

正解:A. JpaRepository

  • A が正しい。基本的な CRUD をまとめて扱える。
  • B と C は Java の別用途クラスであり、永続化とは無関係である。

1-4. JPA が発行した SQL を確認しやすくする設定として最も適切なのはどれか。

  • A. spring.jpa.show-sql=true
  • B. server.port=0
  • C. spring.main.banner-mode=off
解答と解説

正解:A. spring.jpa.show-sql=true

  • A が正しい。JPA が発行する SQL を見やすくする。
  • B と C は別の設定であり、SQL 確認が目的ではない。

1-5. Entity と DTO を分ける主な理由として最も適切なのはどれか。

  • A. DB 保存の都合と API 入出力の都合は責務が違うから
  • B. Java では同じクラスを2回書かないと動かないから
  • C. CSS を適用しやすくするため
解答と解説

正解:A. DB 保存の都合と API 入出力の都合は責務が違うから

  • A が正しい。Entity は DB、DTO は API の契約を主に担う。
  • B と C は誤り。技術的な本質を表していない。

次の文章の空欄を埋めてください。

  1. アプリ再起動後もデータを残すことを (   ) という。
  2. テーブルに保存する対象クラスへ付ける注釈は @**(   )** である。
  3. 主キーへ自動採番を設定する注釈は @**(   )** である。
  4. Entity の CRUD を担う部品を (   ) という。
  5. JPA が内部で発行した SQL を確認するために (   ) ログを見るとよい。
解答欄
解答と解説
  1. 永続化

    データをアプリ再起動後も残すことを指す。

  2. Entity

    テーブルへ保存する対象クラスに付ける。

  3. GeneratedValue

    主キーを自動採番する設定である。

  4. Repository

    Entity の CRUD を担当する部品である。

  5. SQL

    JPA の内部動作を理解する手がかりになる。


3-1. メモリ上の List<Book> ではなく DB 保存へ進む理由を説明してください。

解答欄
解答と解説

3-1. DB 保存へ進む理由

メモリ上の List<Book> はサーバー再起動で消えるため、業務アプリとしては不十分である。DB へ保存すれば、再起動後もデータを保持でき、複数の処理や利用者から同じデータを参照できる。

3-2. Entity と DTO を分けると、どんな変更に強くなるか説明してください。

解答欄
解答と解説

3-2. Entity と DTO を分ける利点

DB のテーブル構造や主キー戦略を変えても、API の外向けフォーマットをすぐに壊さずに済む。また逆に、API の見せ方を変えても DB モデルへの影響を限定しやすい。

3-3. なぜ SQL ログを見ると JPA の理解が深まるのか説明してください。

解答欄
解答と解説

3-3. SQL ログを見る理由

JPA は便利な反面、内部で何をしているか見えにくい。SQL ログを見ることで、「本当に INSERT されたのか」「SELECT が何回走ったのか」が分かり、第5章で学んだ DB の知識と結び付けやすくなる。


自分のアプリで、まず登録だけを 1 ステップで確認してください。

  1. POST /api/books で 1 冊登録する
  2. HTTP 201 が返ることを確認する
  3. その直後にサーバーログで insert into books ... が出るか確認する

この段階で確認できること

  • API 成功と INSERT が対応している
  • save() が本当に DB へ到達している

4-2. 再起動後の取得 (GET) を確認する

Section titled “4-2. 再起動後の取得 (GET) を確認する”

次に、再起動後も残るかだけを確認してください。

  1. いったんサーバーを停止し、もう一度起動する
  2. 再起動後に GET /api/books で一覧取得する
  3. 先ほど登録した本が残っていることを確認する
  4. サーバーログで select ... from books ... が出るか確認する

この段階で確認できること

  • 再起動後も同じ本が取得できるなら、永続化が効いている
  • GET と SELECT が対応している

4-3. 更新 (PATCH) と削除 (DELETE) を確認する

Section titled “4-3. 更新 (PATCH) と削除 (DELETE) を確認する”

保存と取得が通ったら、更新と削除も 1 つずつ確認してください。

  1. PATCH /api/books/{id} で状態を変更する
  2. HTTP 200 と更新後データが返ることを確認する
  3. サーバーログで update books ... が出るか確認する
  4. 次に DELETE /api/books/{id} を実行する
  5. HTTP 204 が返ることを確認する
  6. サーバーログで delete from books ... が出るか確認する
  7. 最後に GET /api/books を実行し、削除した本が含まれないことを確認する

上の 4-1 から 4-3 を試したあとで、次の症状が出たときに最初に確認することを書いてください。

  1. API は 201 を返すのに DB にデータが見当たらない
  2. BookEntity を追加したのにテーブルが作られない
  3. GET /api/books/1500 になる
解答欄
解答と解説

4-1 〜 4-3. 保存・取得・更新・削除の確認観点

API が成功しただけで安心せず、そのタイミングで SQL ログが出ているかを見ると、HTTP 層と DB 層が本当に連動しているか確認できる。登録で INSERT、一覧取得で SELECT、更新で UPDATE、削除で DELETE が出ていれば、JPA の流れを追えている。

4-4. 故障シナリオの切り分け

  1. API は 201 を返すのに DB にデータが見当たらない

    • SQL ログで本当に INSERT が出ているか確認する
    • 接続先 DB が想定したものか確認する
  2. BookEntity を追加したのにテーブルが作られない

    • @Entity が付いているか
    • ddl-auto 設定やスキャン対象パッケージを確認する
  3. GET /api/books/1500

    • 見つからないケースを 404 へ変換しているか確認する
    • サーバーログで例外内容を見る