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

2019.12.16 株式会社エクサ

リードエンジニアブログ『商品情報のデータモデル編』
第4話商品の関連を定義する

本記事では、商品情報の「データモデル」というテーマで進めています。前回、商品属性についてご紹介しました。今回は、商品属性の1つとして考えられる「関連」についてご紹介していきます。

「関連」は、「商品」と「画像」、「商品」と「ドキュメント」、「商品」と「商品」などの関係性を示すものです。これらの関係性を表す情報の持ち方にはいくつかのパターンがあります。今回はこれらのパターンをご紹介します。

片方向の関連パターン

商品から見るとその画像と関連しているかはわかりますが、画像から見るとどの商品と関連しているかはわからないという片方向の関連情報のみをもっているパターンです。

一方通行の片想いです。切ないです。

このパターンは1つの画像に関連付く商品が多い場合に適用されます。「標準規格のロゴ画像」などは、どの商品と関連付いているかということは意識しなくても良いため、この関連パターンが適用されます。

画像さんモテモテですね。

双方向の関連パターン

例えば商品と図面の関係のように、商品から見てどの図面と関連しているかが決まり、図面から見てもどの商品と関連しているかが決まるという関連パターンです。

こんどは両想いですね。

このパターンは例えば図面から関連している他の商品を導き出したいというニーズがある場合に適用します。商品が複数の図面(姿図、設計図、施工図、etc..)と関連を持ち、図面も複数の商品(シリーズものの別商品、etc..)と関連を持つという状態です。この場合でも「この商品に関する図面はこれらですよ」「この図面に関係する商品はこれらですよ」という提示ができるため、商品情報を参照する側の視点で利便性が高まります。

複数との関連を恋愛的に例えると凄いことになるので、双方向はこの辺で〆ます。

仲介を挟んだ関連パターン

セット商品と単品の関係の様に、間に仲介するモノが必要となる関連のパターンです。

世話焼きな親戚のおばさん＝仲介人ですかね。

仲介はどのセット商品と単品が関連付いていて、セット商品の中の単品が何個か、単品がセット商品の中の何番目に位置するかなどの情報を持ちます。セット商品は仲介を介して単品を参照し、単品も然りです。

ダイニングセットのテーブルと椅子の関係で考えると、単品のテーブルは1個で、椅子は4個くらいでしょうか。ただ、別のダイニングセットでは、もう少し小さなテーブルと椅子が2個という組み合わせもあります。この2個とか4個という情報は商品そのものの属性として管理するのではなく、仲介が管理します。

仲介は双方の商品情報を汚さずに関連を作ってくれる役割です。双方の商品からはいつでも仲介を呼び出せるので、あたかも自分の情報であるかのように扱えます。

商品の削除がある場合、この仲介も削除すべきかは一つの検討項目です。セット商品の例では、セット商品が削除される際に併せて削除するのが普通です。仲介だけが居なくなると、これらの商品の間の関係はなくなります。

つまりは破談です。

なお、データモデル上では「中間テーブル」などと表します。

番外編：希薄な関連パターン

関連するデータがPIMの中で管理されていない場合に、関連データのID情報だけを属性にセットしているという関連パターンです。この関連パターンは、片方向、双方向、仲介を挟んだ関連パターンで定義できず、また、絶対に削除しない、という前提がある場合のみ使います。この関連パターンでは関連先が削除されていてもシステム上は不整合を起こさないため、注意が必要です。

SNSでいつの間にか退会していた、みたいな状態ですね

いずれにしても、IDだけ知っているという希薄な関連です。

それがいいという人もいますが、これまでの経験上、結構いなくなりますよ