Prise en charge de recherche paramétrique

Une recherche paramétrique permet aux requêtes utilisant des critères multiples de circonscrire les résultats. Par exemple, tous les produits dont le nom commence par "Jouet", dont le prix est inférieur à 50 € et de couleur "bleue". WebSphere Commerce prend en charge les requêtes de recherche paramétrique sur schéma vertical et horizontal.

Dans la base de données, si les attributs de recherche sont stockés dans le schéma horizontal, chaque attribut distinct est stocké dans une colonne spécifique. Par exemple, les produits comportent une colonne PARTNUMBER. Par contre, s'ils sont stockés dans le schéma vertical, les colonnes ne sont pas spécifiques et des attributs différents peuvent être stockés dans chaque ligne. Par exemple, un produit peut avoir deux lignes d'attribut qui lui sont associées, couleur = bleu et taille = large.

Pour des performances optimales, les attributs sur lesquels peut porter une recherche doivent être stockés dans les tables de schéma horizontal. Ces tables peuvent inclure la table de base pour le stockage d'informations élémentaires sur le produit (comme son numéro de référence ou sa marque) ou des tables associées pour le stockage d'informations localisées comme des descriptions.

Remarque :
  • Les requêtes de recherche paramétrique doivent utiliser les requêtes à deux étapes.
  • Les requêtes de recherche paramétrique ne doivent pas spécifier d'instruction SQL paging_count.

Fonction search()

search() est une fonction spéciale faisant partie d'une HCL Commerce notation XPath étendue. Cette fonction peut être utilisée pour réduire le nombre de requêtes de recherche paramétrique qu'un développeur a besoin de créer.

Elle peut être placée dans une expression XPath dans le prédicat (la chaîne entre crochets dans l'exemple ci-dessous) du nom. L'argument de la fonction search(), avec le mappage entre les objets SDO du modèle logique et le schéma de base de données, est utilisé pour générer des fragments SQL qui sont injectés dans les modèles de requête de recherche paramétrique.

Remarque : La fonction de recherche prend également en charge les conditions 'et' et 'ou'. Cependant, 'et' et 'ou' ne peuvent pas être utilisés simultanément dans la fonction de recherche.
Dans l'exemple suivant, une expression XPath de recherche paramétrique recherche des produits dont la description abrégée contient la chaîne "Chemise Polo" et des numéros de référence commençant par "FU01" :
/CatalogEntry[search(contains(Description/ShortDescription, "Polo shirt") and starts-with(CatalogEntryIdentifier/ExternalIdentifier/PartNumber, "FU01"))]
Le mappage d'attributs pour l'entité logique CatalogEntry ci-dessous définit CATENTRY comme table de base et CATENTDESC comme table associée. Le mappage d'élément ‘Description/ShortDescription‘ (nom de propriété) est recherché dans les éléments ‘columns' de la table de base, CATENTRY. Si aucune correspondance n'est trouvée, la recherche est effectuée sur la table CATENTDESC associée.
<_config:mapping>
  <_config:key name="CatalogEntry"/>
   <_config:basetable name="CATENTRY" useAllColumns="false">
    <_config:columns name="PARTNUMBER" propertyName="CatalogEntryIdentifier/ExternalIdentifier/PartNumber"/>
    <_config:columns name="MFPARTNUMBER" propertyName="CatalogEntryAttribute/Attributes/mfPartNumber"/>
    <_config:columns name="MFNAME" propertyName="CatalogEntryAttribute/Attributes/mfName"/>

    <_config:associatedtable name="CATENTDESC" useAllColumns="false">
     <_config:columns name="NAME" propertyName="Description/Name"/>
     <_config:columns name="SHORTDESCRIPTION" propertyName="Description/ShortDescription"/>
     <_config:columns name="PUBLISHED" propertyName="Description/Attributes/published"/>
    </_config:associatedtable>
   </_config:basetable>
  </_config:mapping>
Le modèle XPath de modèle SQL avec une fonction search() est similaire à ceci :
BEGIN_XPATH_TO_SQL_STATEMENT
  name=/CatalogEntry[search()]
  base_table=CATENTRY
  sql=
    SELECT DISTINCT CATENTRY.$COLS:CATENTRY_ID$
  FROM
      CATENTRY, $ATTR_TBLS$
  WHERE      
    CATENTRY.MARKFORDELETE = 0 AND
    ( $ATTR_CNDS$ ) 
  ORDER BY
      CATENTRY.CATENTRY_ID 
END_XPATH_TO_SQL_STATEMENT
Dans l'instruction SQL générée ci-dessous, la variable $ATTR_TBLS$ est remplacée par la table associée contenant la colonne correspondant à la propriété ‘Description/ShortDescription' telle que définie dans le mappage ci-dessus. La variable $ATTR_CNDS$ est remplacée par la condition de jonction entre cette table et la table de base, et la condition à laquelle comparer la colonne ‘SHORTDESCRIPTION' par la valeur de description abrégée fournie en entrée. La condition pour la propriété ‘CatalogEntryIdentifier/ExternalIdentifier' correspondant à la colonne PARTNUMBER dans la table de base CATENTRY est également incluse.
SELECT DISTINCT CATENTRY.CATENTRY_ID
  FROM
      CATENTRY, CATENTDESC IBM_1
  WHERE      
    CATENTRY.MARKFORDELETE = 0 AND CATENTRY.PARTNUMBER LIKE 'FU01%' AND 
    (CATENTRY.CATENTRY_ID= IBM_1.CATENTRY_ID AND 
     IBM_1.SHORTDESCRIPTION LIKE '%Polo shirt%')
  ORDER BY
      CATENTRY.CATENTRY_ID
Remarque : La fonction search() peut uniquement se rapporter aux propriétés mappées aux colonnes de la table de base qui représentent l'objet entité logique ou aux colonnes des tables avec des relations de clé externe vers la table de base. Par exemple, la fonction search() utilisée dans le prédicat de l'élément 'Catalog' peut se rapporter à la propriété 'description' du catalogue. Cependant, elle ne doit pas se référer à la propriété description des entrées de catalogue. De plus, la fonction search() est limitée à un seul élément dans l'expression XPath. Seule la première occurrence de la fonction search() est prise en compte lors de la production de fragments SQL pour les recherches générées.

Configuration de la recherche paramétrique

Le fichier de configuration de composant, wc-component.xml, comporte une section pour la couche service de données. Celle-ci peut être divisée en trois sous-sections principales :
  • Informations de médiateur de données
  • Informations de contexte
  • Informations de mappage d'attributs
Cette configuration est décrite par l'élément <dataservice>. Un exemple de configuration figure dans l'échantillon XML ci-dessous :
<_config:dataservice dataMediatorType="JDBC" 
		metadataClass="com.ibm.commerce.catalog.facade.server.metadata.CatalogMetadata" 
		maximumPagingResultLimit="2000">
		<_config:context key="LANG_ID" 
					name="com.ibm.commerce.context.globalization.GlobalizationContext" 
					propertyName="languageId" defaultValue="-1"/>
     <_config:context key="CATALOG_ID" 
					name="com.ibm.commerce.catalog.businesscontext.CatalogContext" 
					propertyName="catalogID" defaultValue="-1"/>
     <_config:context key="OWNER_ID" 
					name="com.ibm.commerce.catalog.businesscontext.CatalogContext" 
					propertyName="ownerID" defaultValue="-1"/>
     <_config:context key="STORE_ID" 
					name="com.ibm.commerce.context.base.BaseContext" 
					propertyName="storeId" defaultValue="-1"/>


    <!-- Mapping for catentry search -->
    <_config:mapping>
      <_config:key name="CatalogEntry"/>
      <_config:basetable name="CATENTRY" useAllColumns="false">

        <_config:columns name="PARTNUMBER" propertyName="CatalogEntryIdentifier/ExternalIdentifier/PartNumber"/>
        <_config:columns name="MFPARTNUMBER" propertyName="CatalogEntryAttribute/Attributes/mfPartNumber"/>
        <_config:columns name="MFNAME" propertyName="CatalogEntryAttribute/Attributes/mfName"/>

        <_config:associatedtable name="CATENTDESC" useAllColumns="false">
          <_config:columns name="NAME" propertyName="Description/Name"/>
          <_config:columns name="SHORTDESCRIPTION" propertyName="Description/ShortDescription"/>
          <_config:columns name="PUBLISHED" propertyName="Description/Attributes/published"/>
        </_config:associatedtable>
      </_config:basetable>
  </_config:mapping>

      <!-- Mapping for catgroup search -->
    <_config:mapping>
         <_config:key name="CatalogGroup"/>
      <_config:basetable name="CATGROUP" useAllColumns="false">
        <_config:columns name="IDENTIFIER" propertyName="CatalogGroupIdentifier/ExternalIdentifier/GroupIdentifier"/>
               <_config:associatedtable name="CATGRPDESC" useAllColumns="false">
          <_config:columns name="NAME" propertyName="Description/Name"/>
                     <_config:columns name="SHORTDESCRIPTION" propertyName="Description/ShortDescription"/>
               </_config:associatedtable>
      </_config:basetable>
    </_config:mapping>
  </_config:dataservice>
La section du médiateur de données définit les informations suivantes :
  • Type de médiateur de données : seul JDBC est pris en charge.
  • Classe de métadonnées : nom complet de la classe de métadonnées fournissant les informations de métadonnées objet-relationnel. Cette classe doit constituer une sous-classe de com.ibm.commerce.dataservice.db.jdbc.ComponentMetadata
Ces définitions de contexte servent à extraire les données de contexte en phase d'exécution pour les substituer dans l'instruction SQL du modèle. La section des informations de contexte contient les éléments suivants :
  • Clé : identifiant unique représentant les informations de contexte. Cette clé est utilisée dans le fichier de modèle de requête comme chaîne de substitution.
  • Nom : Nom de contexte défini dans le service Contexte métier.
  • Nom de la propriété : identifie la propriété dans le contexte contenant les données. La classe d'implémentation du contexte doit avoir une méthode d'accès 'get' définie pour cette propriété.
  • Valeur par défaut : cette valeur est utilisée pour substitution dans l'instruction SQL du modèle si la valeur du contexte n'a pas été définie en phase d'exécution.

Mappage d'attributs

Un même objet logique a des propriétés stockées dans plusieurs tables physiques. La couche service de données prend en charge trois types différents de tables :
  1. Table de base : contient les données d'identification uniques du domaine. Chaque colonne doit représenter une propriété de l'objet logique (la table de base représentant généralement votre nom).
  2. Table associée : propriétés supplémentaires stockées dans une table distincte dans le cadre du schéma horizontal. Cette table dispose d'une relation de clé externe avec la table de base. Chaque colonne doit représenter une propriété de l'objet logique.
  3. Table de propriétés : propriétés supplémentaires stockées dans une table distincte dans le cadre du schéma vertical. Chaque ligne peut représenter une paire propriété/valeur de l'objet logique. Cette table dispose d'une relation de clé externe avec la table de base.
Un exemple de configuration de mappage d'attributs figure dans le code XML ci-dessous :
<_config:mapping>
  <_config:key name="CatalogEntry"/>
   <_config:basetable name="CATENTRY" useAllColumns="false">
    <_config:columns name="PARTNUMBER" propertyName="CatalogEntryIdentifier/ExternalIdentifier/PartNumber"/>
    <_config:columns name="MFPARTNUMBER" propertyName="CatalogEntryAttribute/Attributes/mfPartNumber"/>
    <_config:columns name="MFNAME" propertyName="CatalogEntryAttribute/Attributes/mfName"/>

  <_config:associatedtable name="CATENTDESC" useAllColumns="false">
     <_config:columns name="NAME" propertyName="Description/Name"/>
     <_config:columns name="SHORTDESCRIPTION" propertyName="Description/ShortDescription"/>
     <_config:columns name="PUBLISHED" propertyName="Description/Attributes/published"/>
	</_config:associatedtable>

    <_config:propertyTable name="CEPROPERTY">
		<_config:columns name="NAME" propertyName=".name."/>
		<_config:columns name="VALUE" propertyName=".value."/>
    </_config:propertyTable>

   </_config:basetable>
 </_config:mapping>

Chaque élément du mappage définit un mappage d'objet logique avec plusieurs tables physiques. L'élément clé identifie la propriété du modèle logique qui référence l'objet entité logique.

Element Attribut Description
basetable Identifie la table de base
nom Nom de la table
useAllColumn Indique si toutes les colonnes de la table sont utilisée pour la recherche paramétrique. Les valeurs de cet attribut sont les suivantes :
  • true - toutes les colonnes de la table sont utilisées. Le mappage de nom de propriété logique avec le nom de colonne se base sur les informations de métadonnées objet-relationnel sauf si elles sont explicitement remplacées par des sous-éléments de colonnes (décrit plus loin). L'attribut useAllColumn est facultatif. Cette valeur est celle par défaut si vous n'avez rien spécifié.
  • false - seules les colonnes identifiées dans les sous-éléments de colonnes sont prises en compte.
colonnes Sous-élément de table de base et table associée qui identifie les informations de colonne pour ces tables.
nom Nom de la colonne.
propertyname Nom de propriété XPath logique si elle a été spécifiée. Sinon, le nom de propriété définie pour cette colonne dans les métadonnées objet-relationnel est utilisé.
searchable Indique si la colonne est utilisée pour la recherche paramétrique.
caseSensitive Indique si les recherches doivent considérer la valeur de cette colonne comme sensible à la casse ou non.
  • true - le contenu de cette colonne est considéré être sensible à la casse. Il s'agit de la valeur par défaut.
  • false - la valeur de cette colonne n'est pas sensible à la casse. Lorsque l'attribut caseSensitive est défini à "false", la fonction UPPER() SQL est utilisée dans l'instruction SQL générée pour modifier la casse du contenu de la colonne. Les utilisateurs doivent prendre en compte l'impact sur les performances en cas d'utilisation de recherches non sensibles à la casse. L'utilisation de la fonction UPPER() entraînera un balayage complet de l'index ou même des tables. Si vous utilisez Oracle, il est recommandé d'utiliser un index basé fonction en vue d'améliorer les performances.
genmode Indique le mode de génération.
associatedtable Définit la table associée. Les attributs de cet élément sont identiques à ceux de l'élément basetable.
propertytable Définit la table de propriétés. Seul l'attribut 'name' est pris en charge.
columns Sous-élément de propertytable qui identifie les informations de colonne pour ces tables.
nom Nom de la colonne.
propertyname Nom de propriété du modèle logique.

Modes de génération

Lorsque les attributs de recherche sont connectés par un opérateur logique ‘or', un certain nombre d'options de génération de requête de recherche peuvent être sélectionnées via la configuration. Les différents modes de génération vous permettent d'affiner les performances des requêtes générées. Par exemple, dans le cas d'ensembles de données volumineux, la décomposition d'une requête de recherche unique en plusieurs requêtes et la combinaison du jeux de résultats à l'aide de l'opérateur UNION peut produire des performances optimales. Les modes de génération suivants peuvent être spécifiés à l'aide de l'attribut 'genmode' de l'élément 'columns' :
  • Mode UNION : une requête est générée pour chaque paramètre de recherche. Les résultats sont combinées à l'aide de l'opérateur SQL UNION. Par exemple :
    select distinct ce.id, ce.partnumber from catentry ce where ce.partnumber like 'FU01%'
union 
select distinct ce.catentry_id, ce.partnumber from catentry ce, catentdesc d where ce.catentry_id = d.catentry_id and d.shortdescription like '%shirt%'
  • Mode EXISTS : une requête unique est générée en utilisant la condition EXISTS. L'exemple précédent serait généré ainsi :
    select distinct ce.catentry_id, ce.partnumber from catentry ce where ce.partnumber like 'FU01%' or exists(select distinct * from catentdesc d where ce.catentry_id=d.catentry_id and d.shortdescription like '%shirt%')
  • Mode IN : une requête unique est générée en utilisant la condition IN. L'exemple précédent serait généré ainsi :
    select distinct ce.catentry_id, ce.partnumber from catentry ce where ce.partnumber like 'FU01%' or ce.catentry_id in   (select distinct d.catentry_id from catentdesc d where ce.catentry_id=d.catentry_id and d.shortdescription like '%shirt%')
Mode de génération Valeur de l'attribut 'genmode'
UNION 0
EXISTS 1
Indiana 2
Le mode UNION est celui par défaut. Il est utilisé si aucune configuration n'a été spécifiée. Il est également utilisé si au moins un des attributs de recherche a été configuré pour utilisation du mode UNION. Le mode EXISTS est utilisé si l'un des attributs de recherche a été configuré pour le mode EXISTS et aucun pour le mode UNION. Le mode IN est utilisé si tous les attributs de recherche ont été configurés pour son utilisation.

Remplacement du code SQL généré pour les requêtes de recherche paramétrique

Vous pouvez remplacer le code SQL généré pour les requêtes de recherche paramétrique. Par exemple, si une recherche paramétrique donnée ne fonctionne pas de manière satisfaisante, votre administrateur de base de données peut suggérer une autre manière de rédiger son code SQL. Dans ce cas, vous pouvez remplacer complètement le code SQL utilisé pour la requête de recherche paramétrique.

Pour remplacer le code SQL généré, il suffit de définir un nouveau bloc XPATH_TO_SQL_STATEMENT dans votre fichier de modèle personnalisé. Le nom de la requête doit correspondre au nom de la clé XPath, avec les paramètres de recherche spécifiés explicitement. Cette requête est utilisée au lieu de générer la requête SQL.

En suivant l'exemple utilisé plus haut dans cette section, le nom (et SQL de remplacement) correspondrait alors à ce qui suit :

BEGIN_XPATH_TO_SQL_STATEMENT 
name=/CatalogEntry[search(contains(Description/ShortDescription,) and starts-with(CatalogEntryIdentifier/ExternalIdentifier/PartNumber,))] 

base_table=CATENTRY 
sql= 
	SELECT DISTINCT CATENTRY.CATENTRY_ID 
	FROM 
		CATENTRY, CATENTDESC IBM_1 
	WHERE 
		CATENTRY.MARKFORDELETE = 0 AND CATENTRY.PARTNUMBER LIKE '?CatalogEntryIdentifier/ExternalIdentifier/PartNumber?%' AND 
			(CATENTRY.CATENTRY_ID= IBM_1.CATENTRY_ID AND 
			IBM_1.SHORTDESCRIPTION LIKE '%?Description/ShortDescription?%') 
		ORDER BY 
			CATENTRY.CATENTRY_ID 
END_XPATH_TO_SQL_STATEMENT