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

Transcript

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


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

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

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

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

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

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

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


   あじぇんだ

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


   あじぇんだ

10. 自己紹介
 曽根 壮大（40歳）
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO

    兼 COO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも


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


    あじぇんだ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    あじぇんだ

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

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

35. ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 
 • 事実だけを保存する 
 • 重複がない


    • 不整合がない
 • nullがない
 これらを意識して設計していくとシンプルな設計に近づいてい きます。
 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000

36. そして最後にINDEXの数にも注目しましょう。主キーは必ずあ りますが、外部キー制約とユニーク制約を除いたINDEXは主 に検索のために必要なINDEXです。検索のWHEREの対象の 数だけそのテーブルの責務が大きいといえ、 4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。 隠 れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り 込んでいるケースが見えてくることがあります。 


    このようにシンプルな設計を目指して考察を繰り返していくこ とが重要です。そして同じくらい重要なこととして認識すべき はイージーとシンプルは両立できる、ということです。 シンプ ルを目指し考察を繰り返すことがまさにデータモデリングであ り、変化に強い設計につながっていくのです。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000

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

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

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

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

41. Small is beautiful. 小さなプログラムという発想 1. 小さなプログラムはわかりやすい 2. 小さなプログラムは保守しやすい 3. 小さなプログラムはシステム

    リソースに優しい 4. 小さなプログラムは他のツールと組 み合わせやすい https://amzn.to/33QPAdv

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


    Unixの哲学

43. Make each program do one thing well. 一つのことに集中することで プログラムに不要な部分をなくせる。 不要な部分があると、

    実行速度が遅くなり、 不必要に複雑になり、 融通が効かない。 https://amzn.to/33QPAdv

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

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

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

47. 正規化とSimple is Beautiful

48. 正規化とSimple is Beautiful

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

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

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


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

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

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

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

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

57. • メールアドレスとパスワードは必須
 ◦ LINE認証でアカウント登録してもemailとpasswordを登録 する必要がある
 ◦ ユーザの手間は減っていない（むしろ増える）
 • この問題はLINEの認証情報を別テーブルにしても同じ
 ◦

    emailとpasswordをnullにする必要がある
 ◦ nullを許可したときにemailがUNIQUEでなくなる
 userテーブルにカラムを追加すると……

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

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

60. passwordは認証情報のみの情報です。一方のemailは認証 情報のみに使われる情報だとするとpasswordと一緒にしてお くのも合理的かもしれません。 
 　しかし、emailは「email情報単体で変更される」こともあれ ば、たとえばGitHubのように複数のemailを持つこともあるで しょう。
 　このように、emailは認証情報以外の属性も持っています。 こうした場合、emailにpinコードを送ってWeb画面で認証する、 といったワンタイムトークンのような認証機能を実装すると

    passwordは不要になります。 
 　こうした運用を想定し、今回はemailとpasswordを別テーブ ルに分ける判断をしました。 
 　またこの設定であれば以下の図のように新たなログイン情 報が必要になった際も対応することができます。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000

61. 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で

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

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

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

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

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

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


    あじぇんだ

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

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

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

71. おわりに

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

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

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

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

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

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

78. 
 
 
 おわりに

79. 昨日の自分に誇れる
 
 今日の自分になろう
 おわりに

80. ご清聴ありがとうございました
 
 
 おわりに