楽々ERDレッスンを読む(1) - 第１部 DB設計総論

羽生 章洋「楽々ERDレッスン (CodeZine BOOKS)」を読了したので３回に分けてまとめ。
まず第１部「DB設計総論」。
浅海氏智晴氏はこの第１部について「上級者向け」と書いてらっしゃるが、そんなことはない。
初めてDB設計をやる人は絶対に読んだ方がいいと思う。で、ここに書いてあることを論破できないなら、書いてある通りにした方がいいと思う。そういう意味で初心者向き。

第1部の要点は

• データ構造の設計時に、アイデンティファイア（ID）を導入する。
• 外部キーにするのはコードではなくアイデンティファイア。

これに尽きる。
で、なぜそう考えなくてはならないのか、が60ページにわたって詳細に書いてある。

コードとは

第1部で言う「コード」とは、コンピュータシステムの外で、ビジネス上の意味を持つ符号のこと。
携帯の請求書に印字された顧客番号とか、通販カタログの商品に与えられた商品コードとか、そういうもののこと。

ビジネスをするときに、この手のコードを何のために振るのかというと、名前（＝顧客名や商品名)には

• 重複
• 変更

があるので、顧客や商品の特定ができない（か、できても面倒くさい）から。

しかし、そうして導入したコードにも重複や変更があり得る。
ビジネス上意味のあるコードは、ビジネスの変化とともに変更が必要になったり（桁数が足りなくなるとか）、「『その他商品』を一括して9999番として扱いたい」といった例外要求が発生したりして、結局重複・変更が発生してしまうことがある。
ビジネスのためのコードなのだから、ビジネス上の要請には即座に対応できなくてはならない。
だから、コンピュータシステムの内部で、「ある対象を特定するための符号」としてコードを使うことは危険なのだ。
そこでアイデンティファイアを導入しましょうという話になる。

アイデンティファイアとは

アイデンティファイアとは、ビジネス上の意味を持たない、そのレコードが存在していることだけを示す識別子。
帳票に印字されることもないし、システムのオペレータが入力することもない、純粋にシステムの内部だけで利用される符号。
その役割は「インスタンスを一意に特定する座標の役割を果たす」ことに限定される。

外部キーとして参照するのは、コードではなくアイデンティファイアにしなくてはならない。
コードが外部キーとして参照されていると、ビジネス上の要請でコード体系に変更が発生する度に、参照している全テーブルのデータをいっぺんに変更しなくてはならなくなる。
IDが参照されていれば、ビジネスがどのように変化しようとも、マスタ上のコードの変更が、その他のテーブルに波及しない。

コードとアイデンティファイアの分離はなぜ常識になっていないのか

「名前を外部キーにするな」というのは常識だが、「コードを外部キーにするな」というのは2006年の今でも業界の常識ではない。
が、システムの外部で体系が決定されるコードは、絶対不変である保証はない。
ということは、名前を外部キーにできないのと同じ意味で、コードは外部キーにできない。
これが常識になっていないのは、何かトレードオフがあるからなのか、開発者がコード体系の変更などという不定の未来のことを考えていないからなのか。
どうも、後者ではないかと疑っている。
個人的な経験では、サロゲートキー*1の導入によって何か面倒なことが起きたことはない。
T字形ER手法も、サロゲートキーの導入を否定していない。
実践 クライアント・サーバ データベース設計テクニック (SRCハンドブック―STシリーズ)という、T字形ER手法の最初期の本にこうある：

P-27
部門コードか２桁とすれば、組織が変更されて部門の数が100以上になったならば、attributeの
部門コードの桁数の変更だけではなくキー(当該entityとリレーションシップを設定されている
他のentityに、アクセス用に挿入された部門コードの参照キー)まで変更しなくてはならない。
これでは安定したデータ構造とは言えまい。
...
マスター・キー概念とER手法におけるidentifier概念は区別されなければならない。この2つを
混同すると、論理データ設計がいい加減になってしまい、ER図という新しい手法を使ってデータ
構造を構築していながら、(データ重複は排除されてはいるが)内容は従来のまま温存されている、
ということになりかねない。

というわけで、私もコードとアイデンティファイアの分離派に属する。
が、サロゲートキーの否定論というのを何かの本で読んだので、そっちもチェックしてみます。何か問題あるのかなあ。何も思いつかないなあ。

*1:アイデンティファイアであって、かつ主キー、ぐらいの概念