主キーはインデックスではない

　仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。

　たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。

　じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセスする処理を見ると、{a,d}の参照キーでロジックが書かれている。bとcが抜けているのでバグではないかと問うと、「aとdの組み合わせでレコードは重複しないので、大丈夫だと思います」と説明された。「大丈夫って...では、なぜＸの主キーにわざわざbとcが組み込まれているのでしょう」と問うと、「私が設計したわけではないんですが、その順に一覧したいからじゃないですかね」との返答だった。

　死んだ子の年を数えるような真似だが、この事例での設計者の発想を想像してみたい。最初にテーブルＸの主キーは{a,b,c}として構想されたのではないか。その順でレコードを並べることが多いからだ。それでテストしてみると、レコードの重複が生じることがわかって、主キーにdを組み込んだ。その後、そのテーブルＸを参照すべきテーブルＹがあったのだが、その上にbとcが載っていないことに気付いた。けれども、調べてみると{a,d}だけでユニークになることがわかったので、参照キーをそのようにしても問題がないことがわかった。その夜、自分の設計もなかなかイケてるじゃんと満足してビールを飲んだ。

　こういう行き当たりばったりな発想で設計されたDBは少なくないような気がする。その発想の中心にあるのは「プロセス指向」だ。つまり、データ処理の過程を支援するために主キーが設定される。したがってプログラムを構想する過程で、処理されるテーブルの主キーが「進化」する。そして、主キーに関するここらへんのビミョーな事情が文書化されることもないだろうから、設計者がプロジェクトから離れたとたんに保守性が低下してゆく。あとに残るのは設計意図が不明な巨大DBだ。

　ぜひとも理解しておいてほしいのだが、テーブルの主キーは、そのテーブルのレゾン・デートル（存在理由）といっていいほどに本質的な属性である。それはレコードの並び順を暗黙的に規定しもするが、これはDBMSの仕様レベルの些末な問題でしかない。主キーを設計することの重大さは他にある。

　そのことを理解してもらうために、私はセミナーで次の話をする。あるテーブルが{a,b}を主キー（候補キー）として、c,dを属性項目として持つとする。このデータ構造において、以下の２種類の関数従属性が成立する(*1)。

{a,b}→c
{a,b}→d

　大事な点は、これら以外の関数従属性が「成立してはいけない」という点だ。具体的には、以下のいかなる関数従属性も成立してはいけない。たった４個の項目しか含まれていないテーブルなのに、そのデータ構造によって２６種類もの関数従属性が「禁止される」のである。

a→b, a→c, a→d
b→a, b→c, b→d
c→a, c→b, c→d
d→a, d→b, d→c
{a,c}→b, {a,c}→d
{a,d}→b, {a,d}→c
{b,c}→a, {b,c}→d
{b,d}→a, {b,d}→c
{c,d}→a, {c,d}→b
{a,b,c}→d, {a,b,d}→c
{b,c,d}→a, {a,c,d}→b

　つまり主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。その責任の重大さがおわかりだろうか。

　なお、ここで問題にされている関数従属性はテーブルの静的な側面で、いっぽう、レコードがどのように処理されるか（たとえば読取順など）は動的な側面だ。後者は主キー設計において考慮される必要がない。そしてテーブルは「処理過程でのデータの一時保管場所」ではない。システム要件にもとづいてエンジニアリングされた「関数従属性の制約の束」をデータ構造に写像した結果である。

　ようするに、DB設計というものは専門的な作業であって、局面毎に検討課題を切り分けるような工夫なしでは完遂できない。主キーとインデックスとは検討すべき局面が異なる課題で、これらを同時に考えればわかることもわからなくなる。レコードの並び順など、DB全体の主キーを確立したあとでゆっくり考えたらいい。

　蛇足ながら、以上説明したようなややこしい議論を扱うのが面倒だからと「全テーブルの主キーを"id"にしてしまえばいいではないか。そうすればそこらへんの問題は存在しない」などと考えてはいけない。それでは問題がなくなるのではなく、DB設計者が扱うべき重大な問題が「潜航」する。結果的に、関数従属性やユニーク制約や更新不可制約の保全を、個々のアプリが引き受ける羽目になる。その先には、モグラ叩き的なコードの保守地獄が待っている。

*1.「{a,b}→c」を「{b,a}→c」と書いても同じである。つまり{a,b}が意味するのは、これらの「組合せ」であって「順列」ではない。関数従属性の検討において、レコードの並び順は問題にされない。