モデリングを考える - 第19回 関西ＩＴ勉強宴会 -

第19回 関西ＩＴ勉強宴会に参加しました。
このスケジュール登録に少し気が引ける名称の集まりは、元々お酒を飲みながらデータモデリングを主体とした上流設計を議論する勉強会だそうです。なお、今は会場の関係で基本的な議論と居酒屋での本番の議論に分かれています。

今回のテーマは「『チケット駆動開発』とデータモデリング」。前半はあきぴーさんチケット駆動開発の話で、後半はウォーターマーク・アプリケーションズの杉本啓さんのサロゲートキーとデータモデルのお話でした。

サロゲートキーは代替キーとも呼ばれ、プライマリーキーに自動採番のIDを用いる場合などがそれにあたります。サロゲートキーは、ユニークな項目がない場合やナチュラルキーを将来変更する可能性がある場合に有効なほか、分析の早い段階から利用できるなどのメリットがあります。

その反面、本来プライマリーキーとなるべきものが明確でなくなる、実装の都合で導入するのでユーザに説明しにくい、などのデメリットがあります。

そこで、サロゲートキーで表現するのではなく、“[foo]”のように実体名(概念)で表現するという方法が提案されました。ユーザーに説明しやすいほか、実装時はサロゲートキーに置き換えが可能です。

私の場合は、物理モデルで顧客ともやり取りする場合も多く、サロゲートキーのことをあまり気にしていなかったのですが、確かにユーザに説明が容易な概念モデルでありながら、実装をすすめながらもメンテナンスが容易な方法だと思いました。

このようなお話を聞いて、サロゲートキーを真剣に考えるなら、それが非正規化である事も意識すべきだと思いました。本来プライベートキーとなるべき属性がある場合、その属性とサロゲートキーは１対１または他対１の推移従属です。きちんと正規化するなら、別テーブルになるはずです。

モデリングとは、ある視点で物事を単純化することです。概念モデルはユーザと共有すべきデータの有り様を示し、物理モデルはDBの有り様を示します。しかし、サロゲートキーのある物理モデルは技術者同士であってもわかりにくく、必要な制約が漏れる事もあるでしょう。

一旦、サロゲートキーを別のテーブルに表現しておき、その情報をデータベースに与えれば良きに計らってくれるような仕組みはできないものかなどと妄想しました(うまくやらないとサロゲートキーのありがたみがなくなるかもしれませんが)。

今回は飲み会では時間切れで詳しいお話はできませんでしたが、XEAD Driver の渡辺幸三さんから、ナチュラルキーに対してサロゲートキーを人工キーと呼ぶ事もあるが、不変キーという考え方もあるとうかがいました。

モデルは最終的な物理モデルを示すだけでなく、コミュニケーションや考えるための道具でもあります。実装のために人間が合わせるのではなく、分析者の意図を表現したものが自動的に実装される事が好ましいのではないかなどと、門外漢ながら考えた次第です。

近頃、甘口の勉強会が増えていますが、久しぶりに濃い口の勉強会に参加して、刺激を受ける事ができました。機会があれば、また参加させていただきたいと思いました。