第10章 データを保存できる形にする

Slide 01. データベースとデータモデリング

第10章では、第9章で整理した支援ステータス機能を、データベースに保存できる形へ置き換えます。ユースケース、用語、状態、ルールを見比べながら、テーブル、カラム、制約、SQLでの確認へ順番につなげます。

Slide 02. この章で持ち帰ること

この章のゴールは、データ設計を自分の言葉で説明できるようにすることです。何を保存するか、どう関係づけるか、どの値を入れてよいかを決めます。制約でおかしなデータが入りにくいようにし、SQLでユースケースを確認します。

Slide 03. 第9章からつなげる

第9章では、メンター、受講者、学習ログ、支援ステータスという言葉とルールを整理しました。第10章では、それをRDB、つまりリレーショナルデータベースの表と関係に置き換えます。ここで作る設計は、第11章でAPIを作るときの土台になります。

Slide 04. DB設計が後から効く

DB設計は、API、画面、テスト、運用に長く影響します。保存する意味が曖昧なままだと、APIの返し方、画面の表示、テストの期待値でも同じ曖昧さが繰り返されます。だから最初に、業務上の意味とルールを、DBに保存できる形にします。

Slide 05. アプリDB設計に絞る

この章では、Webアプリケーションを動かすためのDB設計に集中します。分析用のSQLや大きなデータ基盤の話は広げすぎません。まずは、データを追加する、取り出す、更新する、表をつなぐ、制約を確認する範囲を扱います。

Slide 06. RDBの基本単位

RDBは、データをテーブル、行、カラムとして扱います。テーブルは同じ種類の対象を集める場所です。行は1件のデータ、カラムは名前や作成日時のような項目です。Excelのシートに似て見えますが、関係と制約まで設計する点が大事です。

Slide 07. 主キーと外部キー

主キーは、行を一意に識別するための値です。外部キーは、別のテーブルとの関係を表す値です。受講者IDで受講者を見分け、学習ログにはその受講者IDを持たせます。そうすると、どのログが誰のものかをDB上でたどれます。

Slide 08. 題材を再確認する

題材は、メンターが担当受講者に支援ステータスを付けられる機能です。支援ステータスは、noneは未設定、needs_supportは支援が必要、のように値を決めます。初回リリースでは、自動アラートや分析ダッシュボードは扱いません。

Slide 09. 用語からテーブル候補へ

第9章の用語集から、保存したい対象を選びます。受講者、メンター、学習ログはテーブル候補になりやすい概念です。支援ステータスは、受講者ごとの今の状態だけを持つのか、変更の履歴まで持つのかを考えます。

Slide 10. 関係をテーブルにする

担当関係は、メンターと受講者をつなぐ別テーブルにします。たとえば mentor_assignments というテーブルにすると、誰が誰を担当するかを確認できます。この関係は、担当受講者だけを操作できるかを確認するときにも使えます。

Slide 11. カラム設計を見る

カラム設計では、まず名前、意味、型、必須かどうか、入れてよい値を見ます。余裕があれば、初期値、誰が変えるか、いつ変わるかも確認します。statusという名前を使うときも、何の状態なのかを明確にします。

Slide 12. 状態値を扱う

支援ステータスは、入れてよい候補を先に決めます。最初は文字列で持ち、CHECK制約やコード側の候補で守る形から始めると理解しやすいです。値が増えそうなら、別テーブルに分ける案も検討します。

Slide 13. 制約の役割

制約は、DBに入れてよいデータの条件を決める仕組みです。主キー、外部キー、NOT NULL、UNIQUE、CHECKを使うと、存在しない受講者を参照したり、定義外のステータスを入れたりするミスを減らせます。

Slide 14. 制約の例を見る

たとえば、同じメンターと受講者の担当関係を重複させないなら、mentor_idとlearner_idの組み合わせを一度だけ登録できるようにします。支援ステータスを決めた値だけにしたいなら、CHECK制約で許可する値を示します。

Slide 15. 正規化の基本

正規化は、同じ意味のデータを何度も持たないための考え方です。受講者名を学習ログの各行にコピーして持つと、名前が変わったときに片方だけ古いまま残る危険があります。重複による不整合を減らすために、どのテーブルに何を置くかを整理します。

Slide 16. 現在値と履歴

支援ステータスを今の状態だけで持つと、一覧表示や更新はシンプルです。履歴を持つと、いつ誰が変更したかを追えますが、設計と実装は少し複雑になります。どちらがよいかは、ユースケースと初回リリースの範囲で判断します。

Slide 17. SQLで確認する

SQLは、データベースに対して何を保存し、何を取り出すかを確認する言語です。まずは一覧を取る、追加する、更新する、表をつなぐ、条件で絞る、という操作を試します。設計したテーブルで、実際のユースケースを満たせるか見ます。

Slide 18. 担当受講者一覧を取る

最初の確認は、メンターの担当受講者一覧を取得できるかです。受講者、担当関係、支援ステータスの3つの表をつないで、担当する受講者と今の支援ステータスを一覧にします。SQLを書いてみると、関係の持ち方が自然か見えてきます。

Slide 19. 制約違反も試す

SQL確認では、成功する操作だけでなく、失敗すべき操作も試します。存在しない受講者IDを参照できないか、定義外のステータスを入れられないか、担当関係を重複登録できないかを見ると、制約が効いているか確認できます。

Slide 20. インデックスの入口

インデックスは、検索を助けるための仕組みです。よく使う検索条件や、表をつなぐ条件から候補を考えます。ただし増やせばいつも良いわけではありません。mentor_idで担当受講者を探すなら、その検索を支える候補として検討します。

Slide 21. トランザクションの入口

トランザクションは、複数の更新をひとまとまりに扱うための仕組みです。支援ステータスを更新し、同時に支援履歴を追加する場合、片方だけ成功すると困ります。まとめて成功させるか、まとめて失敗させるために使います。

Slide 22. マイグレーションを意識する

DBスキーマは、プロダクトの変更に合わせて変わります。テーブル追加、カラム追加、制約追加は、既存データにも影響します。たとえばstatusカラムを追加するなら、今ある行に入れる値も考えます。PRでは、変更内容と確認結果を書けるようにします。

Slide 23. AIにスキーマ案を頼む

AIには、テーブル候補、カラム候補、制約候補、確認SQLの初稿を出してもらえます。依頼するときは、第9章の用語、ルール、対象外を渡します。ただし、実データや機密情報は入れません。判断が必要な点も分けて出してもらいます。

Slide 24. 検証責任は人が持つ

AIが出したスキーマ案を採用する前に、既存データに問題が出ないか、命名規則に合うか、使うDBで動くかを確認します。SQLは手元で実行するか、設計材料と照合します。データの意味と移行リスクは、最後に人が判断します。

Slide 25. 個人開発にも使う

個人開発でも、保存するデータと関係は多くの場合出てきます。ユーザー、投稿、コメント、予約、支払いなど、テーマが変わっても考え方は同じです。データモデル、制約チェック、SQL確認ログを軽く残すだけで、後半の実装が進めやすくなります。

Slide 26. 演習1 テーブル候補

演習1では、第9章のドメインモデルからテーブル候補を作ります。保存する対象、関係、状態値、テーブルにしない用語を分けます。最後に、なぜそのテーブルが必要か、どの場面で使うかを自分の言葉で説明します。

Slide 27. 演習2 カラムと制約

演習2では、カラムと制約を設計します。主キー、外部キー、必須、UNIQUE、CHECKを並べ、DBで防ぐことと、アプリケーションコードで確認することを分けます。どこで何を確認するかが、レビューで説明する材料になります。

Slide 28. 演習3から5 SQL確認へ

演習3ではschema-draft.sqlにテーブル案を書きます。演習4ではSQLで一覧取得や制約違反を確認します。演習5では、変更内容、既存データへの影響、確認結果をDB変更メモに残します。この材料を持って、第11章のバックエンドAPIへ進みます。