ブログ記事
「データ設計はセンスで決まる」を疑う――佐藤正美『事業分析・データ設計のためのモデル作成技術入門』のTM理論
同じ要件書から出発したはずなのに、なぜ設計者によって違うテーブル構造ができあがるのか。
佐藤正美著『事業分析・データ設計のためのモデル作成技術入門』（技術評論社、2022年）は、この問いに「センスの差」以外の答えを出そうとする一冊だ。著者が長年かけて再体系化した「TM（Theory of Models）」という方法論は、集合論や関数論といった数理論理学を土台に、同一の事実からは誰が設計しても一意の構造に収束する手順を定義する。
1. 「モノ」を「Event」と「Resource」に分けるだけでいい
TM理論が最初に要求するのは、業務上の「モノ」を個体指定子（コードやID）で洗い出し、それを2種類にだけ分類することだ。時間軸に沿って発生する「Event（できごと）」と、それ以外の静的な「Resource（管理対象）」。この二分法は単純に見えるが、設計者の好みが入り込む余地を最小化する狙いがある。
従来のRDB設計では「エンティティを見つける」作業自体に経験と勘が必要とされてきた。TMはこの発見プロセスを、個体指定子の有無という機械的な判定に置き換える。結果として、定義された「関係の文法」に当てはめていくだけで、誰が組んでもほぼ同じモデル図に近づいていく。
2. 構文論が先、意味論は後――解釈の迷走を防ぐ順序
多くの設計議論は「このテーブルは業務的に何を意味するか」という意味論から始まり、そこで迷走する。TMはこの順序をひっくり返す。まずテーブル間の関係や演算が論理規則として無矛盾に成り立っているか（構文論・L-真）を先に確定させ、その後にそれが現実のビジネスと一致しているか（意味論・F-真）を検証する。
骨組みが先、解釈は後。この順序を守るだけで、「この項目はこういう意味もあるかもしれない」という議論が設計の骨格を揺らす事態を防げる。
3. 「対照表」という切り出し方――仕様変更にテーブル定義を巻き込まない
「特定の顧客への販売を制限する」のような新しい業務ルールが降ってきたとき、既存の顧客テーブルや商品テーブルにフラグやカラムを足して対応しようとすると、テーブルは急速にスパゲッティ化する。TMはこうしたルールをリソースの属性として持たせず、「対照表」という独立した関連テーブルに切り出す。
ルールがさらに複雑化しても、変更するのは対照表であって既存テーブルの定義ではない。この切り分けが、変化に対する耐性の正体だ。
4. 更新・削除を捨てる――2値論理とイミュータブルの世界
ステータスフラグを都度UPDATEで書き換える設計は、いつ・どう変わったかの履歴を追跡不能にする。TMは時間軸を持つEventの書き換えを原則禁止し、新しい事実を常に新しい行としてCreateすることを推奨する。あわせて、RDBで多用される「null」は値ではなく状態にすぎないとして排除し、3値論理ではなく2値論理（真・偽）だけでモデルを組む。
flowchart LR
subgraph 一般的な設計
A["ステータスフラグ\nUPDATE で上書き"] --> B["履歴が消える\n監査が困難"]
end
subgraph TM理論
C["Event\n新しい事実を都度 Create"] --> D["全履歴が残る\n2値論理で矛盾なし"]
end
style A fill:#fce8e8,stroke:#e53935
style B fill:#fce8e8,stroke:#e53935
style C fill:#e8f8e8,stroke:#4caf50
style D fill:#e8f8e8,stroke:#4caf50
この本が解決できる具体的な状況
設計者ごとにテーブル構造がばらつき、機能追加や法改正のたびに既存スキーマが破綻して場当たり的なカラム追加を繰り返している――この状態は、個々のミスというより「設計を客観的に検証する手順がない」ことが原因であることが多い。本書のEvent/Resourceの二分法と「対照表」による分離は、この属人化に対する具体的な対抗策になる。また、更新のたびに状態が上書きされ、いつ何が変わったかを追えないまま監査対応やデバッグに時間を溶かしている会計・決済系のシステムにも、イミュータブルな設計思想は直接効く。
こんな人に向いている
- メンバーごとの設計スキルのばらつきに限界を感じ、チーム全体の設計プロセスを論理的なルールで統一したいテックリードや開発責任者
- 要件定義と実装の間でデータの解釈がずれ続け、運用開始後に不整合や複雑な状態管理フラグのバグに直面しているシステムアナリスト
- 複雑に絡み合うステータス管理に悩み、更新を排して事実だけを記録するイミュータブルなデータパイプラインを設計したいサーバーサイドエンジニア
逆に向いていないケース
- すぐに使える具体的なパターン集が欲しい人: 本書は抽象度の高い方法論の書であり、業務別の実装例が豊富なわけではない。業界別の具体パターンが欲しいなら『システム開発・刷新のためのデータモデル大全』のような書籍のほうが手っ取り早い
- チームに標準的なERD/UMLでの合意形成をこれから進めたい人: TMの記法や用語は業界標準の表記法と一線を画すため、そのまま持ち込むとチーム内の合意形成コストがかえって膨らむ
- 正規化・主キー・トランザクションといった基礎をまだ固めていない人: 本書は上級者向けで、DB設計の基本用語を前提に進む
知っておきたい限界
本書への批判として押さえておきたい点が三つある。
一つは学術的な記述の敷居の高さだ。デイヴィドソンのT文やカルナップの哲学、数学基礎論の専門用語が随所に登場し、一般的なエンジニアにとっては理論の壁が高く、途中で挫折しやすい。
二つ目は、業界標準との乖離だ。ERDやUMLといったデファクトスタンダードとは異なる「T字書式」やTM独自の規則を学ぶ必要があるため、チーム開発に導入・普及させるには相応の学習コストと合意形成の手間がかかる。
三つ目は、主観排除の徹底度そのものへの疑問だ。「誰がやっても同じモデルになる」とされるが、実際にある関係が現実世界で充足されるかどうかを判定する局面では高度なドメイン知識（業務理解）が要求され、属人性を完全に排除することは難しい。関連するアトリビュートリストなど補助資料のメンテナンスコストが高くなるという指摘も存在する。
この三点を踏まえた上で、本書は「万能の自動設計装置」ではなく、設計議論を客観的な土台に載せるための思考の道具として使うのが現実的だ。
同じテーマの本との比較
DB設計の基本手順（論理設計と正規化、物理設計への変換）をまだ固めていないなら、先に『達人に学ぶDB設計徹底指南書』で正規化とトレードオフの判断基準を身につけておくと、本書のEvent/Resource分類がなぜ有効なのかをより深く理解できる。
同じく数学的な基盤からRDBを説き起こす書籍としては『理論から学ぶデータベース実践入門』がある。ただし守備範囲が異なり、あちらは集合論・述語論理からリレーショナルモデルとnullの3値論理問題を導出するのに対し、本書は業務分析からエンティティを抽出する手順そのものを扱う。
『システム開発・刷新のためのデータモデル大全』とは並行して参照する関係にある。本書が「考え方」を扱うのに対し、あちらは「その成果物としての具体的なモデル例」を業務領域別に多数示す。抽象的な技法と具体的なテーブル構成例を行き来すると、設計の引き出しが立体的になる。
まとめ
「データ設計はセンス」という前提を疑うところから、本書は始まる。TM理論のすべてをチームに導入できなくても、Event/Resourceの分類、対照表による切り出し、更新を避けて事実を追記するという発想は、既存の設計レビューに組み込める部分から使える。
筆者の体験から
テックリードとしてメンバーが提出してくるスキーマ設計をレビューする立場になってから、同じ要件でも人によってテーブルの切り方がまるで違うことに悩まされる時期があった。「なんとなくこの形の方が自然」という説明しか返ってこないレビューが続き、判断基準を言語化したくて本書に手を伸ばした。
T字書式や数学基礎論の用語をそのままチームに持ち込むのは早々に諦めた。カルナップの哲学の話をレビューの場に持ち出しても誰もついてこられない。その代わり、「このカラムは事実の記録（Event）か、それとも状態を持つ管理対象（Resource）か」という問いと、「新しいビジネスルールを既存テーブルのフラグで表現していないか、対照表として切り出せないか」というチェック項目の2つだけを抜き出して、レビューの観点に加えた。
実際、ある業務ルールの追加要望が来たとき、最初は既存の商品テーブルにフラグを足す提案が出ていたのを、対照表として切り出す設計に変更したことがある。ルールがその後もう一段複雑になったときも、既存テーブルの定義は変えずに済んだ。
一方で、「主観を排除して誰がやっても同じモデルになる」という本書の主張をそのまま信じられたわけではない。ある関係が実際の業務で成り立つかどうかを判断する場面では、結局のところ業務側への深いヒアリングと経験が必要で、属人性が完全に消えた実感はなかった。理論はあくまで議論の土台であって、業務理解の手間を代替してはくれない、というのが正直な感想だ。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有