商品の属性を定義する ～商品情報データモデル～

「商品」を特定する属性を検討しましょう

お客様の「商品」を特定する属性として、「商品コード」「商品名」「JANコード」などがあります。この中で「1つの商品」を一意に示す情報があれば、それが「ユニークキー」となる属性です。PIMで管理する「商品」を一意に示す情報は、属性情報として一番重要になります。

一般的には「商品コード」がユニークキーになるのですが、場合によっては「商品コード」だけだと「製品コード(製造時のユニークキー)」違いで重複していたり、「商品コード」を持たない商品もあったりします。例えば「説明書は有料で、1商品として取り扱う」と定義した場合、説明書には「商品コード」がなく、別の属性「ドキュメントID」になっているかもしれません。

また、1つの属性だけでは一意にならないケースもあります。その場合はデータベースで言うところの「複合主キー」のように扱うことができます。データベースの世界ではあまり推奨されませんが、PIMの世界では複合主キーでもOKだと思っています。

PIM製品の仕組みの話となりますが、PIM製品では各商品情報を内部的に発行するユニークキーで管理しています。このユニークキーは連番やハッシュ値で生成され、PIM利用者が見てもどの商品か判断できるものではなく、あくまでもPIM製品の内部値としての位置づけとなります。PIM製品としてはこのキーがあるために商品コードが同じ商品であっても登録・管理できるという仕様になっています。ただし、商品情報を取り込んだり、参照したり、外部に出力する際には、利用者が指定できる値で一意性を示せないとデータ操作が困難になります。そのため、たとえ複数の属性の値であっても一意性を示せるようにする必要があると考えます。

極端な例として、「商品コード」＋「商品名」で一意になるのであれば、「商品名」のような全角文字を含む属性値でもユニークキーにしてしまって問題ありません。(ただし、外部システムとの連携で影響がでないかを意識する必要はあります)

時には、PIM導入をするにあたり、初めてお客様側で新規に判別可能なユニークキーを定義する必要がでてくることもあります。その場合、「自動採番」を安易に選択しないことをお勧めしています。例えば、テスト環境と本番環境に同じデータを登録したとしても、自動採番を採用したケースではデータの内容が異なることになってしまうため、正しい比較ができないなどの弊害がでてしまうからです。

このように、「商品」が漏れなく一意になるかという点を確認しておくことで、以降のデータモデリングが効率的に進みます。同様に、画像やドキュメント、図面についてもユニークキーを確認しておきましょう。

過去の事例として実際にあったお話しを２つほど。

お客様と商品のユニークキーを決めていく中で、認識として一意であると考えていた「コード」が実は社内で他の部署に確認したら一意じゃなかった、ということがありました。『え！？じゃあ、あっちのシステムはどうやって連携してるの？』という議論に発展していき、セッションが予定通り終わらないということが結構ありました。

また、商品にソフトウェアを含めようとしたところ、『ソフトウェアのコードと商品のコードが被っている！！』ということもありました。こういうケースが後から出てくるとデータモデルへの影響も大きく、困ってしまいますね。

「商品」を伝える属性を検討しましょう

次に、「商品」には、「仕様」や「特長」など、商品を正しく伝えるための属性があります。これらの属性を商品一つ一つで定義していくのですが、PIM活用により、この部分の効率化が可能となっています。

Tシャツを例にすると、伝える属性には「素材」「ブランド」「原産国」「価格」「サイズ」「カラー」「説明文」などが思い浮かぶと思います。ここで、無地のTシャツシリーズに「赤Tシャツ」「青Tシャツ」という別の商品があった場合を想定します。これらの商品では「サイズ」「カラー」はそれぞれ別の値(S、M、L、XL、赤、青など)を持ちますが、 それ以外の「素材」「ブランド」「原産国」「価格」「説明文」は同じ値をもつことになります。 この同じ値を持つ属性は商品毎に値を持つよりは共通化したいですよね。

PIM製品には、このような共通化できる属性の実現方法がいくつか提供されています。PIM製品の仕様・特性を理解し、データモデル検討の際に考慮することで、商品情報の整理が非常に効率的になります。

また、商品によって定義する属性そのものが異なるケースもあります。衣料品と電化製品では、商品を伝えるために必要な「仕様」や「特長」は異なりますし、一般的に提示すべき「環境情報」や「規格情報」も違います。もっと細かく言うと、電化製品の中でも洗濯機とテレビでは持つべき属性が違ってきますよね！

PIM製品では、こういった属性そのものが異なる商品を統合的に管理するために、商品カテゴリーや分類によって定義・編集可能な属性を切り替える仕組みを持っています。「メーカー」「電圧」「幅」「高さ」「奥行」「重さ」などの電化製品全体で共通の属性、「解像度」「パネル」「端子」などのテレビ・モニターで共通の属性、「チューナー」などテレビで共通の属性など、商品を階層的に展開していく中で、必要な属性を追加していくことができます。データモデルを検討する上では、この商品の体系と属性の整理が重要なポイントとなります。

さらには、「属性」を検討する上で重要なのが「データ型」や「必須」「サイズ」などの属性ごとの特性です。良くあるケースとしては、商品ごとに「サイズ」がW×H×D、H×D×Wなどで表記が異なっていたり、重さがgとkgで単位が異なっていたり、場合によっては重さが「約 2 kg」などの文字列として定義されている場合もあります。重さが数値じゃなければならないという決まりはないのですが、今の値が文字列だからという理由だけで安易に文字列型の属性にしてしまうと、将来的に、重さで絞り込んで探したい、重さと売り上げなど他の数値との相関性を見たい、といったニーズの実現難易度が上がってしまいます。

その他、「データ型」の中には、Enum型(列挙型)というのもあります (在庫ステータスの「在庫あり」「在庫なし」「在庫管理対象外」などの選択肢型)。こういった型の属性の選択肢をどう定義し、管理していくかというのも一つのテーマとなります。

「商品」をコントロールする属性を検討しましょう

最後に、「EC販売可否」「Web公開開始日」など商品情報のライフサイクルをコントロールするための属性を検討します。これらの属性の値に従って、ECやCMSへの連携を制御したり、各システム側での表示制御に利用したりします。属性の定義方式としては、商品個々に属性として持たせる方式や属性値ではなくデータの関連としてあらわす方式などがあります。それぞれにメリット・デメリットがあるので詳細を確認して最終的に決定する必要がありますが、導入プロジェクト序盤で連携の対象・タイミングを考えていく中で、属性の要否だけでも検討しておくことをお勧めしています。

また、商品情報を検討する中で、これらの属性をどこで管理するかという議論も必ず出てきます。PIMは商品情報を管理するものだからコントロール情報は他で管理すべきだとか、商品にまつわる情報は全てPIMに集めるべきだという意見もありますが、どちらが正しいとは言えないと思います。運用する際に担当者が1つのシステムで業務を完結できるのであれば、どちらの方法でも問題ないのですが、個々のシステムを個別に操作する運用になってしまうようであれば、使いづらい上に人的ミスの要因にもなります。これら実運用を踏まえ、また、PIMの将来的な拡張や発展も考慮し、コントロール情報と商品そのものの情報との依存関係が高くならないよう柔軟にデータモデルを検討していくことをお勧めします。

まとめ

以上、3つの属性パターンの検討についてご紹介しました。

前回、「商品」という単位を決定し、周辺の情報を整理・検討しました。その後、今回お話しした属性、特に「商品」を特定するユニークキーの整理については、事前に検討した商品単位に無理がないかなどを振り返って確認することに繋がります。

また、「似たような属性」「同じ意味の属性」を適切な粒度で整理できるかというのも重要です。属性を徹底的に集約してしまうと、逆に外部連携などで問題になるケースもあるため、さじ加減が大切です。似たような属性が多いとどの値が正しいのかわからなくなったり、編集する際に抜け漏れがでたりする危険性もあるため、運用のし易さも含めて検討していく必要があります。

個々の属性の定義については地味で手間のかかるプロセスです。量が多いのですが、ここで頑張って整理しきることができればこの先が楽になります。PIM製品はデータモデルの柔軟性が高いため、プロジェクト序盤で完全に属性を整理し定義しきる必要はないのですが、大まかな内容を整理しておくことでデータモデル全体の構造矛盾の検知や最適化ができるようになります。

今回はここまでです。

次回は他の商品情報や画像・図面などとの「関連」についてご紹介します。

PIMについてすぐ知りたい！という方はこちら↓をクリック