商品分類パターン

商品はさまざまな分類に分類して管理していきます。商品の分類を管理する方法としては、いくつか存在します。以下に商品を分類するための考え方（のパターン）を説明していきます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【属性による分類】
最も簡単な方法は、商品エンティティに”商品タイプ”とか”商品カテゴリ”といった分類を行うための属性をもたせる方法です。

（図１）商品分類を属性で管理

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

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

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

（図２）サブタイプによる分類管理

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

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【分類エンティティとの参照リレーションによる分類】
商品をどのようなカテゴリーで分類するのかを“商品タイプ”エンティティで管理していきます。例えば、事務用品の製造を行っているといった場合、商品の種類からは「黒板・掲示板」「パーティション」「収納システム」「周辺用品」といったタイプに分類できます。
さらに、「黒板・掲示板」は「コピー黒板（感熱紙）」「コピー黒板（普通紙）」「ミーティング用ボード」「掲示板」というように細分化して管理していきます。

（図３）商品タイプの構造

このようなケースでよく行われるのが、分類を「大分類」「中分類」「小分類」というように、各階層に対応したエンティティを作成し、その間で従属関係を定義するケースです。

（図４）商品分類を階層で管理

これはこれで、上記の構造を正確に表現しているのですが、分類を変更したいといった場合には少し問題が残ります。

たとえば、上位階層の商品分類コードを変更すると、下位の商品分類コード（識別子）も変更する必要が出てきます。

また、下位の商品分類コードを別の上位の商品分類の下に移動させたいといった場合にも、商品分類コード（識別子）の変更を行う必要がでてくる可能性があります。

本来は正規化していなければならないと思いますが、実際にはトランザクション側にも商品コードを持つと同時に商品分類コードを持つことがあります。

このようなケースでは、商品分類コードが変更されると、マスタの商品分類コードだけを変更すっればいいということにはなりません。
トランザクション側で参照されている商品分類コードも変更する必要があります。

そこで、商品をどのようなカテゴリーで分類するのかを“商品タイプ”エンティティで管理していきます。

「商品大分類」「商品中分類」「商品小分類」という分類も、現時点での商品分類の考え方で、もしかすると、さらに階層を増やして管理していきたいということも出てくるかもしれません。

しかし、「商品大分類」も「商品中分類」も「商品小分類」も、あるいは「他の分類」も商品を分類するための情報ということで考えれば同じではないでしょうか。
そこで、商品分類に関するエンティティを階層的に定義するのではなく、”商品分類タイプ”ということでまとめます。

商品分類タイプ間の関係については、自己参照関係を定義することにより管理します。

<<自己参照の関連説明>>


（図５）商品タイプのテーブルイメージ

このような構造にしておくと、新たに分類したい商品タイプとして”重点商品”という区分が出てきたとしても、テーブルにレコードを追加することによって、対応することが可能となります。

ただし、この構造では”商品”からみて”商品タイプ”は１つだけということになりますので、ある商品が「重点商品」でもあり、「黒板・掲示板」でもあるという定義を行うことはできません。

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【分類エンティティとの間の中間エンティティによる管理】
通常商品は様々な観点で分類されます。例えば、製造ラインや製造モデルあるいはグレードや商品分野といった分類です。

商品を商品の種類からだけ分類するのではなく、別の観点（例えば、製造工場や製造国）でも分類したいといった場合、”商品”エンティティと”商品タイプ”エンティティの間に１対Ｎの参照関係を定義するだけでは管理することができません。

商品から見て商品タイプが複数存在しますので、”商品タイプ”と”商品”との間にＮ対Ｍの関係が存在することになります。
そこで、中間（関連）エンティティとして“商品分類”を追加し分類を管理します。

（図６）商品分類のテーブルイメージ

“商品タイプ”では分類の選択肢を管理し、商品がどのような分類に分類されるのかは、“商品分類”エンティティで管理します。

このような構造にしておけば、商品の分類を追加したいといった場合でも、テーブルや属性を追加したりすることなく、新たに管理したい分類を定義することができます。

例えば、商品の分類として「価格帯」を管理する必要が発生したとします。
その場合は“商品分類タイプ”に「価格帯区分」を登録します。

さらに、“商品分区分”に価格帯の内容である「0～10,000」「10,001～100,000」「100,001～500,000」という選択肢を登録し、“商品分類”で各商品に対して、どのような「価格帯区分」なのかを対応付けていくことにより、新たな商品分類を追加することができます。

（図７）商品分類の追加イメージ

また、商品タイプを組み合わせてあらたな商品タイプを作成するということが考えられます。例えば、「グレードがＨ（高）の黒板・掲示板」といったタイプに分類したいといった場合、商品タイプと商品タイプとの間に関連が存在することになります。
グレードの商品タイプ（Ｈ（高）Ｍ（中）Ｌ（低））は、各商品の種類毎に存在しますし、ハイクオリティに部類される商品も複数存在しますので、“商品タイプ”間に多対多の関係が存在することになります。そこで、中間エンティティとして“商品タイプ構成”を追加し商品タイプの組み合せで新たに商品タイプを作成可能としています。

（図８）商品タイプ構成のテーブルイメージ

<<中間（関連）エンティティの関連説明>>

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

（図９）商品分類の各種パターン

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