ブログ記事
「サロゲートキーの呪い」を知っているか――渡辺幸三『システム開発・刷新のためのデータモデル大全』
主キーをただの連番として扱っていないか。
渡辺幸三著『システム開発・刷新のためのデータモデル大全』（日本実業出版社、2020年）は、この一見当たり前の問いから始まる。ORMやフレームワークの標準に従い、すべてのテーブルにサロゲートキー（自動採番の単独ID）を振っただけの設計が、なぜ将来のデータ不整合を招くのか。金物屋の経営プロセスから仕訳・決算、シフト契約、生産工程まで、多様な業務ドメインのモデリングパターンを通じて、著者は実務に裏打ちされた論理設計を説く。
1. 「サロゲートキーの呪い」――便利な自動採番が招く整合性崩壊
リレーショナルデータベースの主キーは、単なる識別番号ではなく「ユニーク制約」と「更新不可制約」によってビジネスルールを守る防壁だ。ところが開発の利便性を優先してサロゲートキーだけを主キーにすると、本来は変更不可能であるべき業務上の識別子がシステム上で更新可能になってしまう。
本書はこの現象を「サロゲートキー導入の呪い」と名付ける。サロゲートキーを使うこと自体を否定するのではなく、それを採用する場合は本来の業務キーに対して個別のユニーク制約を追加で張るなど、データベース層での整合性担保策を併せて講じる必要がある、というのが主張だ。
2. 関係は3つのトポロジーに集約される
複雑に見えるテーブル間の関連も、著者は「親子関係」「参照関係」「派生関係」という3つの接続形態に整理する。
flowchart TD
A["親子関係 (∈)\n1対多・主キーの一部を継承\n関係は変更不可"]
B["参照関係 (⋯)\n1対多・主キーを含まない\n関係は変更可能"]
C["派生関係\n1対1または0\n条件付きの関数従属"]
style A fill:#e8f4fd,stroke:#4a9eda
style B fill:#fff8e1,stroke:#f5a623
style C fill:#e8f8e8,stroke:#4caf50
親子関係は「多」側の主キーが「1」側の主キーを部分的に含み、一度結ばれたら変更されない。参照関係は主キーを含まず、属性の更新によって接続先を切り替えられる。派生関係は特定条件下でのみ成立する1対1の関連だ。この3分類に沿って関係を定義するだけで、自己流の曖昧な設計を避けられる。
3. 現行業務をなぞらない――「創造的データ指向アプローチ」
既存の業務フローをそのままデータ構造に置き換える設計は、過去の複雑な負の遺産を引き継いでしまう。本書が提唱するのは、設計者の経験や他業界の知識を掛け合わせ、あるべきデータモデルの骨格を先に定義してから業務プロセスを見直す「創造的データ指向アプローチ」だ。データ構造を起点に据えることで、業務そのものの簡素化が進む。
4. 業務知識とデータモデルは不可分
本書の厚みの大半は、簿記の仕訳や決算、要員シフト契約、生産管理の工程、予算実績管理といった具体的な業務ドメインのモデル解説に割かれている。テーブル設計の理論だけを学んでも、業務知識がなければ実用的なモデルは組めない、という前提に立っている。
この本が解決できる具体的な状況
ORMの標準的なやり方に従ってすべてのテーブルを単独のサロゲートキーで設計した結果、データ量やルールの複雑化に伴って重複や不当な更新による不整合が表面化している――この状況に、本書は「主キーに業務上のユニーク制約を張り直す」という具体的な処方箋を与える。また、システム刷新やDX案件を発注する立場で、ベンダーが提示する設計図の妥当性を技術的に評価する手段を持たない非技術部門のリーダーにとっても、プログラミング言語に依存しない「データの形」という共通言語を得る手がかりになる。
こんな人に向いている
- サロゲートキーだけに頼った設計でデータ品質の低下に直面し、より堅牢な主キー設計へ移行したい開発者
- DDDの永続化レイヤを実際の業務ドメインに合わせて設計したいエンジニア
- システム刷新の発注側で、ベンダーの設計力や成果物の品質を自ら評価・監督する必要があるリーダー
逆に向いていないケース
- アジャイルで開発されるモダンなWebサービスやBtoCプロダクトの設計者: 紹介されるモデルの多くは基幹業務システム（会計・在庫・生産管理）向けに最適化されており、実務への適用や関連性を描きにくい場面がある
- 複数の設計手法を比較検討したい人: 著者の主張や独自ツールの解説に紙幅が割かれ、他アプローチとの客観的な比較は薄い
- DB設計の基礎（正規化、主キーの役割）をまだ固めていない人: 難易度は上級で、基本用語の理解を前提に進む
知っておきたい限界
批判として押さえておきたい点が二つある。
一つは独自の図法・用語の学習コストだ。本書が採用するデータモデル図の記法や用語は著者特有の規格であり、業界標準のIE記法などとは異なる。テーブルの親子・参照関係を一目で把握できる利点はあるが、他のドキュメントや他社の設計者とのコミュニケーションでは読み替えが必要になる。
もう一つは、扱う業務ドメインの偏りだ。紹介されているモデルの多くは簿記・シフト管理・生産工程といった基幹業務システム向けに最適化されている。アジャイルで開発されるモダンなWebサービスやBtoCのプロダクト開発では、そのまま適用できる場面が限られる。「考え方」を抽出して自分のドメインに翻訳する作業が読者側に必要になる。
同じテーマの本との比較
先に『達人に学ぶDB設計徹底指南書』で正規化と物理設計への変換という基本手順を身につけておくと、本書が示す業務パターン集を「なぜその形になるのか」まで含めて理解しやすくなる。
『事業分析・データ設計のためのモデル作成技術入門』とは並行して参照する関係にある。あちらが業務分析からエンティティを抽出する「考え方」を扱うのに対し、本書はその成果物としての具体的なモデル例を業務領域別に多数示す。抽象的な技法と具体的なテーブル構成例を行き来すると、設計の引き出しが立体的になる。
単一の業務システムのモデリングが腹落ちしたら、次は複数のデータストアが絡む大規模システムへ視野を広げたい。『データ指向アプリケーションデザイン』は、本書が単一RDBの中で完結させていた整合性の話を、レプリケーションやパーティショニングといった分散データシステム全体の原理へ押し広げてくれる。
まとめ
主キーを「ただの連番」として扱うか、「ビジネスルールを守る防壁」として扱うかで、システムの寿命は大きく変わる。本書は具体的な業務ドメインのモデル例を通じて、その差を体感させてくれる一冊だ。
筆者の体験から
業務システム寄りの機能を担当していた頃、ORMのお作法どおりauto incrementのIDだけを主キーにしたテーブルで、業務上は同一のはずのレコードが重複して登録されるという不具合を出したことがある。原因を追うと、アプリケーション側のバリデーションだけに頼っていて、データベース側には業務上のユニーク性を担保する制約が何も張られていなかった。本書の「サロゲートキーの呪い」という言葉を読んだとき、あのときの不具合はこれだったのかと腑に落ちた。
それ以来、サロゲートキーを主キーにする場合でも、業務上の識別子（伝票番号や外部連携のコードなど）には必ず個別のユニーク制約を追加するようにしている。親子・参照・派生の3分類も、レビューで「この関連は将来つなぎ替わり得るか」を確認する観点として使うようになった。
ただし、紹介されているモデル例の多くは簿記や在庫管理、生産工程といった基幹業務システム寄りで、自分が関わってきたアジャイルなWebサービスの開発にそのまま持ち込める場面は正直少なかった。個別のモデル例よりも、「主キーの制約を厳格に扱う」「関係を3種類に整理する」という考え方だけを抜き出して使っている、というのが実態に近い。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有