« サロゲートキーは強制されるべきものではない | トップページ | サロゲートキーの事例解説 »

2012.02.02

「強制されたサロゲートキー」の事例を眺める

 Ruby on Rails上で実装されているプロジェクト管理ツール「Redmine」をインストールした。実務で使うためではなく、前回記事で言う「サロゲートキーを強制する開発基盤」のひとつであるRails上のDB設計事例を眺めてみたかったからだ。

20120201_2

 サロゲートキーが強制される基盤上で作られるテーブル構造の特徴は、複合主キーが許されないために「親子関係」が出現しない点である。たとえば図1において、membersはuser-idとproject-idの組み合わせをユニーク制約としているが、それらは一次識別子に含まれていないので、usersやprojectsとは「参照関係」をとっている。つまりER図だけ眺めたら、memberレコードを追加した後で、user-idやproject-idの値が変更可能であるように見える。

図1

[users] id, firstname, lastname, ...

| [projects] id, name, ...
| +
| |
| └―…
└――…[members] id, mail-notification, {user-id, project-id}, ...
      +
      |
      └―…[member_roles] id, member-id, role-id, ...
      ┌―…
      |
      +
      [roles] id, name, ...

 しかし、いったん登録したmembers上のproject-idやuser-idを変更できるページは見当たらないので、図2が本来のデータ要件だったように思える。図2においてmembersは、usersとprojectsの「子」である。そのuser-idもproject-idも、いったん追加した後で値を変更することができない(一次識別子に含まれているため)。こちらのほうがモデルとして自然に思えるのだが、そのような部分は他にもいろいろあって興味がつきない。

図2

[users] user-id, firstname, lastname, ...

| [projects] project-id, name, ...
| +
| |
| └―∈
└――∈[members] user-id, project-id, mail-notification, ...
      +
      |
      └―∈[member_roles] user-id, project-id, role-id, ...
      ┌―∈
      |
      +
      [roles] role-id, name, ...

 テーブル定義をインポートして、ActiveRecordの記述等を手がかりにしてテーブル関連を付け足しただけのもので、よくわからない部分もあるが、しくみを理解したりアドインを作ったりするためにもそれなりに参考になるだろう。Redmine.xmlをダウンロードしてRedmine.xeadにリネームして、XEAD Modelerで眺めてみてほしい。自由に改変していただいてもかまわない。

|

« サロゲートキーは強制されるべきものではない | トップページ | サロゲートキーの事例解説 »

コメント

サロゲートキーを用いたDB設計はMySQLのauto_increment機能と
相性が良いというところがあると思います。
完全に実装側の都合ですが…

投稿: SH2 | 2012.02.02 13:18

サロゲートキーを強制されるのは最初抵抗ありましたね。。
サロゲートと聞くと映画サロゲートを思い出しますwサロゲートという擬似体を遠隔操作して実生活を送るという発想が面白かった。

投稿: RET315 | 2012.02.03 12:37

コメントを書く



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




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/53882506

この記事へのトラックバック一覧です: 「強制されたサロゲートキー」の事例を眺める:

« サロゲートキーは強制されるべきものではない | トップページ | サロゲートキーの事例解説 »