« 仕様書の類型化と様式化 | トップページ | 「仕様書プログラミング」とその運命 »

2013.11.29

複合主キー「否定派」と「許容派」の論争

 定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。

 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。2つほどの理由が考えられる。

 まず、単独主キーとしてIDを機械的に置くやり方(ID方式)が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子(オブジェクトID)を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデアが妥当だとしたらシステム開発の合理化がよほど進展しているはずなのだが、私にはかえって混迷を深めているようにしか見えない。

 2つ目の理由は実務レベルのものだ。1つ目の理由と無関係ではないのだろうが、HibernateやRuby on RailsといったWEB開発のためのメジャーな開発基盤では、複合主キーの利用を認めていない(使えないわけではないが推奨されていない)。

 それだけなら、「選定された基盤に付随する実装上の制約」として考慮すればいいだけなのだが、これで話が終わらないからややこしい。その種の基盤からキャリアを始めた技術者が、ID方式を正統なDB設計手法として勘違いしてしまうことがある。複合主キーを許容する基盤を使った場合でも、論理レベルからいきなりID方式で設計したりする。

 喩えるなら「オートマ・モード搭載のF1カーに乗った人」である。オートマ車にしか乗ったことがない一般人が、そのF1マシンに乗ってもオートマ・モードにこだわる。それで「ほら、オートマでもF1カーは動かせるじゃないですか。オートマこそが、正統かつ汎用的なドライビング手法なんですよ」と語る。オートマ走行は実践しやすいので、その主張は一般人には受け入れやすい。いっぽうF1ドライバーは、ネイティブのミッション・モードでなければ高速での精妙なコントロールができないことを知っている。しかし、彼らの説明は専門的で一般人には理解しにくい。

 ようするに、オートマ・モードやID方式は、複雑な問題を取り扱わずに済むような特殊な状況に向けた、良くも悪くも「便法」なのである。私はRuby on Railsを便利な開発基盤だと思うが、それを使って、たとえば生産管理システムのように複雑なデータ要件を扱うシステムを作ろうとは思わない。主キーがシンプルになる代わりに、あちこちに辛気臭い配慮が必要になるからだ。けっきょく別の何かがややこしくなって、トータルの保守コストが増える。

 たとえば、a=F(b,c)という関数従属性が存在するとしよう。これは論理レベルでは、{b,c}を複合主キーとし、aを属性項目とするテーブルを要求する。いっぽう、複合主キーを許さない基盤では、ID等の代理キーを単独主キーとして、a,b,cを属性項目とせざるを得ない。この場合、正規形を崩したことになるので、データ整合性を保全するための調整が別途必要になる。すなわち、{b,c}のユニーク制約をテーブルに付与するとともに、b,cについてはアプリ上で更新されないように配慮しなければいけない。

 ところがこのとき、いきなりID方式で設計する設計者は、a=F(b,c)のようなデータ要件を見落としてしまう。単独主キーのIDに対してa,b,cを属性項目とするだけで満足する。結果的に、主キーがシンプルであるわりに、使えば使うほどデータ整合性が崩れてゆくシステムがまたひとつ生み出される。

 データ要件がシンプルな案件では、どんな開発基盤を使ってもたいした違いはない。しかし、業務システムのような案件では、複合主キーを許容する基盤を使ったほうがいい。いずれにせよ、運よくシンプルな案件ばかり手がけるとは考えにくいので、複合主キーを含むオーソドックスなDB設計手法を身につけておいたほうが無難である。そうでないと簡単な正規化崩しにも失敗してしまう。


*1.しつこく述べてきたように、複合主キーを許容すべきかどうかは「ナチュラルキーか代理キーか」の議論とは関係ない(直交している)。じっさい私はナチュラルキーを主キーとすることに反対しているが、複合主キーは許容すべきだと主張している。
本ブログでの参考記事:
ナチュラルキーを主キーにしてはいけない
アンチパターン「成長する主キー」

|

« 仕様書の類型化と様式化 | トップページ | 「仕様書プログラミング」とその運命 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 複合主キー「否定派」と「許容派」の論争:

« 仕様書の類型化と様式化 | トップページ | 「仕様書プログラミング」とその運命 »