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

by soudai sone

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

タイムテーブル      What is it? 

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

今日のゴール      What is it? 

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

AIは未来を想像してくれない初期設計

Slide 8

Slide 8 text

AIは未来を想像してくれない初期設計仕様追加

Slide 9

Slide 9 text

AIは未来を想像してくれない初期設計仕様追加将来を見据えたテーブルの修正をしないと次の仕様追加に耐えられない

Slide 10

Slide 10 text

AIは未来を想像してくれない初期設計仕様追加仕様追加

Slide 11

Slide 11 text

AIは未来を想像してくれない初期設計仕様追加仕様追加マジカルな設計によって開発ができなくなる

Slide 12

Slide 12 text

データモデリングがなぜ重要か  ↓  AIは未来を想像してくれない  What is it? 

Slide 13

Slide 13 text

データモデリングがなぜ重要か  ↓  AIは未来を想像してくれない  What is it?  将来の設計を考慮して提案してくれるわけではない

Slide 14

Slide 14 text

だからこそ、データモデリングが大事！      What is it? 

Slide 15

Slide 15 text

“大事なのはできるという経験を得ること”    – 宇宙兄弟 145話   What is it?

Slide 16

Slide 16 text

できる！を体験して    データモデリングを理解していきましょう  What is it? 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

データモデリングの3層構造      データモデリングの3層構造

Slide 23

Slide 23 text

データモデリングの3層構造  ↓  データモデルと3層スキーマ  データモデリングの3層構造

Slide 24

Slide 24 text

データモデリングの3層構造外部スキーマ概念スキーマ内部スキーマ論理スキーマ物理スキーマユーザから見えている部分概念データモデル論理データモデル物理データモデル ANSI/SPARC 3層スキーマアプリケーションの画面やインターフェース

Slide 25

Slide 25 text

概念スキーマデータモデリングの3層構造外部スキーマ内部スキーマ論理スキーマ物理スキーマユーザから見えている部分概念データモデル論理データモデル物理データモデル今日の対象概念データモデル論理データモデル物理データモデルザックマンフレームワークのデータモデル分類

Slide 26

Slide 26 text

Slide 27

Slide 27 text

概念データモデル      概念データモデル 

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

論理データモデル      論理データモデル

Slide 40

Slide 40 text

論理データモデル  ↓  事実の保存される構造を決める  論理データモデル

Slide 41

Slide 41 text

情報と事実（データ）は違う      論理データモデル

Slide 42

Slide 42 text

情報と事実（データ）は違う      論理データモデル生年月日は事実年齢はそのタイミングの情報

Slide 43

Slide 43 text

データモデリングと情報設計は別モノ    分けることが大事  論理データモデル

Slide 44

Slide 44 text

データモデリング      論理データモデル

Slide 45

Slide 45 text

データモデリング  ↓  どのように事実を保存するか  論理データモデル

Slide 46

Slide 46 text

情報設計      論理データモデル

Slide 47

Slide 47 text

情報設計  ↓  事実を如何に加工し、利用するか  論理データモデル

Slide 48

Slide 48 text

● エンティティの定義と属性(アトリビュート)を整理して、ライフサイクルを分解していく  ● 成果物はER図になる  ○ 保存されるミドルウェアのことは考えない  ○ NoSQLやRDBMSかもしれない  ○ もちろん、両方使うかもしれない  ● できるだけ小さい粒度にしていくことが大事  論理データモデル

Slide 49

Slide 49 text

できるだけ小さい粒度にしていく      論理データモデル

Slide 50

Slide 50 text

できるだけ小さい粒度にしていく  ↓  正規化  論理データモデル

Slide 51

Slide 51 text

ここまでシンプルな実装を目指しましょうと強調してきましたが、「シンプルな実装」とはなんでしょうか。RDBMSを使う上でシンプルな実装のヒントは正規化です。正規化のコツは次のように表現できます。   ● 事実だけを保存する   ● 重複がない  ● 不整合がない  ● nullがない  これらを意識して設計していくとシンプルな設計に近づいていきます。  また正規化を行う際はここまで説明したとおり、種別と状態を考えることも重要です。ライフサイクルが違うデータは往々にして状態や種別が異なります。場合によってはnullになるようなカラムやUPDATEが必要なレコードは状態を持っている可能性があります。こうしたテーブルが見つかった場合はより深く考察する必要があります。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 52

Slide 52 text

概念を正規化して    適切な粒度に分解していく作業  論理データモデル

Slide 53

Slide 53 text

Slide 54

Slide 54 text

物理データモデル      物理データモデル

Slide 55

Slide 55 text

物理データモデル  ↓  事実を保存する場所に合わせる  物理データモデル

Slide 56

Slide 56 text

● DBMSの特性に合わせて論理データモデルを整える  ● RDBMSなら型やインデックスなど利用するために  必要な条件に合わせていく  ● パフォーマンスや利用用途の都合も考慮する  ○ 例えばキャッシュや非正規化など  ● RDBMS以外のストレージに保存されることもある  ○ オブジェクトストレージやNewSQLなど  物理データモデル

Slide 57

Slide 57 text

そして最後にINDEXの数にも注目しましょう。主キーは必ずありますが、外部キー制約とユニーク制約を除いたINDEXは主に検索のために必要なINDEXです。検索のWHEREの対象の数だけそのテーブルの責務が大きいといえ、 4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。隠れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り込んでいるケースが見えてくることがあります。   このようにシンプルな設計を目指して考察を繰り返していくことが重要です。そして同じくらい重要なこととして認識すべきはイージーとシンプルは両立できる、ということです。シンプルを目指し考察を繰り返すことがまさにデータモデリングであり、変化に強い設計につながっていくのです。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 58

Slide 58 text

実際に保存する場所に    データの姿を合わせていく  物理データモデル

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

概念スキーマデータモデリングの3層構造外部スキーマ内部スキーマ論理スキーマ物理スキーマユーザから見えている部分概念データモデル論理データモデル物理データモデル概念データモデル論理データモデル物理データモデルザックマンフレームワークのデータモデル分類上から下へアプリケーションの画面やインターフェース

Slide 62

Slide 62 text

概念データモデリング      概念データモデリング

Slide 63

Slide 63 text

エンティティを列挙して    エンティティの関係を示す  概念データモデリング

Slide 64

Slide 64 text

エンティティを列挙して    エンティティの関係を示す  概念データモデリング

Slide 65

Slide 65 text

イベントリソース概念をリソースとイベントにわけて列挙する  駐車場車両利用者契約入庫出庫予約支払い

Slide 66

Slide 66 text

イベントリソース駐車場車両利用者契約入庫出庫予約支払い時間に依存せず存在するモノ住所 who(誰が) what(何が) what(何が) where(どこで) 概念をリソースとイベントにわけて列挙する 

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

エンティティを列挙して    エンティティの関係を示す  概念データモデリング

Slide 69

Slide 69 text

利用履歴概念データモデル図の例  駐車場車両利用者契約入庫出庫予約支払い

Slide 70

Slide 70 text

一見、良さそうだが……    本当に？  概念データモデリング

Slide 71

Slide 71 text

利用履歴概念データモデル図の例  駐車場車両利用者契約入庫出庫予約支払い月極だった場合は契約に紐づくのでは？複数の車両の考慮は？駐車枠のリソースが必要では？予約の事実も利用履歴では？

Slide 72

Slide 72 text

こうやって概念を整理して    必要なエンティティを抽出する  概念データモデリング

Slide 73

Slide 73 text

論理データモデリング      論理データモデリング

Slide 74

Slide 74 text

エンティティを分解して    適切な粒度にする  論理データモデリング

Slide 75

Slide 75 text

1. 属性（アトリビュート）を洗い出す  2. データの関係を明確にする  a. 1:1なのか1:NのかN:Nなのか  b. 参照方向の確定（依存の親子関係）   3. エンティティのライフサイクルで分ける  4. ユースケースごとにデータの流れを整理する  5. 属性のnull、updateを無くすところまで分解する  a. イミュータブルモデリング  b. SELECTとINSERTのみでデータを表現する  エンティティの分解するとき

Slide 76

Slide 76 text

Slide 77

Slide 77 text

駐車場属性を洗い出す  ● 名称 ● 管理番号 ● 住所 ● 緯度 ● 経度 ● 最寄り駅 ● 収容台数 ● 営業時間 ● 登録日時支払い ● 名称 ● 基本料金 ● 時間料金 ● 1日最大利用料 ● 昼間料金 ● 夜間料金 ● 支払日時 ● 支払料金 ● 支払者 ● 消費税 ● 割引額

Slide 78

Slide 78 text

駐車場属性を洗い出す  ● 名称 ● 管理番号 ● 住所 ● 緯度 ● 経度 ● 最寄り駅 ● 収容台数 ● 営業時間 ● 登録日時支払い ● 名称 ● 基本料金 ● 時間料金 ● 1日最大利用料 ● 昼間料金 ● 夜間料金 ● 支払日時 ● 支払料金 ● 支払者 ● 消費税 ● 割引額駐車枠に依存する属性なのでやっぱり駐車枠リソースは必要

Slide 79

Slide 79 text

駐車場属性を洗い出す  ● 名称 ● 管理番号 ● 住所 ● 緯度 ● 経度 ● 最寄り駅 ● 収容台数 ● 営業時間 ● 登録日時支払い ● 名称 ● 基本料金 ● 時間料金 ● 1日最大利用料 ● 昼間料金 ● 夜間料金 ● 支払日時 ● 支払料金 ● 支払者 ● 消費税 ● 割引額支払い条件の話

Slide 80

Slide 80 text

支払い駐車場属性を洗い出す  ● 名称 ● 管理番号 ● 住所 ● 緯度 ● 経度 ● 最寄り駅 ● 収容台数 ● 営業時間 ● 登録日時 ● 名称 ● 基本料金 ● 時間料金 ● 1日最大利用料 ● 昼間料金 ● 夜間料金 ● 支払日時 ● 支払料金 ● 支払者 ● 消費税 ● 割引額支払い内容の話

Slide 81

Slide 81 text

支払い内容属性を洗い出す  支払い条件 ● 名称 ● 基本料金 ● 時間料金 ● 1日最大利用料 ● 昼間料金 ● 夜間料金 ● 支払日時 ● 支払料金 ● 支払者 ● 消費税 ● 割引額支払い ● 名称 ● 基本料金 ● 時間料金 ● 1日最大利用料 ● 昼間料金 ● 夜間料金 ● 支払日時 ● 支払料金 ● 支払者 ● 消費税 ● 割引額分解

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

関係を明確にする 

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Userテーブルの分割の場合      Userテーブルの分割

Slide 87

Slide 87 text

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);  

Slide 88

Slide 88 text

よく見るテーブルだけど？      Userテーブルの分割

Slide 89

Slide 89 text

？？？「LINE認証を追加したいんだけど」      Userテーブルの分割

Slide 90

Slide 90 text

？？？「LINE認証を追加したいんだけど」  ↓  カラム追加すればえぇやろ！  Userテーブルの分割

Slide 91

Slide 91 text

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);

Slide 92

Slide 92 text

これが様々な問題を生み出す…      Userテーブルの分割

Slide 93

Slide 93 text

● メールアドレスとパスワードは必須  ○ LINE認証でアカウント登録してもemailとpasswordを登録する必要がある  ○ ユーザの手間は減っていない（むしろ増える）  ● この問題はLINEの認証情報を別テーブルにしても同じ  ○ emailとpasswordをnullにする必要がある  ○ nullを許可したときにemailがUNIQUEでなくなる  userテーブルにカラムを追加すると……

Slide 94

Slide 94 text

大きく捉えて小さく作る      Userテーブルの分割

Slide 95

Slide 95 text

passwordは認証情報のみの情報です。一方のemailは認証情報のみに使われる情報だとするとpasswordと一緒にしておくのも合理的かもしれません。   　しかし、emailは「email情報単体で変更される」こともあれば、たとえばGitHubのように複数のemailを持つこともあるでしょう。  　このように、emailは認証情報以外の属性も持っています。こうした場合、emailにpinコードを送ってWeb画面で認証する、といったワンタイムトークンのような認証機能を実装すると passwordは不要になります。   　こうした運用を想定し、今回はemailとpasswordを別テーブルに分ける判断をしました。   　またこの設定であれば以下の図のように新たなログイン情報が必要になった際も対応することができます。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 96

Slide 96 text

Slide 97

Slide 97 text

大きく捉えて小さく作る      Userテーブルの分割

Slide 98

Slide 98 text

Slide 99

Slide 99 text

Small is beautiful.    小さいものは美しい  Unixの哲学

Slide 100

Slide 100 text

Small is beautiful. 小さなプログラムという発想  1. 小さなプログラムはわかりやすい   2. 小さなプログラムは保守しやすい   3. 小さなプログラムはシステム  リソースに優しい  4. 小さなプログラムは他のツールと組み合わせやすい    https://amzn.to/33QPAdv

Slide 101

Slide 101 text

Make each program do one thing well.    1つのプログラムには  1つのことをうまくやらせる  Unixの哲学

Slide 102

Slide 102 text

Make each program do one thing well. 一つのことに集中することで  プログラムに不要な部分をなくせる。   不要な部分があると、  実行速度が遅くなり、  不必要に複雑になり、  融通が効かない。    https://amzn.to/33QPAdv

Slide 103

Slide 103 text

1テーブル、1責務      正規化とSimple is Beautiful

Slide 104

Slide 104 text

1テーブル、1責務  ↓  Simpleを目指す  正規化とSimple is Beautiful

Slide 105

Slide 105 text

SimpleとEasyは違う      正規化とSimple is Beautiful

Slide 106

Slide 106 text

正規化とSimple is Beautiful

Slide 107

Slide 107 text

正規化とSimple is Beautiful

Slide 108

Slide 108 text

イミュータブルに設計する              正規化と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] [検索]

Slide 109

Slide 109 text

テーブルはSimpleが美しい      正規化とSimple is Beautiful

Slide 110

Slide 110 text

テーブルはSimpleが美しい  ↓  EasyではなくSimpleを目指す  正規化とSimple is Beautiful

Slide 111

Slide 111 text

論理データモデリング中に    新しい概念を見つけることがある  論理データモデリング

Slide 112

Slide 112 text

概念と論理を繰り返す概念データモデル論理データモデル概念データモデル論理データモデル概念データモデル論理データモデルスタート

Slide 113

Slide 113 text

概念と論理を繰り返す概念データモデル論理データモデル概念データモデル論理データモデル概念データモデル論理データモデル新しい概念を見つけたら改めて整理する

Slide 114

Slide 114 text

概念と論理を繰り返す概念データモデル論理データモデル概念データモデル論理データモデル概念データモデル論理データモデル繰り返して完成を目指す

Slide 115

Slide 115 text

論理データモデリング中は    物理の制約や既存の制約にとらわれない  倫理データモデリング「今のテーブルが◯◯だから～」みたいなセリフがあると危険信号本来の設計から逸脱しているかも

Slide 116

Slide 116 text

物理データモデリング      物理データモデリング

Slide 117

Slide 117 text

論理データモデルを    物理の世界にマッピングする  物理データモデリング

Slide 118

Slide 118 text

1. 論理データモデルを対象のソフトウェアに反映する  a. RDBMSの場合にはDDL  b. 検索のためのインデックスや制約を追加する  2. パフォーマンスの要件のために必要な対応  a. パーテーション  b. キャッシュ  3. 実際に利用するときのSQLを整理する  a. 参照のためのSELECTや更新の処理  b. そのときの実行計画を確認する  c. 10年後も同じ実行計画になるか  物理データモデリングの進め方

Slide 119

Slide 119 text

Slide 120

Slide 120 text

1. 論理データモデルを対象のソフトウェアに反映する  a. RDBMSの場合にはDDL  b. 検索のためのインデックスや制約を追加する  2. パフォーマンスの要件のために必要な対応  a. パーテーション  b. キャッシュ …など  3. 実際に利用するときのSQLを整理する  a. 参照のためのSELECTや更新の処理  b. そのときの実行計画を確認する  c. 10年後も同じ実行計画になるか  物理データモデリングの進め方日本向けのサービスとグローバルで想定する最大ユーザ数は変わる国内ならuserのpkはintで良いかも、グローバルなら bigintやuuidが必要

Slide 121

Slide 121 text

論理データモデルを    物理の世界にマッピングする  物理データモデリング RDBMSならDDLにほぼするだけ。 ER図を作る過程で副産物として完成していることも多い

Slide 122

Slide 122 text

物理設計のフェーズで    新しい概念を見つけることもある  物理データモデリング

Slide 123

Slide 123 text

物理設計のフェーズで    新しい概念を見つけることもある  物理データモデリング概念データモデリングに戻る

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

お題「駐車場」      駐車場のデータモデリング https://gist.github.com/soudai/dd93d925380e8db27542a3f2904d1f78

Slide 126

Slide 126 text

サンプル      駐車場のデータモデリング https://github.com/soudai/explain-analyze-training/tree/main/docker/src/design_parking Dockerの環境なども用意しているので使い方がわからない人は質問してください

Slide 127

Slide 127 text

まずは抽象モデリング    次に論理データモデリング  駐車場のデータモデリング

Slide 128

Slide 128 text

まずは抽象モデリング    次に論理データモデリング  駐車場のデータモデリング PCを使っても紙を使っても AIを使ってもOK

Slide 129

Slide 129 text

前半 30分やっていきましょう！      駐車場のデータモデリング各々で適宜休憩は取ってください

Slide 130

Slide 130 text

前半の解説 10分      駐車場のデータモデリング

Slide 131

Slide 131 text

後半戦！      駐車場のデータモデリング

Slide 132

Slide 132 text

前半の論理データモデルを    物理データモデルに変換しましょう  駐車場のデータモデリング

Slide 133

Slide 133 text

速く終わった人は    仕様変更のステップにチャレンジ！  駐車場のデータモデリング

Slide 134

Slide 134 text

後半の解説 10分      駐車場のデータモデリング

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

AIを活用するためにも    データは必要  おわりに

Slide 137

Slide 137 text

データの寿命は    アプリケーションよりも長い  おわりに

Slide 138

Slide 138 text

おわりに

Slide 139

Slide 139 text

ビジネスに踏み込み    データモデリングを考え抜きましょう  おわりに

Slide 140

Slide 140 text

データモデリングの歴史は長い      おわりに

Slide 141

Slide 141 text

データモデリングの歴史は長い  ↓  本もサイトも豊富なので活用しましょう  おわりに

Slide 142

Slide 142 text

オススメ本      おわりに

Slide 143

Slide 143 text

ミック本は良い ● SQLの基礎本  ミックさんの本は読みやすいし、正しい情報だし、とにかく良い  https://amzn.to/3xHwP8R

Slide 144

Slide 144 text

DBは本から学べる ● DB設計の本  ● SQLの本も別にある  ミックさんの本はオススメ。そしてこの本は2012年の本だが、未だ全く色褪せることなく現役で使える知識で、今でもみんなに勧める1冊。  https://amzn.to/3CGNm0p

Slide 145

Slide 145 text

頼む、読んでくれ！ ● 俺たちのt_wada  ● 大事なことが沢山書いてある  ● 7月に第2版がでた  まぁとりあえず読んでくれ  https://amzn.to/43J8hiR

Slide 146

Slide 146 text

現実に向き合った本 ● 令和の名著（当社調べ）  ● PostgreSQL & MySQL 対応  そーだい本、一度は読んで欲しい。あと 5年は現役で読める本だと思っているし、「失われた事実」とか「キャッシュ中毒」なんかは未だによく話をする。  あと頑張ったら新刊出すかも。  (連載してたやつをまとめて)  https://amzn.to/4jBL4nL

Slide 147

Slide 147 text

データモデリングはスキルなので    正しく学べば身につけることができる  おわりに

Slide 148

Slide 148 text

      おわりに Simple is Beautiful     

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

今、こだわり抜いた設計が    未来の自分を救うことになる  おわりに