コレクションについて

Endeca Serverでは、コレクションは、一意のキー割当てに従ってソース・レコードが名前付きコレクションにパーティション化されてEndeca Serverにロードされる、データ・モデルを表します。

コレクションにより、特定のデータ・ドメイン内のデータを複数の編成されたグループ(Studioではデータセットと呼ばれる)に分割できます。そのため、すべてのレコードが単一のデータ・ドメインの索引内にある、レコードの複数のコレクションを含むEndeca Serverアプリケーションを構築できます。

コレクションには実際的な意味があります。ユーザーが検索する必要があるデータが、異なる複数の種類に及ぶことはよくあります(販売製品とハウツー記事、車両と保証クレーム、従業員変更の構造的HRレコードと満足度調査など)。これらの異なる種類のレコードは通常、互いに関連しており関係性がありますが、混在して表示されるとあまり有用ではありません。たとえば、UIの結果リストにおいて、一部の行には販売製品が、その他の行にはデータ・シートが表示されると有用ではありません。コレクションを使用すると、データ・ドメインごとにデータをロードして編成し、内部に論理グループを作成できます。

Endeca Serverアプリケーションではコレクションはオプションであることに注意してください。Endecaレコードは、コレクションのメンバーである必要はありませんが、この方法でデータ・モデルを表す場合はコレクションを使用できます。

使用例のサンプル

上位レベルからアプリケーションを見た場合、対話Webサービスは、単一のEndeca Serverデータ・ドメインにおいてデータの複数のコレクションに関するナレッジを保持しています。このことは、問合せ状態がコレクションごとに追跡され、ほとんどのコンテンツ要素(NavigationMenuやRecordListなど)を単一の焦点となるコレクションで操作できることを意味します。

例として、製品販売とオンライン・レビューを探索するためのアプリケーションについて考えてみます。レコードのコレクションとして、SalesとReviewsの2つがあるとします。アプリケーションでは、2つの異なるタブを使用します(Reviewsの探索用に1つ、Salesの探索用に1つ)。さらに、2つのタブ上には異なるフィルタがあるため、Salesレコードを製品説明のテキスト検索によって制限しながらReviewレコードを5つ星のレビューのみに絞り込むことが可能です。タブを切り替えても、単一のStateに両方の種類のレコードに対する個別の選択が含まれているため、両方の種類のレコードに対する選択は失われません。

各タブでは、問題になっているコレクションに関連するデータのみが表示されるため、Reviewsタブでは、Reviewsの限定に役立つ絞込みである値を含む使用可能な絞込みのメニューが表示されます(Salesレコードでのみ表示される属性は表示されません)。また、Salesレコードが混在していないReviewレコードのみのページを含むレコード・リストが表示されます。

クロス・フィルタリング

ReviewsレコードのナビゲートとSalesレコードのナビゲートを切り替える場合は、2つの間で一部のフィルタを保持できると便利であることがあります。たとえば、5つ星のReviewsのみの選択ではSalesをフィルタする必要はありませんが、他の属性は実際に共有可能である場合があります。たとえば、ユーザーJaneが、John Doeによって書かれたレビューのみが表示されるようにReviewsをフィルタした場合、Salesも同様にJohn Doeによる購入のみに自動的に絞り込まれると便利である可能性があります。Endeca Serverでは、フィルタ・ルールによりこのようなクロス・フィルタリング・シナリオがサポートされています。詳細は、「フィルタ・ルール」を参照してください。

フィルタ・ルールを使用すると、ReviewsレコードのReviewer属性をSalesレコードのBuyer属性と結び付けることができます。フィルタによって属性の1つで絞込みと選択を行うと、他の属性で暗黙的に追加の選択が行われます。つまり、ReviewsタブでJohn Doeによって書かれたReviewsのみに絞り込んだ後、Salesビューに切り替えると、SalesブレッドクラムにもBuyer=John Doeの選択が自動的に追加されます。このように、複数のコレクションに対するクロス・フィルタリングを使用することで、複数のデータセットにまたがる探索という重要なバリュー・プロポジションをEndecaアプリケーションで提供できます。