Documentation SDX-2 Télécharger Installer Présentation Configuration Base de documents Entrepôt Indexation Recherche OAI Javadoc Référence API-XSP Migration Schemas Performances | # Configuration d'une base de documents Les bases de documents sont l'une des composantes des applications SDX 2. L'élément `<sdx:documentBases>` du fichier `application.xconf` contient les informations qui définissent les bases de documents d'une application ; nous allons expliquer ici quelles sont les informations de configuration associées à cet élément. Il est à noter que la configuration d'une application SDX doit également contenir un élément `<sdx:userDocumentBase>` qui a exactement la même structure que l'élément `<sdx:documentBase>` dont il sera principalement question ici. Ainsi, toutes les informations de ce document peuvent également s'appliquer à l'élément `<sdx:userDoucmentBase>`. Ce dernier permet de configurer la base de documents spéciale qui gère les utilisateurs associés à l'application. Cette base de documents est spéciale à cause du rôle spécifique qu'elle joue pour l'application, mais en fait elle peut également être utilisée de la même manière que toute base de documents, ce qui implique notamment qu'elle peut être utilisée en recherche. L'architectude de SDX a été conçue de manière à ce que la notion de base de documents soit relativement générique, même si pour l'instant un seul type de base de documents peut être défini, soir les bases de documents Lucene. Si jamais d'autres moteurs de recherche sont interfacés avec SDX, d'autres types de bases de documents verront le jour. ## Relation avec les entrepôts Une base de documents n'est pas suffisante pour construire une application SDX avec du contenu. En effet, même si celle-ci a toute l'information nécessaire pour chercher des documents et les présenter de façon sommaire, elle ne contient pas les documents eux-mêmes, ni même une référence précise avec leur emplacement. Par contre, les bases de documents vont garder une trace de l'entrepôt de documents où se trouve le document indexé, ce qui va permettre de retrouver les documents eux-mêmes lorsque nécessaire. La configuration d'un entrepôt de documents peut se situer à l'intérieur (dans le sens de la hiérarchie XML) de la configuration d'une base de documents ou encore à l'extérieur, c'est-à-dire au niveau de la configuration d'une application. Lorsque l'entrepôt est défini à l'intérieur d'une base de documents, cela signifie qu'il est accessible seulement pour cette base ; autrement dit, les autres bases de documents de l'application ne pourront pas stocker les documents dans cet entrepôt. A l'opposé, lorsque l'entrepôt est défini au niveau de l'application, toutes les bases de documents peuvent y déposer des documents. L'intérêt de cette configuration sera plus important lorsque différents types de bases de documents seront intégrés à SDX. ## L'élément `<sdx:documentBases>` Cet élément a simplement pour but de contenir la liste des bases de documents associées à une application. Il doit être à l'intérieur de l'élément `<sdx:application>`. ## Informations générales à propos d'une base de documents L'élément `<sdx:documentBase>` contient toutes les informations nécessaires pour définir une base de documents, y compris certaines informations générales. Ces informations générales sont toutes spécifiées en attributs. Table 1. Attributs de l'élément `<sdx:documentBase>`
Attribut | Valeurs possibles | Description
--- | --- | ---
`id` | Un identifiant. Obligatoire. | L'identifiant de la base de documents. Cet identifiant est obligatoire, il devient par la suite la clé d'identification de la base de documents pour toutes les opérations de recherche, d'ajout ou de suppression de documents dans cette base.
`default` | Un booléen (`true` ou `false`), par défaut c'est `false`. | Si true, cette base est la base par défaut pour cette application. Cela signifie que les opérations de recherche, d'ajout ou de suppression de documents se feront dans cette base sauf si une base est explicitement mentionnée par son identifiant.
`type` | Une chaîne. | Le type de base de documents ; pour l'instant, seule la valeur "lucene" est permise.
`xml:lang` | Un code de langue selon la norme XML (par exemple fr-CA ou en). | La langue par défaut pour le contenu des champs de cette base de documents. Si elle n'est pas spécifiée, c'est la langue par défaut de l'application qui est utilisée.
`variant` | Un code de variante de langue, selon le langage Java. | Java permettant de préciser des variantes de langue, le contenu de cet attribut vient préciser la langue donnée par xml:lang.
`remote-access` | Un booléen (true ou false), par défaut c'est false. | Si true, cette base de documents est cherchable par des applications SDX autres que celle où elle est définie.
`keepOriginalDocuments` | Un booléen (true ou false), par défaut c'est true. | Cet attribut n'a de sens que si le tube d'indexation contient plusieurs étapes de transformation. Dans ce cas, une valeur true signifie que le document original fourni à l'indexation est conservé par SDX ; dans le cas contraire, SDX ne conserve que les documents issus des étapes de transformation avec un keep=true.
`maxFieldLength` | Un nombre entier, par défaut 10 000. | Le nombre de mots indexés dans un champ. La modification de ce nombre peut avoir des impacts sur la performance. Consulter la documentation de la classe IndexWriter de Lucene pour en savoir plus.
`autoOptimize` | Un booléen (`true` ou `false`), par défaut c'est `true`. | Par défaut, SDX optimise les index Lucene à toutes les fois qu'un lot de documents est ajouté ou supprimé à l'index. Voir la section sur la gestion des index ci-dessous pour en savoir plus. A noter que cette fonctionnalité n'est disponible que depuis la version 2.3 de SDX. Si vous utilisez cet attribut avec une version antérieure, il est tout simplement ignoré.
## Générateur d'identifiants Tous les documents gérés par SDX doivent avoir un identifiant. Cet identifiant doit être unique dans la base de documents où il se trouve. En général, c'est le processus d'indexation qui est responsable de déterminer cet identifiant qui est fourni par l'attribut `id` de l'élément `sdx:document` résultant de ce processus d'indexation. Toutefois, dans certains cas, il peut être difficile de trouver un identifiant lors du processus d'indexation, et c'est pourquoi SDX 2 offre un moyen d'en générer automatiquement, à l'aide de générateurs d'identifiants. Un générateur d'identifiants est nécessairement une classe Java qui implémente l'interface fr.gouv.culture.sdx.documentbase.IDGenerator ; SDX 2 fournit une telle classe nommée fr.gouv.culture.sdx.documentbase.DefaultIDGenerator qui génère des identifiants de manière aléatoire. Il n'est pas nécessaire de configurer des générateurs d'identifiants, même si on désire en utiliser un. En effet, dans une telle situation, SDX 2 utilisera toujours son propre générateur d'identifiants par défaut. Toutefois, si on veut en utiliser un autre, on doit le déclarer dans le `application.xconf`, à l'aide d'un élément `sdx:idGenerator`, qui doit avoir un attribut `class` qui indique le nom complet de la classe, et peut avoir des attributs `idPrefix` et `idSuffix` pour indiquer un préfixe et/ou un suffixe à ajouter aux identifiants générés. Pour utiliser ce générateur d'identifiants ou celui proposé par SDX 2, on doit spécifier l'attribut `generateId` de `sdx:document` dans le document retourné par le processus d'indexation, et lui donner une valeur true. ## Gestion des index
| Note
Les informations fournies dans cette section ne sont valables que depuis la version 2.3 de SDX. Sur des versions antérieures, elles n'ont aucun effet.
Il est possible de paramétrer la manière dont SDX va gérer les index Lucene pour une base de documents. Le principal objectif de ce paramétrage est de rendre plus efficace la gestion des gros index, c'est-à-dire lorsqu'il y a un très grand nombre de documents ou lorsque les documents sont de grande taille. Pour les petits index, ces paramétrages sont fonctionnels mais peu utiles. ### Optimisation Un index Lucene est optimisé lorsqu'il est stocké dans une structure efficace et optimale. Normalement, lorsqu'on ajoute ou supprime des documents dans un index Lucene, celui-ci n'est plus optimisé, jusqu'à ce qu'on demande explicitement une optimisation. Que l'index soit optimisé ou non, les résultats de recherche seront exactement les mêmes, mais un index optimisé effectuera les recherches plus rapidement. Par ailleurs, l'optimisation d'un index est une opération qui prend un certain sur un index volumineux. C'est pourquoi il ne faut pas chercher à la faire trop souvent. La gestion de l'optimisation d'un index Lucene doit donc être vu comme un compromis entre la performance en recherche (les index optimisés sont plus performants) et la performance en indexation (l'optimisation des index prend du temps). Si on ne fait rien de spécial pour une base de documents SDX, ou si on utilise une version de SDX antérieure à la 2.3, alors l'optimisation de l'index Lucene sera effectuée l'ajout ou la suppression de chaque lot de documents. La taille d'un lot est spécifiée par le paramètre batch que l'on peut fournir lors de l'indexation ; par défaut la valeur est de 25, ce qui est peu. Donc si vous avez des lots de 25 et que vous indexez 1000 documents, alors l'index sera optimisé 40 fois. Si vous indexez un seul document à la fois, l'index sera optimisé une fois. C'est pourquoi depuis la version 2.3 de SDX il est possible de configurer une base de documents (et donc des index Lucene) pour que l'optimisation ne soit pas effectuée après l'indexation d'un lot de documents. Pour ce faire, il s'agit d'utiliser l'attribut `autoOptimize` de l'élément `sdx:documentBase` et de lui donner la valeur `false` (voir ci-dessus). Dans ce cas, si vous ne faites rien d'autre, les index ne seront jamais optimisés. ## Interprète de requêtes A faire. ## Liste des champs La liste des champs contient des informations capitales pour une base de documents SDX, puisque toutes les manipulations ultérieures (recherche, tris, résultats, etc.) se font sur des champs. La liste des champs est une liste à plat, une simple collection de champs dont l'ordre n'est pas important. Pour chaque champ, on peut définir un certain nombre de propriétés, certaines ayant des valeurs par défaut, d'autres obligatoires, d'autres optionnelles. De plus, un certain nombre de propriétés peuvent être héritées depuis des éléments parents. De manière générale, la définition d'une liste de champs intervient à l'intérieur d'un élément `sdx:documentBase` de la manière suivante :
    <sdx:documentBase ...>
      ...
      <sdx:fieldList ...>
        <sdx:field .../>
        ...
      </sdx:fieldList>
    </sdx:documentBase>
La liste des champs est obligatoire, sinon votre base de documents ne sera pas disponible dans l'application. L'élément `sdx:fieldList` peut avoir les attributs suivants : Table 2.
Atribut | Valeurs possibles | Description
--- | --- | ---
`ref` | L'attribut id d'un autre élément `sdx:fieldList`. Optionnel. Pas de valeur par défaut. | Cet attribut permet de pointer sur un autre élément `sdx:fieldList` déclaré globalement, c'est-à-dire au niveau de l'application, et donc dans l'élément `sdx:application`. Cela permet de réutiliser des listes de champs dans différentes bases de documents. A noter que si vous utilisez cet attribut, toutes les proprités de la liste de champs de référence seront utilisées, mais vous pourrez ajouter des champs en ajoutant des sous-éléments `sdx:field`.
`analyzerClass` | Le nom qualifié d'une classe Java. Optionnel. Pas de valeur par défaut directe. | Cette classe Java sera utilisée comme analyseur de mots par défaut pour tous les champs de cette liste. Ainsi, si un champ de type `word` n'a pas de précisions sur l'analyseur de mots à utiliser, c'est celui-ci qui le sera. Cet attribut a préséance sur le rôle joué par l'attribut `xml:lang` présenté ci-dessous.
`analyzerConf` | Une URL. Optionnel. Pas de valeur par défaut. | L'URL qui indique le fichier de configuration à utiliser pour l'analyse de mots spécifié par défaut, peu importe la méthode dont celui-ci est spécifié.
`xml:lang` | Un code de langue, éventuellement qualifié (par exemple `fr-CA`). Optionnel. Pas de valeur par défaut directe. | La langue par défaut du contenu des champs. Si l'attribut `analyzerClass` n'est pas utilisé, alors la langue permet de déterminer l'analyseur de mots par défaut. S cet attribut n'est pas spécifié, alors on considère que la langue est donnée par l'attribut `xml:lang` de l'élément parent `sdx:documentBase` ou, si celui-ci non plus n'est pas spécifié, on considère que la langue est donnée par l'attribut `xml:lang` de l'élément racine `sdx:application`.
`variant` | Une chaîne de caractères. Optionnel. Pas de valeur par défaut. | Un complément au code de langue, selon le mécanisme des locale du langage Java. Pour préciser encore plus la langue par défaut des contenus.
Ensuite, à l'intérieur de l'élément `sdx:fieldList`, on retrouve un ou plusieurs éléments `sdx:field`, chacun identifiant un champ qui sera disponible en recherche ou pour tout autre traitement. Le tableau suivant présente les attributs qui peuvent être associés à l'élément `sdx:field` pour déterminer les caractéristiques de chaque champ. Table 3.
Atribut | Valeurs possibles | Description
--- | --- | ---
`name` | Une chaîne de caractère, unique parmi tous les champs, composée de lettres seulement. Obligatoire. | Cet attribut donne un nom unique au champ.
`default` | Un booléen, soit `true` ou `false`. Optionnel. Par défaut, `false`. | Indique s'il s'agit du champ de recherche par défaut. Il doit y avoir un seul champ par défaut dans une liste de champs.
`type` | Une des valeurs `word`, `field`, `date`, `unindexed` ou `xml`. Obligatoire. Par défaut `word`. | Le type de champ ou d'indexation dont il s'agit. La valeur `word` indique un champ indexé par mots, avec un analyseur de mots. La valeur `field` indique un champ indexé tel quel, sans analyse de mots. La valeur `date` indique que le contenu doit être traité comme une date (format ISO 8601). La valeur `unindexed` indique que le champ n'est pas indexé. La valeur `xml` indique que le champ n'est pas indexé mais que sont contenu doit être interprété comme étant du XML, mais non indexé. A noter que cette dernière valeur n'est possible que depuis la version 2.3 de SDX.
`brief` | Un booléen, soit `true` ou `false`. Optionnel. Par défaut, `false`. | Indique si le champ doit être retourné en résultat de recherche ou non. Pour un champ de type `unindexed` ou `xml`, il est conseillé de mettre cette valeur à `true` sinon le champ sera inutile.
`analyzerClass` | Le nom qualifié d'une classe Java. Optionnel. Pas de valeur par défaut directe. | Cette classe Java sera utilisée comme analyseur de mots par défaut pour tous ce champ, s'il est de type `word`. Cet attribut a préséance sur l'attribut `xml:lang` ou sur les informations fournies au niveau de l'élément `sdx:fieldList`.
`analyzerConf` | Une URL. Optionnel. Pas de valeur par défaut. | L'URL qui indique le fichier de configuration à utiliser pour l'analyse de mots pour ce champ.
xml:`lang` | Un code de langue, éventuellement qualifié (par exemple `fr-CA`). Optionnel. Pas de valeur par défaut directe. | La langue par défaut du contenu du champs. Si l'attribut `analyzerClass` n'est pas utilisé, alors la langue permet de déterminer l'analyseur de mots pour le champ de type `word`. S cet attribut n'est pas spécifié, alors on considère que la langue est donnée par l'attribut `xml:lang` de l'élément parent `sdx:fieldList` ou par les règles d'héritage qui lui sont propres..
`variant` | Une chaîne de caractères. Optionnel. Pas de valeur par défaut. | Un complément au code de langue, selon le mécanisme des locale du langage Java. Pour préciser encore plus la langue du contenu du champ.
`storeTermVector` | Un booléen, soit `true` ou `false`. Optionnel. Par défaut, `false`. | Indique si le moteur de recherche Lucene doit consigner des informations de type term vectors pour ce champ. Pour en savoir plus sur ces informations, voir la documentation de Lucene. A noter que SDX ne fait aucun usage de cette information, mais si elle est stockée alors elle pourrait être exploitée à l'aide d'autres outils, ou en manipulant directement les index Lucene, sans SDX.
## Indexation A faire.
| Auteur : Martin Sévigny ( AJLSM ) - 2004-08-19

| Home |
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.