DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所

by soudai sone

Slide 1

Slide 1 text

DB TECH SHOWCASE 2025 DBのスキルで生き残る技術  - AI時代におけるテーブル設計の勘所 

Slide 2

Slide 2 text

今日のお話すること      What is it?

Slide 3

Slide 3 text

AIに代替されないスキル    その勘所とテーブル設計のコツ    What is it?

Slide 4

Slide 4 text

テーブル設計もAIに代替される？      What is it?

Slide 5

Slide 5 text

テーブル設計もAIに代替される？  ↓  そんなことはありません  What is it?

Slide 6

Slide 6 text

データベースの寿命は    アプリケーションよりも長い  What is it?

Slide 7

Slide 7 text

だからこそ今、    データベースが熱い！！  What is it?

Slide 8

Slide 8 text

1. 自己紹介  2. AIは未来を想像してくれない  3. 正規化とSimple is beautiful  4. おわりに  あじぇんだ

Slide 9

Slide 9 text

1. 自己紹介  2. AIは未来を想像してくれない  3. 正規化とSimple is beautiful  4. おわりに  あじぇんだ

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

1. 自己紹介  2. AIは未来を想像してくれない  3. 正規化とSimple is beautiful  4. おわりに  あじぇんだ

Slide 12

Slide 12 text

AIは未来を想像してくれない      AIは未来を想像してくれない

Slide 13

Slide 13 text

AIは未来を想像してくれない  ↓  ドメインを理解しているわけではない  AIは未来を想像してくれない

Slide 14

Slide 14 text

AIはダブルループではなく    シングルループ学習  AIとの設計の歩み方

Slide 15

Slide 15 text

AIは未来を想像してくれない前提行動結果シングルループは実行結果に元に行動を変える

Slide 16

Slide 16 text

AIは未来を想像してくれない前提行動結果ダブルループは結果から、前提を変えて根本から変更する

Slide 17

Slide 17 text

LLMは単語に対して    ありそうな文言を回答する  AIは未来を想像してくれない

Slide 18

Slide 18 text

LLMは単語に対して    ありそうな文言を回答する  AIは未来を想像してくれないそれっぽいテーブルは作ってくれるが、背景を知らないので良くある駄目なパターンを回答しやすい

Slide 19

Slide 19 text

LLMは単語に対して    ありそうな文言を回答する  AIは未来を想像してくれないそれっぽいテーブルは作ってくれるが、背景を知らないので良くある駄目なパターンを回答しやすい世の中のOSSの設計はEasyでDirtyな設計が多い敢えてそういう戦略を取っている OSSもある WordPressやRedmineのEAV(Entity-Attribute-Value)とか

Slide 20

Slide 20 text

AIによって    高速にデータベースが肥大化する  AIは未来を想像してくれない

Slide 21

Slide 21 text

AIは未来を想像してくれない https://martinfowler.com/articles/is-quality-worth-cost.html 生産性の交差点がより手前になった

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

AIは未来を想像してくれない https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition

Slide 28

Slide 28 text

前提を見直すことは    人間の仕事（しばらくは）  AIは未来を想像してくれない

Slide 29

Slide 29 text

前提を見直すことは    人間の仕事（しばらくは）  AIは未来を想像してくれない要求は物理の世界にあって、要求の変更は人間にしかできないから

Slide 30

Slide 30 text

データベースの寿命は    アプリケーションよりも長い  大切なことなのでもう一回

Slide 31

Slide 31 text

大きく捉えて小さく作る  ↓  つまり正規化  AIは未来を想像してくれない

Slide 32

Slide 32 text

1. 自己紹介  2. AIは未来を想像してくれない  3. 正規化とSimple is beautiful  4. おわりに  あじぇんだ

Slide 33

Slide 33 text

データベースの道はすべて    正規化に通ずる  正規化とSimple is Beautiful

Slide 34

Slide 34 text

正規化のコツ      正規化とSimple is Beautiful

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

情報と事実（データ）は違う      正規化とSimple is Beautiful

Slide 38

Slide 38 text

情報と事実（データ）は違う      正規化とSimple is Beautiful 生年月日は事実年齢はそのタイミングの情報

Slide 39

Slide 39 text

正規化はUnixの哲学にも通ずる      正規化とSimple is Beautiful

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

正規化とSimple is Beautiful

Slide 48

Slide 48 text

正規化とSimple is Beautiful

Slide 49

Slide 49 text

SimpleとEasyは両立するし    質とスピードも両立する  正規化とSimple is Beautiful

Slide 50

Slide 50 text

Userテーブルの分割の場合      正規化とSimple is Beautiful

Slide 51

Slide 51 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 52

Slide 52 text

よく見るテーブルだけど？      正規化とSimple is Beautiful

Slide 53

Slide 53 text

？？？「LINE認証を追加したいんだけど」      正規化とSimple is Beautiful

Slide 54

Slide 54 text

？？？「LINE認証を追加したいんだけど」  ↓  カラム追加すればえぇやろ！  正規化とSimple is Beautiful

Slide 55

Slide 55 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 56

Slide 56 text

これが様々な問題を生み出す…      正規化とSimple is Beautiful

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

機能開発のためのテーブル変更が    ビジネス側に不要な制約を生み出す  正規化とSimple is Beautiful

Slide 59

Slide 59 text

大きく捉えて小さく作る      正規化とSimple is Beautiful

Slide 60

Slide 60 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 61

Slide 61 text

Slide 62

Slide 62 text

テーブルがSimpleだと    変化に強くなる  正規化とSimple is Beautiful

Slide 63

Slide 63 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 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

正解を目指すのではなく    変化に強い構造が大事  正規化とSimple is Beautiful

Slide 67

Slide 67 text

1. 自己紹介  2. AIは未来を想像してくれない  3. 正規化とSimple is beautiful  4. おわりに  あじぇんだ

Slide 68

Slide 68 text

データモデリングのスキルは    寿命が長いし、複利で効く能力  おわりに

Slide 69

Slide 69 text

しばらくはAIに代替できる仕事では無い      おわりに

Slide 70

Slide 70 text

しばらくはAIに代替できる仕事では無い  ↓  代替するのではなく、労力をサポートさせる  おわりに

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

引用元 : ワールドトリガー 28巻

Slide 76

Slide 76 text

“大事なのはできるという経験を得ること”    – 宇宙兄弟 145話   おわりに

Slide 77

Slide 77 text

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