ＫＥＹを頼りにエンティティを見つける方法は、誰でも同じ答えにたどり着く、よい方法です。
一方で、形式的なモデリングになりがちで、ほんもののエンティティにたどり着く保証はありません。
いくつかの限界を紹介します。
第一に、すでに存在するＫＥＹの名称に、エンティティの名称が左右されます。「顧客コード」があった、だから「顧客エンティティ」を見つけた！となるわけで、この名称が適切でないと、とんでもないエンティティがデータモデルに登場します。
第二に、コードや番号の体系が、実世界の管理対象の構造とずれている場合です。コード体系のまずさばかりが目立つデータモデルができあがり、ほんとうに見るべき対象が出てきません。典型的なものは「商品コード体系」です。３０桁もあり、それぞれの桁に意味があると、その構造を可視化するので精一杯。商品本来の構造が見えてきません。
第三に、同じ管理対象が２つ、３つとＫＥＹをもっている場合です。帳票や画面単位の小さなデータモデルを作成しているときは問題ないのですが、２００〜３００を超える画面・帳票の範囲に広がると健在化します。すなわち、本来は１つのエンティティとして認識すべきところ、それぞれのコードの名称が異なるために、２つ、３つのエンティティが切り出されてしまうのです。
この場合の正解は、１つのエンティティに２つ、３つのＫＥＹを記述しなければなりません。（ちなみに、この表現を「代替ＫＥＹ」と呼んでいます。）これをつきとめるためには、データ項目の値を検証する必要があります。「顧客コード＝０００１が鈴木商店、企業コード＝３５７が鈴木商店、よってこの２つは同じ企業を指していますね」といった要領です。
限界があるとしても、ＫＥＹに頼った第一近似データモデルは、より本質的なエンティティに近づくために必要です。ユーザ部門とシステム部門が共通に会話できる「共通言語」と「場」ができるからです。
« ＫＥＹがエンティティの守備範囲を決めるエンティティの粒度 »
