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

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

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

図１

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

図２

[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で眺めてみてほしい。自由に改変していただいてもかまわない。