取引先分類パターン

取引先はさまざまな分類に分類して管理することが一般的だと思いますが、取引先の分類を管理する方法としては、いくつか存在します。以下に取引先を分類するための考え方（のパターン）を説明していきます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【属性による分類】
最も簡単な方法は、取引先エンティティに”取引先区分”とか”業種区分”といった分類を行うための属性をもたせる方法です。

（図１）属性による分類の管理

このように属性として取引先を分類を識別するための項目を持たせる場合は、次のことが前提となります。
・予め取引先をどのように分類するのかがわかっている。
・分類するための属性項目は変わらない。

もしも、必要な取引先の分類が増えた場合は、必要な属性を追加しなければなりません。（テーブルにカラムを追加する必要があります。）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【サブタイプ化による分類】
取引先の種類（分類）ごとにサブタイプ化するというやりかたがあります。

（図２）サブタイプ化による取引先の管理

顧客の重要度という観点から“既存客”“潜在顧客”“重点顧客”というサブタイプに特化していくことも考えられますし、どのようなパートナーなのか協業内容に注目して“販売パートナー”“技術パートナー”といったサブタイプとして定義するということも考えられます。

単に取引先の属性区分として管理すればいいのか、それともエンティティとして独立させるべきなのかという問題は、独自の属性を管理する必要があるかどうかで判断すればいいでしょう。
例えば、“販売パートナー”の属性としてのみ「仕切率」が必要であるといった場合は、“販売パートナー”というエンティティを独立させ、“取引先”のサブタイプとして定義するようにします。

この場合では、必要な取引先の分類が増えた場合は、必要となる取引先（分類）に対するサブタイプエンティティを追加していきます。（テーブルを追加する必要があります。）

<<サブタイプの関連説明>>
<<サブタイプの関連説明（その２）>>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【分類エンティティとの参照リレーションによる分類】
取引先の分類が増えることがある（ユーザによる追加を考慮する必要がある）場合は、“取引先区分”を別エンティティとして独立させ、下記のような参照関連を定義しておくことにより取引先の分類を管理します。

（図３）取引先区分のテーブルイメージ

取引先をどのようなカテゴリーで分類するのかを“取引先区分”エンティティで管理していきます。

このような構造にしておくと、新たに分類したい取引区分として”ＳＩパートナー”という区分が出てきたとしても、テーブルにレコードを追加することによって、対応することが可能となります。

ただし、この構造では”取引先”からみて”取引先区分”は１つだけということになりますので、ある取引先（企業）が販売パートナーでもあり、技術パートナーでもあるという定義を行うことはできません。

<<参照関係の関連説明>>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【分類エンティティとの間の中間エンティティによる管理】
取引先は、さまざまな分類に分類分けされることがあります。

例えば、取引先の業種や重要度を管理したいといった場合、ある取引先の業種は製造業であり、重点顧客であるという事象が発生します。

このような場合、各分類を行うための“＊＊区分マスタ”を設けて、取引先との間に関連を定義しておくということが考えられます。

（図４）取引先を複数の観点から分類するケース

しかし、このようなモデルにしてしまうと、分類分けしたい分類が増えた場合どうなるでしょうか。

新たに分類用のテーブルをその都度追加作成して、各取引先と関連を追加する必要があります。

分類分けしたい分類が増えても、新たに分類用の“＊＊区分マスタ”を追加したり関連を追加したりすることなく、分類を追加したり変更したりするためにはどうすればいいでしょうか。

このようなことを可能とするために、分類分けを「どのような分類を行うのか」と「その分類の中ではどのような選択肢があるのか」という観点から考えていきます。

どのような分類の種類があり、その分類の選択肢としてはどのような選択肢があるのかを管理し、各取引先毎に関連付ければ、上記の問題は解決します。

（図５）取引先分類のパターン

ある取引先は”重点顧客”であり”製造業”であるということが当然あります。

ということは、取引先が分類される取引先区分は複数存在することになります。

また、ある取引先区分に分類される取引先も複数存在するはずであるから、”取引先”と”取引先区分”はＮ対Ｍ関係にあります。
そこで、”取引先”の区分を管理するために、中間（関連）エンティティとして”取引先分類”を追加し、各取引先で複数の取引先区分の設定ができるようにします。

（図６）取引先分類のテーブルイメージ

各取引先を分類分けする種類（顧客区分、業種区分等を“取引先分類タイプ”で管理するようにします。

また、“取引先区分”では分類の選択肢を管理しています。

そして、分類の選択肢自身も階層関係を持っているので、選択肢の階層関係を自己参照（再帰リレーション）を定義することにより管理しています。

取引先がどのような分類に分類されるのかは、“取引先分類”エンティティで管理します。

このパターンを適用することにより、取引先の分類を追加したいといった場合でも、テーブルや属性を追加したりすることなく、新たに管理したい分類を定義することができます。

例えば、取引先の分類として「従業員規模区分」を管理する必要が発生したとします。
その場合は“取引先分類タイプ”に「従業員規模区分」を登録します。

さらに、“取引先分区分”に従業員規模区分の内容である「１～100名」「101名～3,000名」「3,001名以上」という選択肢を登録し、“取引先分類”で各取引先に対して、どのような「従業員規模区分」なのかを対応付けていくことにより、新たな取引先分類を追加することができます。

（図７）取引先分類の追加イメージ

<<自己参照の関連説明>>
<<中間（関連）エンティティの関連説明>>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【取引先分類パターンの整理】
取引先を分類するためのパターンとして、以下のパターンが存在します。

（図８）取引先分類の各種パターン

①属性による分類
取引先を分類分けする区分が予め決められており、変化しないという場合には“取引先”エンティティの属性として「取引先区分（分類）」を持たせます。
②サブタイプによる分類
取引先のタイプよって管理すべき属性が異なる場合には、サブタイプを定義し、各サブタイプにのみ必要な属性を持つようにします。
③分類エンティティとのリレーションによる分類
取引先の区分が追加されることが予想される場合は、“取引先区分”エンティティを追加し参照リレーションを定義しておきます。
④分類エンティティとの中間（関連）エンティティによる分類
取引先が複数の取引先区分に分類できるとした場合は、“取引先”と“取引先区分”との間にＮ対Ｍ関係が存在することになりますので、中間（関連）エンティティを追加し管理します。