Connect製品データモデル

Connect製品データモデルのアーキテクチャの根拠は以下の通りです。

• 特定されたエンドユーザーシナリオを満たす製品データモデルを持つこと。
• 外部商取引システム(ECS)に関わらず、単一の共通製品データモデルを持つこと。
• 異なるソリューションで同じモデルを使い、ソリューション開発者にとってより簡単にすることです。
• 外部のコマースシステム間でデータモデルが同じに保たれるため、UIコンポーネント開発者にとって構築・保守が容易なコンポーネントを持つこと。

製品データは複雑であり、ConnectではSitecore内の単一の製品と単一のアイテムと一対一のマッピングがありません。これはECS内の製品データが単一のSQLテーブルに保存されないのと同じです。

!注単一の製品のデータには複数のSitecore項目が含まれます。CMS項目と混同しないように、本文書およびConnectではそれらをentitiesと称しています。

Connectでは、製品データモデルは以下を目的として設計されています:

• 典型的なeコマースシナリオのためのしっかりとした基盤を提供します。

  商品データをSitecoreに取り込む主な理由は、それを補強し、メディア、ウェブ、モバイル、印刷など異なるショップやチャネルで提示することです。

  製品データは正規化され、有効性を確保し、構築やシナリオの実現を可能にする堅固な基盤を提供しなければなりません。

  製品のデータは複合構造として格納されます。ID、名前、説明、タイプなどの共有ジェネリックフィールドのみを持つ製品テンプレートに基づくメインコンテンツ項目があります。製品項目の下には仕様、関係、リソースを含むサブツリー構造があります。さらに、製品がリンクする複数の関連リポジトリ(メーカー、製品タイプなど)もあります。

• 冗長な製品データを避ける

  冗長なデータが多すぎる(例えば、単一の製品すべてのデータを1つのSitecoreアイテムに格納するなど)すると、Sitecore内で手動でデータを同期・更新する必要があり、その維持が難しくなります。

  代わりに、メーカー情報、部門、仕様などの共有データのために別々のリポジトリが使用され、リンクによって参照されます。これは、正規化された製品データがSQLデータベースの別々のテーブルに保存され、外部キーで参照される方法に似ています。

• 製品データの同期を最小限に抑える

  冗長なデータを避けることで、同期すべきデータ量を最小限に抑えます。また、すべての製品データがECSから必要というわけではありません。以下のセクションで説明するシナリオを満たすために必要な製品データのみが同期され、Sitecoreに保存されます。

• 典型的なカスタムモデル実装の問題を避ける

製品を複合製品構造に分割し、別々のリポジトリにデータを配置することで、最も一般的な実装問題を回避できます。例えば:

• フラットモデル

  フラットモデルでは、単一のアイテムが製品を表します。複数のアイテムを組み合わせて製品データを構成する場合、モデルは次のようになります。

  • シンプルに、必要な情報を多く見逃してしまうこと。
  • 未使用のフィールドを多く持つか、さまざまな製品タイプをカバーするために多数のテンプレートを使うこと。どちらもベストプラクティスではありません。
  • 類似製品やバリアントの冗長なデータをたくさん持っておきましょう。
  • データをカスタムフィールドタイプに強制的に組み込んだり、カスタムスキームでデータをエンコードしたりできます。

• 冗長データ

  共有情報を保存するための別リポジトリがなければ、冗長な情報は避けられません。

• テンプレートが多すぎる

  製品ごとに別々のテンプレートを使うのは、多数の異なる製品があるとすぐに管理が難しくなります。

• 延長が難しい

  製品に単一のアイテムがあり、複数のアイテムを組み合わせて製品データを構成する場合、カスタムデータでの拡張は困難になります。

• 冗長データのコンテンツ編集は時間がかかります

CMS 7の新機能を活用することで、バケットやLinqベースの検索をカスタム製品インデックスに対して利用し、新しいHydrationモデルを通じて製品オブジェクトを返すことが可能になります。HydrationモデルはNHydrateやNhibernateに似ています。詳細は最新バージョンのSitecoreデータ定義APIクックブックをご覧ください。

人工的に製品データを単一のアイテムに強制するのではなく、ECSとの統合、カスタマイズ、拡張が容易になる複合構造でより自然な形で保存されます。