今日も見に来てくれて、ありがとう。地道に書いていきますので、また見に来てくださいね。先週、700%にユーザー数がいきなり増えていて、びっくりしました。なぜかカナダから、同時期に34ユーザの訪問があったのでした。ま、そのひとたちは、二度と来ないと思いますけど。そう34ユーザーでも700%です♪
さて、先日エンティティの定義について書きました。エンティティが定義できたら、次はエンティティの種類について検討します。システム設計では、データをマスタ系とトランザクション系というふうに分けて管理することが多いのですが、TM(T字形ER手法)では、エンティティをリソースとイベントの二種類に分けて考えます。リソースはその名の通り、その組織の中で管理されている資源にあたるものになります。イベントは基本的にはその組織の中で発生した出来事（実施した仕事）を記録したものになります。また、イベントはリソースから生成することができるので、全てのリソースを把握することがとても重要なことだと思います。なので、リソースとイベントの数を比べたときに、リソースの数が多ければ、その組織はまだまだ改善の余地（新たに仕事を生み出す可能性が残っている）があり、イベントの数が多ければ、打つ手が少ないのでは、という可能性が考えられます。
TMでは、エンティティの種類の定義は以下の通りです。このように、明確に定義されているのがTMの特徴です。他の手法でもリソースとイベントを分ける場合はあるようですが、その場合でも例示（社員はリソース、受注はイベント等）のみで、定義は示されていないということだそうです。
イベント：日付（タイムスタンプ）によって並べられる リソース：イベント以外
例えば、認知番号が「受注番号」だとエンティティは「受注」になり、「受注日」という属性があれば、そのエンティティはイベント、ということになります。そう、とっても簡単ですね。これで世の中のエンティティをすべてイベントとリソースに分けることができるようになりました！
めでたし、めでたし、と、なればよかったのですけど、現実世界はそんなに甘くありません。ある日、最初の悩みが生まれました。それは、イベントのふりをしているけれど、イベントではないエンティティがあるんじゃないか、という悩みです。基本的な考え方として、イベントは、取引の実績など、事実を記録していくもの、という特性があり、リソースは、仕事をしていく上で必要な資源、という特性があります。上記のルールどおりに考えると、資源にあたるものだけれどもイベントに分類されてしまうものが出てくるのです。例えば、契約番号に契約日があればイベントです。でも、「契約」エンティティが組織にとって重要な資源として扱われそこからさまざまな仕事が生まれてくるような場合、リソースになるような気がするのですよね。仕事とともに忘れ去られてしまってよい情報ではありませんのでどうしてもリソースとして扱いたくなったのでした。で、よくよく考えてみたところ、日付が表していることがらに違う意味があったのです。
日付の違い： １．記録のためのタイムスタンプの日付（監査証跡） ２．開始、終了などの、範囲を表す日付（未来日付）
そう、この「１．」の方がイベントのよりどころになる日付で、「２．」の方は違う、ということを発見したのでした。ぼくが悩んだ今回の「契約日」は、契約を交わしたイベントを記録した日付ではなくて、もうちょっとていねいに表現すると、この日から契約が始まりますよ、という「契約開始日」だった、というわけです。このように日付の意味を考慮した場合には、契約がリソースになることがあるので注意が必要です。契約をリソースとして正しく管理できれば、譲渡や継承の問題も解決しやすくなりそうですね。
このリソースとイベントの分類、なにがうれしいの？というひともいるかも知れませんので、ちょっとだけ補足します。例えば、海外旅行保険契約やレンタカーの貸渡契約などは、ルール通りイベントで問題ないと思います。ただ、その時に契約したひとの情報をイベントの中に記録しておくだけだと、新たな仕事も生まれません。でも、これら契約者の情報をリソースとして管理できるような仕組みにした場合、新たな可能性が考えられるようになります。例えば、契約者に対して、他の類似商品の販売や、サービス向上の可能性を考えられます。イベントとして埋もれてしまったままだと、その可能性に気づくのはなかなか難しいと思います。システム設計上はもちろんですが、ビジネスとして考えた場合にも、リソースを把握して見える化する、ということがとても重要ですね。