« 会計システムのクラウド化と税理士事務所 | トップページ | 技術者にリフレッシュ休暇を「強制」せよ »

2010.09.08

「複合キー」と実装用フレームワーク

 テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、

分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。

というものだ。根拠を説明しよう。

 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルAが「社員」で、Cが「趣味」で、ACが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の5つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。


 [A] {a},  b
 + 100 aaaaaaaa
 | 200 bbbbbbbb
 |
 └―∈
     [AC] {a, c}, e
 ┌―∈   100 10 2
 |      100 11 0
 |      100 12 1
 |      200 10 -2
 |      200 11 2
 |      200 12 1
 +
 [C] {c}, d
    10 11111
    11 22222
    12 33333

 これをデータベースとして実装した場合、テーブルACについては次の3つのパターンのいずれかとなろう。Ⅰはそのまま実装したパターン、Ⅱは代理キー(id)を導入したうえでユニーク制約を設けたパターン、Ⅲは代理キーを導入しただけでユニーク制約を設けないパターンだ。これらのうちで適切なのはⅠとⅡである。

Ⅰ [AC] {a, c}, e
      100 10 2
      100 11 0
      100 12 1
      200 10 -2
      200 11 2
      200 12 1

Ⅱ [AC] {id}, e, {a,  c}
      0001 2 100 10
      0002 0 100 11
      0003 1 100 12
      0004 -2 200 10
      0005 2 200 11
      0006 1 200 12

Ⅲ [AC] {id},  e, a,  c
      0001 2 100 10
      0002 0 100 11
      0003 1 100 12
      0004 -2 200 10
      0005 2 200 11
      0006 1 200 12

 Ⅲが適切と言えないのはなぜか。本来必要なユニーク制約への対処がアプリケーション側で完備されていれば問題ないが、そうでないなら、次のような関数従属性違反データが登録される事態(アノマリー)を避けられないからだ。この場合なら、関数F(200, 12)の答が1なのか-1なのかわからない。こうなれば、会計情報を含むデータベースとしては使い物にならない。

Ⅲ [AC] {id},  e, a,  c
      0001 2 100 10
      0002 0 100 11
      0003 1 100 12
      0004 -2 200 10
      0005 2 200 11
      0006 1 200 12 ←┐
       :  :  : :   a,cの値が重複している
      0256 -1 200 12 ←┘

 アプリケーション側でユニーク制約を保障するためのコードが書かれていたとしても問題は残る。なんらかの形でそれが強制されていないのであれば、必要な制約チェックが保守フェーズで失われてしまう可能性があるからだ。ようするに「本来はデータベース側で記述できる制約をアプリケーション側で面倒見てもらう」というやり方は、データベースシステムの実装指針としては不適切なのである。

 分析段階で本来のユニーク制約を認識しないまま、いきなりⅢのように実装してしまったケースなど最悪だ。そもそもアノマリーをアノマリーとして認識できないからだ。見かけ上はまったく問題ないように見えるのだが、知らないうちにデータが濁ってゆく。そういうわけで、少なくとも分析段階では、複合キーにもとづくものだろうが何だろうが関数従属性が確実に認識され、対処されなければならない。

 では、ⅠとⅡのどちらがベターなのかというと、Ⅰである。より正確にいえば「論理要件により近い形で実装できるような環境(実装用フレームワーク)がベター」である。

 ただし、論理要件のままでの実装を前提とすれば、実装用フレームワークはさまざまな面で複雑なものにならざるを得ない。たとえば、複合キーの利用を前提とする「動的参照やそれにもとづく削除妥当性検査」といったデータ要件をフレームワーク側で制御できるとすれば、その内部は相応に複雑になるはずだ。

 しかし、その種の複雑さは「歓迎すべき複雑さ」である。ややこしいことをより多くフレームワークに委譲できるゆえに、アプリケーションが単純で済むからだ。言い換えれば、論理要件に対する「実装上の調整」が少なくて済むからだ。ゆえにフレームワークの開発において、複合キーのような基本的要件を「フレームワークの内部が複雑になるから」などといった理由でスルーすべきではない。

 いずれにせよ、フレームワークにどのような「歓迎すべき複雑さ」を盛り込み、アプリケーションの複雑化をどのように抑制するか――その判断はフレームワークの開発者にまかされている。結果的に、さまざまな特性と適性を持つフレームワークが生み出される。そういう意味で実装用フレームワークというものは、開発者の個人的な実装観を反映した「作品」だと考えたほうがいい。

 したがって、避けるべきなのは、個別の実装用フレームワークの枠組みを通して論理設計のあり方を帰納的に把握しようとすることだ。たとえば、HibernateやRailsのような複合キーを扱いにくいフレームワークにたまたま馴染んだとしても「複合キーなど使わずともデータ要件はまとめられる」などと考えてはいけない。

<過去の関連記事>
代理キーは「スタイル」ではなく「テクニック」

|

« 会計システムのクラウド化と税理士事務所 | トップページ | 技術者にリフレッシュ休暇を「強制」せよ »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「複合キー」と実装用フレームワーク:

» 複合キーと代理キー1 [HATのブログ]
渡辺幸三氏のブログで、複合キーの必要性について述べられていました。そこで複合キーと代理キー(人工キー)を対峙して書かれている事が気になりました。私の考えは「代理キーは必要な事があるが、それとは関係なく複合キーは必須です」というものです。長くなりますので、まず渡... [続きを読む]

受信: 2010.09.10 12:38

» 複合キーと代理キー2 [HATのブログ]
複合キーこそがDOAの中心概念のひとつである事を解説したいと思います。その前に、私がDOAにはまった経緯ついても説明します。結論は渡辺幸三氏と変わりませんが、いちSEの私はDOAをそれほど厳格にとらえていません。お叱りを受けるかもしれませんが、業務設計に役立... [続きを読む]

受信: 2010.09.10 17:10

» [DOA]DOA設計手法との出会い [kurokouji39の日記]
システムの品質を向上させるため、DOAを勉強しているのだけれども... 従来の方法は、 1.プログラムを依頼され、顧客の要望を伺う。 2.VB、ACCESS、.NETなどプラットフォーム、ライブラリを用意する。 3.とりあえずテーブルを作ってサンプルデータを用意する。 4.パネル(フ... [続きを読む]

受信: 2010.09.10 20:20

« 会計システムのクラウド化と税理士事務所 | トップページ | 技術者にリフレッシュ休暇を「強制」せよ »