今回も、シナジーマーケティングさんの会議室をお借りしました。毎回ありがとうございます。参加者は13名。ちょっと事情があり参加者を絞ったのですがそのおかげで一つの大きなテーブルを囲む形式で全員で議論が出来て大変楽しかったです。
今回は皆さん翌日に用事があったようで２次会に流れたのは３名だけでした。家庭生活にもやさしい勉強会でした(苦笑)
＜今回の勉強会資料＞
Kansai-IT-Benkyo-Enkai_2012-09-28_Sugimoto.pdf
＜新刊「チケット駆動開発」の紹介＞
著者の一人 あきぴーさん
翔泳社から絶賛発売中の「チケット駆動開発」の説明。チケット駆動開発というのは、バグを可視化するバグトラッキングツールを発展させて、出来る限り多くのタスクを可視化することでプロジェクトを進めていこうという開発方法論です。
内容は本を読んで頂くのが一番ですので、ここでは私（佐野）の所感を述べます。
本ではredmineというツールが全面に出ています。チケット駆動開発という方法論はツールを前提とはしていませんので、今後はツールから独立して話されることが多いそうです。また、プロジェクト管理手法であるWBS(Work Breakdown Structure)は管理者が書くものですが、チケットは作業者が書くという特徴があります。
この点がどうやらチケット駆動開発のキモだと思いました。これが広がると、日本独自の悪慣習である「多重下請け構造」が解消されるきっかけになる可能性があります。しかも日本発というか大阪発の開発方法論です。是非広がって欲しいと思います。
＜サロゲートキーとデータモデル＞
ウォーターマーク・アプリケーションズ 杉本啓さん
元コンサルティングファームにおられ、独立して「EXCELメタボを解決する」FusionPlaceというツールを作られています。今もこのツールを継続的にバージョンアップされていますので現役のプログラマーでもあります。その杉本さんが概念モデルに関して恐らくまだ世間的に解決策がないテーマについて問題の整理と解決策の案を提示して下さいました。
ここで話題にするサロゲートキーは、概念モデルの問題です。論理モデルや物理モデルで実装上の都合で追加するキーの話ではありません。概念モデルは外部設計の一部です。
あなたがオブジェクトモデル系の技術者なら問題点に気づいていない可能性が高いです。データモデル系の技術者は問題点は知ってるはずですが「オブジェクト指向が出てきたからややこしくなった」という意識が強いと思います。
サロゲートキーをどう扱うかという話題は、実は「実体をどうとらえるか」という問題なのです。もっと突き詰めると「それは実体ですか？関係ですか？」という質問にどう答えるかという話になります。それを驚くほど簡単にわかりやすく説明して頂きました。
＜１＞サロゲートキーとは何でしょうか？（P.2～P.8）
オブジェクト指向言語が出てきたときに、インスタンスを永続化（パーシスタンス）するためのキーとしてオブジェクトキーを使おうとされました。たとえば社員マスタなら社員コードというキー（ナチュラルキー）があるはずですが、人工的に振られるオブジェクトキーの方がプログラム的には使いやすいです。それをサロゲートキーと呼びます。
RDBMSでも、例えばORACLEならレコードを挿入したときに内部的にはROWIDが振られます。それがサロゲートキーです。ただ、データモデル図の中にROWIDを入れるSEはいないでしょう。
ここでは概念モデルを考えます。概念モデルは外部設計の一部ですからお客様に説明してレビューしてもらう必要があります。お客様に説明して違和感のない書き方はあるのでしょうか？
＜２＞サロゲートキーをやめて「実体名」を書いてはどうでしょう？（P.9～P.11)
データモデルの中に、「商品ID」とか人工的なものを入れるのをやめて［商品］と実体名を書いてはどうでしょう。実際の値（インスタンス）を書くときにはあえて①とか②とかの意味を予感させないようなものにします。極端に言えば写真でも良いのです。それにより概念的なものであることを示すことが出来ます。
伝統的なDOA（注）では、表のことをエンティティと単純に呼ぶこともありますが、ここでは概念として実体があるものをエンティティと呼びます。関連（リレーションシップ）なのか実体なのかで概念モデルが変わります。
（注） 「伝統的なDOA」についてあまりご存じのない方は、私が解説したページをご覧ください。
伝統的なDOAでは、ナチュラルキーを主キーにするように学びますが、実際にはナチュラルキーが変更になったときの影響を考えて、サロゲートキーを使うことが良くあります。例えば部品表（BOM)の主キーに材料コードというナチュラルキーを使ってしまうと、万一材料コードが変更になった時の影響が大きすぎますからほとんどのSEはサロゲートキーを使います。
主キーをサロゲートキーとした場合は、ナチュラルキーにユニーク制約をつける必要があります。それをしないとプログラムが複雑になります。
＜３＞交差実体を認めるかどうかの基準(P.12～P.15)
実体と実体を組み合わせたキー（複合キー）は通常「関連」ですが、それを実体とみなすことを許すかどうかは大きな判断になります。伝統的ERモデル（注）では実体と関連を区別しませんが、区別せずにサロゲートキーを使うと、この議論の冒頭のとおり情報量の貧弱なモデルを作ってしまいます。
（注）「伝統的ERモデル」について、DOAの概念を作り出された椿正明さんの「データモデルの進化」をお読みください。
＜所感＞
「伝統的なDOA」では何の疑いもなくナチュラルキーを主キーとするでしょう。でも商品コードは本当に変わりませんか？商品コードが変わったら、[商品]という実態も変わるのでしょうか？例えば私は「佐野初夫」として通っていますが、名前が変わっても私は私です。コードが変わろうと名前が変わろうと、「そのもの」は不変です。それが「実体」です。
実装の話ではなく、概念レベルの話として正面からサロゲートキーを扱った議論は今まで見たことがありませんでしたが、杉本さんのおかげで相当簡潔に整理されたと思います。
業務をモデリングするという事は、ある事象が実体なのか関連なのかを決めることでもあります。用語を変えると、「もの（実体）」と「こと（関連）」を切り分ける事です。仏教の世界では色即是空と言って、全ては「こと（関連）」であると悟ることが重要だとされています。
これ以上深く考えると、哲学の世界に入ってしまうでしょう。現に業務分析をするためには哲学と論理学と数学を相当高度に極める必要があると考える流派（？）もあります。杉本さんは、そのややこしい部分に踏み込む寸前で立ち止まる基準を提示されました。私もこれで充分だと思います。
言わば、寸止め理論です。
私は個人的に、オブジェクト指向設計でのデータモデリングの基準になるべき理論ではないかと思っています。
---------------------------------
メーリングリストで議論しませんか？
---------------------------------
この件について「私はこう思う」という意見のある方は是非我々のメーリングリストに投稿して下さい。
KwansaiIt@googlegroups.com
メーリングリストへの参加は簡単です。次のアドレスに空メールを送るとリンクが送られてきますので、それをクリックするだけです。退会も簡単です。
KwansaiIt+subscribe@googlegroups.com
※+は１バイトのプラスの文字です
以上