データモデル・ノウハウ ~商品情報データモデル~

2019.12.16  株式会社エクサ

リードエンジニアブログ 『商品情報のデータモデル編』
第5話 データモデル・ノウハウ

本記事では、商品情報の「データモデル」というテーマで進めています。前回までに商品の「単位」「属性」「関連」についてご紹介しました。今回は、最終話として、データモデルに関するノウハウをご紹介したいと思います。


データモデルの図を具体的にどう作るか

PIMのデータモデルは、データベースの物理的なモデルよりもより概念的なものになります。技術的には、UMLのクラス図のような構造で表現するのが理想的です。これにはいくつかの理由があります。

PIM製品が標準で持つデータ構造はデータモデルに反映しなくても良い

PIM製品すべてに共通して言えることですが、PIMの中の商品情報の構造はデータベースの構造よりもJavaのオブジェクトに近いものになります。これは、データベースのテーブルのカラムに定義できる要素がプリミティブな形式になるのに対して、PIMでは様々な型の形式を属性として扱えるという違いと考えてください。例えば商品とメーカーの関係を例にすると、データベースであればメーカーマスターがあって、メーカーコードを商品の属性にセットするという考え方になりますが、PIMのデータモデルを考える場合には、「メーカー型」の属性を定義するようなイメージになります。

当然、PIM製品の内部的にはこの「メーカー型」をメーカーコード、メーカー名、有効フラグ・・・のような属性に分解し汎用的に格納可能な形式にしているのですが、このあたりの内情はデータモデルに表現する必要はありません。

関連のパターンに「多対多」があっても中間テーブルは必要ない

データベースのテーブル間の関連では、多対多の関係は間に中間テーブルを設けて1対多にするような配慮が必要ですが、PIMのデータモデルでは意識しなくても大丈夫です。

PIM製品の内部では中間テーブルで管理していますが、これもデータモデルを検討する際には意識する必要はありません。

継承関係を表現できる

データベースのデータモデルではER図などを使いますが、PIM製品は商品情報を階層的に拡張する仕組みがあるため、Javaの継承関係のような表現が便利です。

例えば、「商品」→「標準品」「特注品」「セット品」「ソフトウェア」と分ける場合、商品として共通の属性は「商品」に持ち、そこから派生するデータモデルに個々で必要な属性を定義します。


about-datamodel.png

極論としてER図でも表現できなくはないのですが、結果的にPIM製品が内部で持つ構造も意識せざるを得なくなるため、図が複雑になり、構造の矛盾に気付きにくくなります。

そのため、個人的にはUMLのクラス図で表現するのがおすすめです。


時系列で考える

データの追加・更新・削除のライフサイクルを考えておく必要があります。

具体的には以下のような観点で検討しましょう。


登録

  • 最小限でどこまで属性が揃っていたら登録できるか
  • 発売日、公開日などの日付の情報と、登録タイミングに関係性があるか
  • 同時に、または先行し登録しておかなければならないデータはないか

更新

  • 1商品の属性の中で、更新できる・できない属性はどれか (コードは更新できない、など)
  • 商品を更新することで自動的に反映が必要な属性はないか (公開フラグ、承認ステータス、など)
  • 商品の更新に伴って反映が必要な他のデータはないか (画像との関連、セット品構成、など)

削除

  • 物理削除しても良いか、論理削除にすべきか
  • 削除に際してチェックすべき状態はないか (他データとの関連、など)
  • 削除してはいけない状態はないか (注文済みの場合は注文データとの関係性、公開から数年間の監査用途、など)

think-in-time-series.png

データの追加・更新・削除に伴う外部システムへのデータ連携なども、データモデルを考える上で重要です。例えば物理削除する場合は、外部システムに削除したことを連携しないと、先方のシステムで残ってしまいます。CRUD図や状態遷移図で整理するとわかりやすいかもしれません。場合によっては商品情報に状態を示す属性が必要になったり、外部連携の際の判定条件に使う属性が必要になったりします。

変化・拡張への柔軟性を持っておく

最初に一度定義したデータモデルで、将来的に変更もなく使い続けていくことはまずあり得ません。そのため、データモデルを定義するにあたっては、ある程度の将来性を見越した「余白」を考えておくことも重要です。例えば、商品の区分は「標準品/特注品」の2種だけで良いのか、将来は増えないのか、図面は商品だけじゃなくてシリーズにも紐づかないか?などまでを見越した定義を考える、ということです。

ただし、データモデルに柔軟性を持たせておくと、先々の変更・拡張が容易になるという点がありますが、初期のデータモデルの検討の複雑さは高くなります。汎化しすぎも特化しすぎも良くないので、柔軟性についての「さじ加減」は難しいと思いますが、PIM製品では、後から属性や関連を追加・更新・削除できますし、部分的な更新や、一括置換のような仕組みを持っているケースもありますので、そのあたりの機能性を確認しておくと良いと思います。

外部システムとの連携単位を確認しておく

PIMの一般的な連携パターンは、マスタデータを取り込み、PIMで加工して、Webサイトや他システムなどに連携するというフローです。その際に一度に連携するデータ件数、単位を確認しておかないと、差分の連携に時間がかかったり、連携先のシステムでの加工処理に手間がかかったりします。外部システムとの連携は、ケースバイケースなので、一概にこうすべきという提案が難しいのですが、連携の頻度やデータ件数を考えた上で、最適な連携単位を決めておくことでそれをデータモデルに反映することもできます。例えば、ECで更新頻度の高いプロモーション情報は、商品とプロモーション情報を1:nで関連する別のデータモデルとしておき、プロモーション情報の更新だけを反映する、などの方式です。

受け取り側のシステムの構造にも依存するため、全てのシステムで実現できるわけではありませんが、システム間の連携を効率化することで、情報の更新を上げることができ、結果、常にフレッシュな情報を顧客に提供できるなどのメリットがあります。

初期は何回か空にして登録しなおす覚悟も

いざデータを投入してみると、『データモデル通りじゃなかったぁ~』ということはよくあります。一発ですべてうまくいったとしたら、それはもうPIMの神様の領域かもしれません。このような場合は、PIMのデータを一度空にして、データモデルを見直して再チャレンジするしかありません。水路を掘って、水を流してみて、調整していくような作業ですね。



本シリーズでは商品情報のデータモデルについてご紹介してきました。ご一読いただいた皆様に少しでもヒントになる内容があれば幸いです。

しかし、実際取り組んでみると結構大変ですし、『こっちを埋めたらあっちから出てきた』のモグラ叩き状態が続くということも当然あります。後回しにしても良い課題と、解決しておかなければならない課題を見極めて、どのモグラは大丈夫かがわかれば、ハンマーの振りすぎで腕が筋肉痛になることはないかもしれないですね。



当社ではPIM導入の初期の検討段階から、整理の進め方なども含めてご協力できますので、お気軽にご相談ください。

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






[Blog][Footer]【PIMコラム】商品情報管理(PIM)の必要性から プロジェクト成功の秘訣まで

RECENT POST「PIM」


データモデル・ノウハウ ~商品情報データモデル~