» 【146号】 エンティティタイプをどう決めるか

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【146号】 エンティティタイプをどう決めるか

■エンティティタイプは決めるもの
決めるものを決めないと前に進みません。決まるものを決めると矛盾が発生し
ます。決めるものは独立変数、決まるものは従属変数だからです。

しかし、決めるべき独立変数といっても、上限や下限があり、その範囲のなかで、
適切に決めないと経済最適から大きく外れるといった危険性があります。
データモデリングにおけるエンティティタイプは、ソケットの脚の間隔、交流の
50/60サイクルなどと同様、標準化として決めるべきもののように思われます。

■処理のパターン化のために
われわれは五感「見る、聞く、嗅ぐ、味わう、触れる」を通じて情報を入手し
ますが、ビジネス活動に必要な情報のほとんどは「見る」ことによって入手し
ています。「見る」対象は、映像、図、表、文章などとなりますが、安価に情
報共有する手段として、図と表は非常に重要なものと言えます。図は「もの
(=エンティティ)」と「もの」との関係を明快に示しますし、表は「同種の
もの(≒エンティティタイプ)」を一括して表示します。
ビジネス活動で発生する大量のトランザクションには、同じパターンで処理で
きるものがあり、またかかわる関係者や商品も同じ形式で記述できるものが
多々あります。したがって、これらを表/テーブルとして一括表現/ストアするの
は極めて自然であり、リレーショナルDBMSが考案され、普及していったの
も当然の成り行きと思われます。
情報システムは実世界の情報をデータ化し、その形式ごとにストアし、処理す
るものですから、その構築にあたっては、どれだけの形式を用意すべきか、また
その相互関係がどうなっているかを見抜かなければなりません。これがデータ
モデリングであり、その形式がエンティティタイプと言うことになります。
実世界を正しく捉え、これを適切な実装技術−これが進化すれば再度これ−
を用いて実装空間に写像すれば、正しい情報システムが得られると考えます。

■必要な割り切り
「エンティティタイプは属性によって構成される」あるいは「属性はエンティ
ティタイプに所属する」とされますので、いろいろな属性を持つ個性的なエン
ティティを、タイプとして一括する場合は、割り切りが要求されます。たとえば、
社員の中には、営業マンもいれば技術者や工員がいます。海外勤務者や
産休中、また長期療養中の人もいます。これらの社員を管理するためには、
社員共通の属性に加えて、独自の属性を用意する必要があります。これらは
一般にサブタイプとして扱われるわけですが、厳密に扱おうとすると、サブタイプの
サブタイプなども必要になり、大多数のユーザにとっては過度の複雑化となり、
形式化のメリットを損なうことになります。

■リソース系のタイプ化が難題
われわれは、エンティティタイプを、リソース系、イベント系、在庫型、要約、
断面の5種類に大分類していますが、使われ方の多様な、そしてMDM
(Master Data Management)の主テーマ、リソース系のタイプ化が一番難しい
ようです。とくにイベントの中で、Who Whomの役割を持つ人・組織、および
Whatの役割を持つ商品やサービスなどが難しいものかと思われます。その理由
は、多くのユーザによって、いろいろな局面で、長期にわたって使用されるた
め、そのニーズを洗い出し調整するのが難しいからだと思われます。
まず、人・組織について。営業は顧客を、また購買は購入先を意識しますが、
経理は運送会社、銀行、飲み屋を含めて、取引先と考えます。その粒度に関し
ても、法人レベルだけでなく、工場、倉庫、支店、営業所、個人顧客、また建
設業などでは、社長やその家族まで管理するニーズを持っています。物流はも
とより社内外を統一的に扱ってきましたが、SCMやM&A、持ち株会社化が
進む今日、営業、購買、経理、人事などでも社内と社外を統一的に扱うニーズ
が一般化しつつあります。その意味では、システムスコープの拡大とともに、
人と組織は社内外を問わず統一的に扱う方向に向かっているかに見えます。
しかし逆に、社員がたまたま1顧客であった場合、これを同一エンティティと考えず、
敢えて別エンティティとして冗長に管理した方が得策とする場合があります。
次に、商品やサービスについて。小売業や消費財製造業では、JANコード対
応の定型的商品を主体に扱いますが、包装や色、オプションなど、エンティテ
ィタイプとして形式化することの難しい場合も多々あります。生産財製造業や
建設業の商品は非定型であり、部品展開して構成仕様を規定したり、契約とし
て表現することになります。
一般に買い手よりも売り手/作り手の方がエンティティを細かい粒度で認識し
ます。たとえば、PCのユーザは同じ性能ならば、ハードディスクのメーカー
の違いは気にしませんが、作り手はこれを意識せざるを得ません。また、おそ
らく山田電気よりも、ソニーやパナソニックは細かく、また日本電産やTDK
は、さらにこれより細かく品物を見ていると思われます。逆に商品のスコープ
は山田電気が最大、日本電産やTDKが最小なのではないでしょうか。要する
に、広いスコープで粗く見る会社や、狭いスコープで細かく見る会社があり、
一律には行かないと言うことです。

■イベント系での配慮
受注、出荷、請求など、イベント系のエンティティは、Who、 Whom、 What、
When、 Where 、How などを表す参照KEY、および数量や金額などHowMuch
を表す数量データから成る、定型化の容易なエンティティが多いと言えますが、
生産や工事などの個性的な各工程を如何にタイプ化するかは、リソース系と同
様の難しさを持つと言えます。
またイベント系では、受注−引当における引当数量、出荷指図−出荷における
出荷数量のように、ステイタスの進行によって、属性値が確定してゆく場合、
エンティティタイプを如何に規定するか(THモデルにおけるサブストラクチャ)
の問題があります。

■IOサンプルに基ずく適度のタイプ化
このようにデータモデリングは、いろいろな関係者の認識するニーズに基づい
て、属性をエンティティタイプやサブタイプに分類することになりますが、粗
すぎれば役に立たず、逆に細かすぎれば、多くのユーザに過度の負担をかけ、
経済最適から離れます。サブタイプ識別のトリガーとして、ヌル値があります
が、単純にこれを撲滅する方針はサブタイプ過多となり得策でないケースが多
くなるようです。筆者が適度だと考えるのは、加工データに対する加工元データ
の異なるケースとか、例外的な属性が必要になるケースが明示できる程度、
と言うものです。これによってプログラムの分岐がデータモデル時点で明示さ
れ、データモデルの品質向上が実現できます。なおサブタイプは客観的に認識
できるはずですから、これを識別できる属性、たとえば顧客を識別する顧客
フラグ=1などを規定すべきです。
エンティティタイプに関するニーズの把握には、ヒアリングが多く用いられて
いますが、値の記述されたIOサンプルが、思い込みを防ぎ、実証的に進めら
れ、ベストだと考えます。いろいろなケースのIOサンプルをそろえるのは容
易ではありませんが、最終的にはテストケースを洗い出すとき活用できますの
で、決して無駄にならないはずと考えます。