手を動かしながら学ぶデータモデリング - 論理設計から物理設計まで / Data modeling

JJUG CCC 2025 Fallの登壇資料です。
https://jjug.doorkeeper.jp/events/190868

# 参考資料
- https://agilejourney.uzabase.com/entry/2022/07/28/103000
- DMBOK（Data Management Body of Knowledge）
- https://amzn.to/33QPAdv
- https://amzn.to/3xHwP8R
- https://amzn.to/3CGNm0p
- https://amzn.to/43J8hiR
- https://amzn.to/4jBL4nL

# お題
- https://gist.github.com/soudai/dd93d925380e8db27542a3f2904d1f78
- https://github.com/soudai/explain-analyze-training/tree/main/docker/src/design_parking

Transcript

1. JJUG CCC 2025 Fall 
 手を動かしながら学ぶデータモデリング
 - 論理設計から物理設計まで

2. タイムテーブル
 
 
 What is it?

3. 1. 座学 40分程度
 2. データモデリング ワークショップ
 a. 前半 20分 + 解説 10分
 b. 後半 20分 + 解説 10分
 3. まとめ
 タイムテーブル

4. 1. データモデルの3層構造の理解
 2. 要件からモデリングする過程の体験
 3. 変化に強いデータモデルの理解
 What is it?

5. 今日のゴール
 
 
 What is it?

6. データモデリングがなぜ重要か
 
 
 What is it?

7. AIは未来を想像してくれない 初期設計
8. AIは未来を想像してくれない 初期設計 仕様追加
9. AIは未来を想像してくれない 初期設計 仕様追加 将来を見据えたテーブルの修正をしないと 次の仕様追加に耐えられない
10. AIは未来を想像してくれない 初期設計 仕様追加 仕様追加
11. AIは未来を想像してくれない 初期設計 仕様追加 仕様追加 マジカルな設計によって 開発ができなくなる
12. データモデリングがなぜ重要か
 ↓
 AIは未来を想像してくれない
 What is it?

13. データモデリングがなぜ重要か
 ↓
 AIは未来を想像してくれない
 What is it?
 将来の設計を考慮して提案してくれるわけではない
14. だからこそ、データモデリングが大事！
 
 
 What is it?

15. “大事なのは できる という経験を得ること”
 
 – 宇宙兄弟 145話 
 What is it?
16. できる！を体験して
 
 データモデリングを理解していきましょう
 What is it?

17. 1. 自己紹介
 2. データモデリングの3層構造
 3. データモデリングの進め方
 4. 駐車場のデータモデリング
 5. おわりに
 あじぇんだ

18. 1. 自己紹介
 2. データモデリングの3層構造
 3. データモデリングの進め方
 4. 駐車場のデータモデリング
 5. おわりに
 あじぇんだ

19. 自己紹介
 曽根 壮大（41歳）
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO 兼 COO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

21. 1. 自己紹介
 2. データモデリングの3層構造
 3. データモデリングの進め方
 4. 駐車場のデータモデリング
 5. おわりに
 あじぇんだ

22. データモデリングの3層構造
 
 
 データモデリングの3層構造
23. データモデリングの3層構造
 ↓
 データモデルと3層スキーマ
 データモデリングの3層構造
24. データモデリングの3層構造 外部スキーマ 概念スキーマ 内部スキーマ 論理スキーマ 物理スキーマ ユーザから見えている部分 概念データモデル 論理データモデル 物理データモデル ANSI/SPARC 3層スキーマ アプリケーションの画面やイン ターフェース
25. 概念スキーマ データモデリングの3層構造 外部スキーマ 内部スキーマ 論理スキーマ 物理スキーマ ユーザから見えている部分 概念データモデル 論理データモデル 物理データモデル 今日の対象 概念データモデル 論理データモデル 物理データモデル ザックマンフレームワークの データモデル分類
26. 概念スキーマ データモデリングの3層構造 外部スキーマ 内部スキーマ 論理スキーマ 物理スキーマ ユーザから見えている部分 概念データモデル 論理データモデル 物理データモデル 今日の対象 概念データモデル 論理データモデル 物理データモデル ザックマンフレームワークの データモデル分類
27. 概念データモデル
 
 
 概念データモデル

28. 概念データモデル
 ↓
 必要な概念を整理する
 概念データモデル

29. • 対象(エンティティ)と関係(リレーション)を整理したもの
 • 概念データモデルはER図ではない
 ◦ ER図より一段抽象度が高い
 ◦ オブジェクト図やドメインモデル図が近い
 • リソースとイベントに分けて考えると良い
 概念データモデル

30. エンティティ
 ||
 リソースとイベント
 概念データモデル

31. リソース（モノ）とイベント（コト）
 
 
 概念データモデル

32. リソース（モノ）とイベント（コト）
 ↓
 5w1h
 概念データモデル

33. リソース
 ↓
 登録するモノ
 概念データモデル

34. リソースとは
 • 事実を生み出す元になるモノ
 • 物理的なモノも概念も定義できる
 ◦ 例えば未来も定義できる
 • 時間依らず「存在する」モノ
 • リソースはWhenとHow to 以外
 ◦ Where(どこで),Who(誰が),What(何を),Why(なぜ)

35. イベント
 ↓
 実際に発生したコト
 概念データモデル

36. イベントとは
 • 事実そのもの
 ◦ 事実は常に過去しかない
 • 定期的に繰り返される
 ◦ 複数の事実の積み重ねもありえる
 • イベントはWhenとHow to
 ◦ いつ、どんな事実が実行されたか

37. エンティティを洗い出して
 
 関連性を見出してグルーピングする作業
 概念データモデル

38. 概念スキーマ データモデリングの3層構造 外部スキーマ 内部スキーマ 論理スキーマ 物理スキーマ ユーザから見えている部分 概念データモデル 論理データモデル 物理データモデル 今日の対象 概念データモデル 論理データモデル 物理データモデル ザックマンフレームワークの データモデル分類
39. 論理データモデル
 
 
 論理データモデル
40. 論理データモデル
 ↓
 事実の保存される構造を決める
 論理データモデル
41. 情報と事実（データ）は違う
 
 
 論理データモデル
42. 情報と事実（データ）は違う
 
 
 論理データモデル 生年月日は事実 年齢はそのタイミングの情報
43. データモデリングと情報設計は別モノ
 
 分けることが大事
 論理データモデル
44. データモデリング
 
 
 論理データモデル
45. データモデリング
 ↓
 どのように事実を保存するか
 論理データモデル
46. 情報設計
 
 
 論理データモデル
47. 情報設計
 ↓
 事実を如何に加工し、利用するか
 論理データモデル
48. • エンティティの定義と属性(アトリビュート)を整理して、ライフサイ クルを分解していく
 • 成果物はER図になる
 ◦ 保存されるミドルウェアのことは考えない
 ◦ NoSQLやRDBMSかもしれない
 ◦ もちろん、両方使うかもしれない
 • できるだけ小さい粒度にしていくことが大事
 論理データモデル
49. できるだけ小さい粒度にしていく
 
 
 論理データモデル
50. できるだけ小さい粒度にしていく
 ↓
 正規化
 論理データモデル
51. ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 
 • 事実だけを保存する 
 • 重複がない
 • 不整合がない
 • nullがない
 これらを意識して設計していくとシンプルな設計に近づいてい きます。
 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
52. 概念を正規化して
 
 適切な粒度に分解していく作業
 論理データモデル
53. 概念スキーマ データモデリングの3層構造 外部スキーマ 内部スキーマ 論理スキーマ 物理スキーマ ユーザから見えている部分 概念データモデル 論理データモデル 物理データモデル 今日の対象 概念データモデル 論理データモデル 物理データモデル ザックマンフレームワークの データモデル分類
54. 物理データモデル
 
 
 物理データモデル
55. 物理データモデル
 ↓
 事実を保存する場所に合わせる
 物理データモデル
56. • DBMSの特性に合わせて論理データモデルを整える
 • RDBMSなら型やインデックスなど利用するために
 必要な条件に合わせていく
 • パフォーマンスや利用用途の都合も考慮する
 ◦ 例えばキャッシュや非正規化など
 • RDBMS以外のストレージに保存されることもある
 ◦ オブジェクトストレージやNewSQLなど
 物理データモデル
57. そして最後にINDEXの数にも注目しましょう。主キーは必ずあ りますが、外部キー制約とユニーク制約を除いたINDEXは主 に検索のために必要なINDEXです。検索のWHEREの対象の 数だけそのテーブルの責務が大きいといえ、 4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。 隠 れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り 込んでいるケースが見えてくることがあります。 
 このようにシンプルな設計を目指して考察を繰り返していくこ とが重要です。そして同じくらい重要なこととして認識すべき はイージーとシンプルは両立できる、ということです。 シンプ ルを目指し考察を繰り返すことがまさにデータモデリングであ り、変化に強い設計につながっていくのです。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
58. 実際に保存する場所に
 
 データの姿を合わせていく
 物理データモデル
59. 1. 自己紹介
 2. データモデリングの3層構造
 3. データモデリングの進め方
 4. 駐車場のデータモデリング
 5. おわりに
 あじぇんだ

60. 基本的は上から順番に
 
 概念データモデルから始める
 データモデリングの進め方

61. 概念スキーマ データモデリングの3層構造 外部スキーマ 内部スキーマ 論理スキーマ 物理スキーマ ユーザから見えている部分 概念データモデル 論理データモデル 物理データモデル 概念データモデル 論理データモデル 物理データモデル ザックマンフレームワークの データモデル分類 上から下へ アプリケーションの画面やイン ターフェース
62. 概念データモデリング
 
 
 概念データモデリング
63. エンティティを列挙して
 
 エンティティの関係を示す
 概念データモデリング
64. エンティティを列挙して
 
 エンティティの関係を示す
 概念データモデリング
65. イベント リソース 概念をリソースとイベントにわけて列挙する
 駐車場 車両 利用者 契約 入庫 出庫 予約 支払い
66. イベント リソース 駐車場 車両 利用者 契約 入庫 出庫 予約 支払い 時間に依存せず存在するモノ 住所 who(誰が) what(何が) what(何が) where(どこで) 概念をリソースとイベントにわけて列挙する

67. イベント リソース 駐車場 車両 利用者 契約 入庫 出庫 予約 支払い 発生した事実 住所 いつ、入庫した？ いつ、支払いした？ いつ、予約した？ 概念をリソースとイベントにわけて列挙する

68. エンティティを列挙して
 
 エンティティの関係を示す
 概念データモデリング
69. 利用履歴 概念データモデル図の例
 駐車場 車両 利用者 契約 入庫 出庫 予約 支払い
70. 一見、良さそうだが……
 
 本当に？
 概念データモデリング
71. 利用履歴 概念データモデル図の例
 駐車場 車両 利用者 契約 入庫 出庫 予約 支払い 月極だった場合は 契約に紐づくのでは？ 複数の車両の考慮は？ 駐車枠のリソースが必要では？ 予約の事実も利用履歴では？
72. こうやって概念を整理して
 
 必要なエンティティを抽出する
 概念データモデリング
73. 論理データモデリング
 
 
 論理データモデリング
74. エンティティを分解して
 
 適切な粒度にする
 論理データモデリング
75. 1. 属性（アトリビュート）を洗い出す
 2. データの関係を明確にする
 a. 1:1なのか1:NのかN:Nなのか
 b. 参照方向の確定（依存の親子関係） 
 3. エンティティのライフサイクルで分ける
 4. ユースケースごとにデータの流れを整理する
 5. 属性のnull、updateを無くすところまで分解する
 a. イミュータブルモデリング
 b. SELECTとINSERTのみでデータを表現する
 エンティティの分解するとき
76. 1. 属性（アトリビュート）を洗い出す
 2. データの関係を明確にする
 a. 1:1なのか1:NのかN:Nなのか
 b. 参照方向の確定（依存の親子関係） 
 3. エンティティのライフサイクルで分ける
 4. ユースケースごとにデータの流れを整理する
 5. 属性のnull、updateを無くすところまで分解する
 a. イミュータブルモデリング
 b. SELECTとINSERTのみでデータを表現する
 エンティティの分解するとき
77. 駐車場 属性を洗い出す
 • 名称 • 管理番号 • 住所 • 緯度 • 経度 • 最寄り駅 • 収容台数 • 営業時間 • 登録日時 支払い • 名称 • 基本料金 • 時間料金 • 1日最大利用料 • 昼間料金 • 夜間料金 • 支払日時 • 支払料金 • 支払者 • 消費税 • 割引額
78. 駐車場 属性を洗い出す
 • 名称 • 管理番号 • 住所 • 緯度 • 経度 • 最寄り駅 • 収容台数 • 営業時間 • 登録日時 支払い • 名称 • 基本料金 • 時間料金 • 1日最大利用料 • 昼間料金 • 夜間料金 • 支払日時 • 支払料金 • 支払者 • 消費税 • 割引額 駐車枠に依存する属性なので やっぱり駐車枠リソースは必要
79. 駐車場 属性を洗い出す
 • 名称 • 管理番号 • 住所 • 緯度 • 経度 • 最寄り駅 • 収容台数 • 営業時間 • 登録日時 支払い • 名称 • 基本料金 • 時間料金 • 1日最大利用料 • 昼間料金 • 夜間料金 • 支払日時 • 支払料金 • 支払者 • 消費税 • 割引額 支払い条件の話
80. 支払い 駐車場 属性を洗い出す
 • 名称 • 管理番号 • 住所 • 緯度 • 経度 • 最寄り駅 • 収容台数 • 営業時間 • 登録日時 • 名称 • 基本料金 • 時間料金 • 1日最大利用料 • 昼間料金 • 夜間料金 • 支払日時 • 支払料金 • 支払者 • 消費税 • 割引額 支払い内容の話
81. 支払い内容 属性を洗い出す
 支払い条件 • 名称 • 基本料金 • 時間料金 • 1日最大利用料 • 昼間料金 • 夜間料金 • 支払日時 • 支払料金 • 支払者 • 消費税 • 割引額 支払い • 名称 • 基本料金 • 時間料金 • 1日最大利用料 • 昼間料金 • 夜間料金 • 支払日時 • 支払料金 • 支払者 • 消費税 • 割引額 分解
82. 1. 属性（アトリビュート）を洗い出す
 2. データの関係を明確にする
 a. 1:1なのか1:NのかN:Nなのか
 b. 参照方向の確定（依存の親子関係） 
 3. エンティティのライフサイクルで分ける
 4. ユースケースごとにデータの流れを整理する
 5. 属性のnull、updateを無くすところまで分解する
 a. イミュータブルモデリング
 b. SELECTとINSERTのみでデータを表現する
 エンティティの分解するとき
83. 1. 属性（アトリビュート）を洗い出す
 2. データの関係を明確にする
 a. 1:1なのか1:NのかN:Nなのか
 b. 参照方向の確定（依存の親子関係） 
 3. エンティティのライフサイクルで分ける
 4. ユースケースごとにデータの流れを整理する
 5. 属性のnull、updateを無くすところまで分解する
 a. イミュータブルモデリング
 b. SELECTとINSERTのみでデータを表現する
 エンティティの分解するとき ER図で表現する
84. 関係を明確にする

85. 1. 属性（アトリビュート）を洗い出す
 2. データの関係を明確にする
 a. 1:1なのか1:NのかN:Nなのか
 b. 参照方向の確定（依存の親子関係） 
 3. エンティティのライフサイクルで分ける
 4. ユースケースごとにデータの流れを整理する
 5. 属性のnull、updateを無くすところまで分解する
 a. イミュータブルモデリング
 b. SELECTとINSERTのみでデータを表現する
 エンティティの分解するとき
86. Userテーブルの分割の場合
 
 
 Userテーブルの分割
87. create table users( id bigserial constraint users_pk primary key, name text not null, birthday date not null, email text not null, hashed_password text not null ); create unique index 　users_email_uindex　on users (email); 

88. よく見るテーブルだけど？
 
 
 Userテーブルの分割
89. ？？？「LINE認証を追加したいんだけど」
 
 
 Userテーブルの分割
90. ？？？「LINE認証を追加したいんだけど」
 ↓
 カラム追加すればえぇやろ！
 Userテーブルの分割
91. alter table users add line_id text; alter table users add line_token text; create unique index users_line_token_uindex on users (line_token); create unique index users_line_id_uindex on users (line_id);
92. これが様々な問題を生み出す…
 
 
 Userテーブルの分割
93. • メールアドレスとパスワードは必須
 ◦ LINE認証でアカウント登録してもemailとpasswordを登録 する必要がある
 ◦ ユーザの手間は減っていない（むしろ増える）
 • この問題はLINEの認証情報を別テーブルにしても同じ
 ◦ emailとpasswordをnullにする必要がある
 ◦ nullを許可したときにemailがUNIQUEでなくなる
 userテーブルにカラムを追加すると……
94. 大きく捉えて小さく作る
 
 
 Userテーブルの分割
95. passwordは認証情報のみの情報です。一方のemailは認証 情報のみに使われる情報だとするとpasswordと一緒にしてお くのも合理的かもしれません。 
 　しかし、emailは「email情報単体で変更される」こともあれ ば、たとえばGitHubのように複数のemailを持つこともあるで しょう。
 　このように、emailは認証情報以外の属性も持っています。 こうした場合、emailにpinコードを送ってWeb画面で認証する、 といったワンタイムトークンのような認証機能を実装すると passwordは不要になります。 
 　こうした運用を想定し、今回はemailとpasswordを別テーブ ルに分ける判断をしました。 
 　またこの設定であれば以下の図のように新たなログイン情 報が必要になった際も対応することができます。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
96. passwordは認証情報のみの情報です。一方のemailは認証 情報のみに使われる情報だとするとpasswordと一緒にしてお くのも合理的かもしれません。 
 　しかし、emailは「email情報単体で変更される」こともあれ ば、たとえばGitHubのように複数のemailを持つこともあるで しょう。
 　このように、emailは認証情報以外の属性も持っています。 こうした場合、emailにpinコードを送ってWeb画面で認証する、 といったワンタイムトークンのような認証機能を実装すると passwordは不要になります。 
 　こうした運用を想定し、今回はemailとpasswordを別テーブ ルに分ける判断をしました。 
 　またこの設定であれば以下の図のように新たなログイン情 報が必要になった際も対応することができます。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000 そもそもUserじゃなくてMemberな って話が記事にはあるので続きは Webで
97. 大きく捉えて小さく作る
 
 
 Userテーブルの分割
98. 1. 属性（アトリビュート）を洗い出す
 2. データの関係を明確にする
 a. 1:1なのか1:NのかN:Nなのか
 b. 参照方向の確定（依存の親子関係） 
 3. エンティティのライフサイクルで分ける
 4. ユースケースごとにデータの流れを整理する
 5. 属性のnull、updateを無くすところまで分解する
 a. イミュータブルモデリング
 b. SELECTとINSERTのみでデータを表現する
 エンティティの分解するとき
99. Small is beautiful.
 
 小さいものは美しい
 Unixの哲学
100. Small is beautiful. 小さなプログラムという発想
 1. 小さなプログラムはわかりやすい 
 2. 小さなプログラムは保守しやすい 
 3. 小さなプログラムはシステム
 リソースに優しい
 4. 小さなプログラムは他のツールと組 み合わせやすい
 
 https://amzn.to/33QPAdv
101. Make each program do one thing well.
 
 1つのプログラムには
 1つのことをうまくやらせる
 Unixの哲学
102. Make each program do one thing well. 一つのことに集中することで
 プログラムに不要な部分をなくせる。 
 不要な部分があると、
 実行速度が遅くなり、
 不必要に複雑になり、
 融通が効かない。
 
 https://amzn.to/33QPAdv
103. 1テーブル、1責務
 
 
 正規化とSimple is Beautiful
104. 1テーブル、1責務
 ↓
 Simpleを目指す
 正規化とSimple is Beautiful
105. SimpleとEasyは違う
 
 
 正規化とSimple is Beautiful
106. 正規化とSimple is Beautiful
107. 正規化とSimple is Beautiful
108. イミュータブルに設計する
 
 
 
 
 
 
 正規化とSimple is Beautiful https://scrapbox.io/kawasima/%E3%82%A4%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%96%E3%83%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%83%A2%E3%83%87%E3%83%AB [イミュータブルデータモデリング kawasima] [検索]
109. テーブルはSimpleが美しい
 
 
 正規化とSimple is Beautiful
110. テーブルはSimpleが美しい
 ↓
 EasyではなくSimpleを目指す
 正規化とSimple is Beautiful
111. 論理データモデリング中に
 
 新しい概念を見つけることがある
 論理データモデリング
112. 概念と論理を繰り返す 概念データモデル 論理データモデル 概念データモデル 論理データモデル 概念データモデル 論理データモデル スタート
113. 概念と論理を繰り返す 概念データモデル 論理データモデル 概念データモデル 論理データモデル 概念データモデル 論理データモデル 新しい概念を見つけたら改 めて整理する
114. 概念と論理を繰り返す 概念データモデル 論理データモデル 概念データモデル 論理データモデル 概念データモデル 論理データモデル 繰り返して完成を目指す
115. 論理データモデリング中は
 
 物理の制約や既存の制約にとらわれない
 倫理データモデリング 「今のテーブルが◯◯だから～」みたいなセリフがあると危険信号 本来の設計から逸脱しているかも
116. 物理データモデリング
 
 
 物理データモデリング
117. 論理データモデルを
 
 物理の世界にマッピングする
 物理データモデリング
118. 1. 論理データモデルを対象のソフトウェアに反映する
 a. RDBMSの場合にはDDL
 b. 検索のためのインデックスや制約を追加する
 2. パフォーマンスの要件のために必要な対応
 a. パーテーション
 b. キャッシュ
 3. 実際に利用するときのSQLを整理する
 a. 参照のためのSELECTや更新の処理
 b. そのときの実行計画を確認する
 c. 10年後も同じ実行計画になるか
 物理データモデリングの進め方
119. 1. 論理データモデルを対象のソフトウェアに反映する
 a. RDBMSの場合にはDDL
 b. 検索のためのインデックスや制約を追加する
 2. パフォーマンスの要件のために必要な対応
 a. パーテーション
 b. キャッシュ
 3. 実際に利用するときのSQLを整理する
 a. 参照のためのSELECTや更新の処理
 b. そのときの実行計画を確認する
 c. 10年後も同じ実行計画になるか
 物理データモデリングの進め方
120. 1. 論理データモデルを対象のソフトウェアに反映する
 a. RDBMSの場合にはDDL
 b. 検索のためのインデックスや制約を追加する
 2. パフォーマンスの要件のために必要な対応
 a. パーテーション
 b. キャッシュ …など
 3. 実際に利用するときのSQLを整理する
 a. 参照のためのSELECTや更新の処理
 b. そのときの実行計画を確認する
 c. 10年後も同じ実行計画になるか
 物理データモデリングの進め方 日本向けのサービスとグローバルで想定する最大ユーザ数は変わる 国内ならuserのpkはintで良いかも、グローバルなら bigintやuuidが必要
121. 論理データモデルを
 
 物理の世界にマッピングする
 物理データモデリング RDBMSならDDLにほぼするだけ。 ER図を作る過程で副産物として完成していることも多い
122. 物理設計のフェーズで
 
 新しい概念を見つけることもある
 物理データモデリング
123. 物理設計のフェーズで
 
 新しい概念を見つけることもある
 物理データモデリング 概念データモデリングに戻る
124. 1. 自己紹介
 2. データモデリングの3層構造
 3. データモデリングの進め方
 4. 駐車場のデータモデリング
 5. おわりに
 あじぇんだ

125. お題「駐車場」
 
 
 駐車場のデータモデリング https://gist.github.com/soudai/dd93d925380e8db27542a3f2904d1f78
126. サンプル
 
 
 駐車場のデータモデリング https://github.com/soudai/explain-analyze-training/tree/main/docker/src/design_parking Dockerの環境なども用意しているので 使い方がわからない人は質問してください
127. まずは抽象モデリング
 
 次に論理データモデリング
 駐車場のデータモデリング
128. まずは抽象モデリング
 
 次に論理データモデリング
 駐車場のデータモデリング PCを使っても紙を使っても AIを使ってもOK
129. 前半 30分 やっていきましょう！
 
 
 駐車場のデータモデリング 各々で適宜休憩は取ってください
130. 前半の解説 10分
 
 
 駐車場のデータモデリング
131. 後半戦！
 
 
 駐車場のデータモデリング
132. 前半の論理データモデルを
 
 物理データモデルに変換しましょう
 駐車場のデータモデリング
133. 速く終わった人は
 
 仕様変更のステップにチャレンジ！
 駐車場のデータモデリング
134. 後半の解説 10分
 
 
 駐車場のデータモデリング
135. 1. 自己紹介
 2. データモデリングの3層構造
 3. データモデリングの進め方
 4. 駐車場のデータモデリング
 5. おわりに
 あじぇんだ

136. AIを活用するためにも
 
 データは必要
 おわりに
137. データの寿命は
 
 アプリケーションよりも長い
 おわりに
138. おわりに
139. ビジネスに踏み込み
 
 データモデリングを考え抜きましょう
 おわりに
140. データモデリングの歴史は長い
 
 
 おわりに
141. データモデリングの歴史は長い
 ↓
 本もサイトも豊富なので活用しましょう
 おわりに
142. オススメ本
 
 
 おわりに
143. ミック本は良い • SQLの基礎本
 ミックさんの本は読みやすいし、正しい 情報だし、とにかく良い
 https://amzn.to/3xHwP8R
144. DBは本から学べる • DB設計の本
 • SQLの本も別にある
 ミックさんの本はオススメ。そしてこの本 は2012年の本だが、未だ全く色褪せる ことなく現役で使える知識で、今でもみ んなに勧める1冊。
 https://amzn.to/3CGNm0p
145. 頼む、読んでくれ！ • 俺たちのt_wada
 • 大事なことが沢山書いてある
 • 7月に第2版がでた
 まぁとりあえず読んでくれ
 https://amzn.to/43J8hiR
146. 現実に向き合った本 • 令和の名著（当社調べ）
 • PostgreSQL & MySQL 対応
 そーだい本、一度は読んで欲しい。あと 5年は現役で読める本だと思っている し、「失われた事実」とか「キャッシュ中 毒」なんかは未だによく話をする。
 あと頑張ったら新刊出すかも。
 (連載してたやつをまとめて)
 https://amzn.to/4jBL4nL
147. データモデリングはスキルなので
 
 正しく学べば身につけることができる
 おわりに
148. 
 
 
 おわりに Simple is Beautiful
 
 

149. 
 
 
 おわりに Simple is Beautiful
 ↓
 常に追求した者だけが辿り着ける

150. 今、こだわり抜いた設計が
 
 未来の自分を救うことになる
 おわりに
151. 
 
 
 おわりに
152. 昨日の自分に誇れる
 
 今日の自分になろう
 おわりに
153. ご清聴ありがとうございました
 
 
 おわりに