Exporter (0) Imprimer
Développer tout
Développer Réduire
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Choisir une langue lors de la création d'un index de recherche en texte intégral

État de la rubrique : certaines informations de cette rubrique constituent une documentation préliminaire et peuvent faire l'objet de modifications dans les versions à venir. Ces informations préliminaires décrivent les nouvelles fonctionnalités ou les modifications apportées à des fonctionnalités existantes de Microsoft SQL Server 2014.

Lorsque vous créez un index de recherche en texte intégral, vous devez spécifier une langue au niveau de la colonne pour la colonne indexée. L'analyseur lexical et les générateur de formes dérivées de la langue spécifiée seront utilisés par les requêtes de texte intégral sur la colonne. Plusieurs aspects doivent être pris en considération pour le choix de la langue d'une colonne lors de la création d'un index de texte intégral. Ces aspects sont liés à la façon dont les jetons de votre texte sont créés et à la façon dont ce texte est ensuite indexé par le Moteur d'indexation et de recherche en texte intégral pour.

Remarque Remarque

Pour spécifier une langue au niveau de la colonne pour une colonne d'index de recherche en texte intégral, utilisez la clause language_term LANGUAGE lors de la spécification de la colonne. Pour plus d'informations, consultez CREATE FULLTEXT INDEX (Transact-SQL) et ALTER FULLTEXT INDEX (Transact-SQL).

Cette section fournit une introduction aux analyseurs lexicaux et aux générateur de formes dérivées et indique comment la recherche en texte intégral utilise le LCID de la langue de la colonne.

Introduction aux analyseurs lexicaux et aux générateurs de formes dérivées

SQL Server 2008 et les versions ultérieures incluent une nouvelle famille complète d'analyseurs lexicaux et de générateurs de formes dérivées qui sont considérablement plus performants que ceux précédemment disponibles dans SQL Server.

Remarque Remarque

Le Microsoft Natural Language Group (MS NLG) a implémenté et prend en charge ces nouveaux composants linguistiques.

Les avantages de ces nouveaux analyseurs lexicaux sont les suivants :

  • Robustesse

    Les tests ont montré que les nouveaux analyseurs lexicaux sont fiables dans les environnements de requête de haute intensité.

  • Sécurité

    Les nouveaux analyseurs lexicaux sont activés par défaut dans SQL Server grâce aux améliorations de sécurité dans les composants linguistiques. Nous recommandons vivement que les composants externes tels que les analyseurs lexicaux et filtres soient signés afin d'améliorer la sécurité globale et la robustesse de SQL Server. Vous pouvez configurer le texte intégral pour vérifier que ces composants sont signés comme suit :

    EXEC sp_fulltext_service 'verify_signature';
    
  • Qualité

    Les analyseurs lexicaux ont été repensés, et les tests ont montré que les nouveaux analyseurs lexicaux fournissent une qualité sémantique supérieure à celle des analyseurs lexicaux précédents. Cela augmente l'exactitude de rappel.

  • Pour couvrir une longue liste de langues, les analyseurs lexicaux sont inclus d'office dans SQL Server et sont activés par défaut.

Pour obtenir la liste des langues pour lesquelles SQL Server comprend des analyseurs lexicaux et des générateurs de formes dérivées, consultez sys.fulltext_languages (Transact-SQL)

[Haut de la page]

Comment la recherche en texte intégral utilise le nom de la langue de la colonne

Lorsque vous créez un index de recherche en texte intégral, vous devez spécifier un nom de langue valide pour chaque colonne. Si un nom de langue est valide mais n'est pas retourné par l'affichage catalogue sys.fulltext_languages (Transact-SQL), la recherche en texte intégral revient, le cas échéant, au nom de la langue disponible le plus proche de la même famille de langues. Sinon, la recherche en texte intégral revient à l'analyseur lexical neutre. Ce comportement de repli peut affecter l'exactitude de rappel. Par conséquent, nous vous recommandons vivement de spécifier un nom de langue valide et disponible pour chaque colonne lors de la création d'un index de recherche en texte intégral.

Remarque Remarque

Le LCID est appliqué à tous les types de données pouvant faire l'objet d'une indexation de texte intégral (par exemple char ou nchar). Si l'ordre de tri d'une colonne de type char, varchar ou text est défini à l'aide d'une langue différente de la langue identifiée par le LCID, ce dernier est néanmoins utilisé durant l'indexation de recherche en texte intégral et l'interrogation de ces colonnes.

[Haut de la page]

Un analyseur lexical crée des jetons dans le texte indexé à partir des limites des mots, qui sont spécifiques aux langues. Par conséquent, le comportement d'analyse lexicale diffère d'une langue à l'autre. Si vous utilisez une langue x indexer plusieurs langues {x, y et z}, une partie du comportement peut donner lieu à des résultats inattendus. Par exemple, un tiret (-) ou une virgule (,) peut être un élément d'analyseur lexical pouvant être rejeté dans une langue mais pas dans un autre. Un comportement de génération de formes dérivées rarement inattendu peut également se produire parce qu'un mot donné peut être dérivé différemment dans une autre langue. Par exemple, en anglais, les limites des mots sont généralement fixées par des espaces blancs ou un signe de ponctuation. Dans d'autres langues, par exemple l'allemand, les mots ou les caractères peuvent être accolés. Par conséquent, le choix de la langue d'une colonne doit être représentatif de la langue destinée à être stockée dans les lignes de cette colonne.

Langues occidentales

Pour la famille des langues occidentales, si vous êtes incertain quant aux langues qui seront stockées dans une colonne ou si vous pensez en stocker plusieurs, la solution de contournement générale est d'utiliser l'analyseur lexical pour la langue la plus complexe pouvant être stockée dans la colonne. Par exemple, vous pouvez vous attendre à stocker du contenu en anglais, en espagnol et en allemand dans une colonne unique. Ces trois langues occidentales possèdent des modes d'analyse lexicale très semblables, les modes allemands étant les plus complexes. Par conséquent, un bon choix dans ce cas serait d'utiliser l'analyseur lexical allemand, qui doit être en mesure de traiter le texte anglais et espagnol correctement. Par contre, il se peut que l'analyseur lexical anglais ne puisse pas traiter parfaitement le texte allemand à cause des mots composés allemands.

Notez que l'utilisation de l'analyseur lexical de la langue la plus complexe dans une famille de langues ne garantit pas l'indexation parfaite de chaque langue de la famille. Il peut y avoir des cas où l'analyseur lexical le plus complexe ne peut pas gérer correctement le texte écrit dans une autre langue.

[Haut de la page]

Langues non occidentales

Pour les langues non occidentales (telles que chinois, japonais, hindi, etc.), la solution de contournement précitée ne fonctionne pas nécessairement, pour des raisons linguistiques. Pour les langues non occidentales, considérez l'une des solutions de contournement suivantes :

  • Pour les langues de familles différentes

    Si une colonne peut contenir des langues complètement différentes, par exemple l'espagnol et le japonais, pensez à stocker le contenu de langues différentes dans des colonnes séparées. Cela vous permettrait d'utiliser l'analyseur lexical spécifique à une langue pour chaque colonne. Si vous choisissez cette solution et que vous ne connaissez pas la langue de la requête à l'heure de la requête, vous pouvez devoir lancer la requête par rapport aux deux colonnes afin de faire en sorte que la requête recherche la bonne ligne ou le bon document.

  • Pour le contenu binaire (par exemple, les documents Microsoft Word)

    Lorsque le contenu indexé est de type binary, le filtre de recherche en texte intégral qui traite le contenu textuel avant de l'envoyer à l'analyseur lexical peut respecter des balises de langue spécifiques existantes dans le fichier binaire. Dans ce cas, au moment de l'indexation, le filtre émettra le bon LCID pour un document ou une section d'un document. Le moteur d'indexation et de recherche en texte intégral appellera ensuite l'analyseur lexical pour la langue correspondant à ce LCID. Toutefois, après avoir indexé un contenu multilingue, nous vous recommandons de vérifier que le contenu a été indexé correctement.

  • Pour un contenu de texte brut

    Lorsque votre contenu est du texte brut, vous pouvez le convertir en type de données xml et ajouter les balises de langue qui indiquent la langue qui correspond à chaque document ou section de document spécifique. Pour que cette option fonctionne toutefois, vous devez connaître la langue avant l'indexation de recherche en texte intégral.

[Haut de la page]

La recherche de radical est un autre point à prendre en considération lors du choix de la langue de votre colonne. La recherche de radical dans les requêtes de texte intégral se définit comme la recherche de toutes les formes fléchies d'un mot dans une langue particulière. Lorsque vous utilisez un analyseur lexical générique pour traiter plusieurs langues, le processus de recherche de radical fonctionne uniquement pour la langue spécifiée pour la colonne, et non pour d'autres langues dans la colonne. Par exemple, les générateur de formes dérivées allemands ne fonctionnent pas pour l'anglais et l'espagnol (etc.). Cela peut affecter votre rappel, selon la langue que vous choisissez au moment de la requête.

[Haut de la page]

Un autre point à prendre en considération dans le choix de la langue est lié au mode de représentation des données. Pour les données non stockées dans une colonne varbinary(max), aucun filtrage particulier n'est effectué. À la place, le texte est généralement traité tel quel par le composant de séparation des mots.

Les analyseurs lexicaux sont, aussi, principalement conçus pour traiter le texte écrit. Par conséquent, si votre texte contient un balisage quelconque (par exemple du code HTML), vous risquez de ne pas obtenir une précision linguistique importante durant l'indexation et la recherche. Dans ce cas, vous avez deux possibilités : la méthode recommandée consiste simplement à stocker les données de texte dans la colonne varbinary(max) et à indiquer le type de document correspondant pour permettre un filtrage. Si ce choix ne vous convient pas, utilisez un analyseur lexical neutre et, si possible, ajoutez des données de balisage (par exemple « br » en langage HTML) à vos listes de mots parasites.

Remarque Remarque

L'identification de la racine linguistique n'intervient pas lorsque vous spécifiez la langue neutre.

[Haut de la page]

Par défaut, dans SQL Server, la recherche en texte intégral analyse les termes de la requête en utilisant la langue spécifiée pour chaque colonne incluse dans la clause de texte intégral. Pour remplacer ce comportement, spécifiez une langue autre que par défaut au moment de la requête. Pour les langues prises en charge dont les ressources sont installées, la clause LANGUAGE language_term de la requête CONTAINS, CONTAINSTABLE, FREETEXT ou FREETEXTTABLE est utilisée pour spécifier la langue utilisée pour l'analyse lexicale, la recherche de radical, le dictionnaire des synonymes et le traitement des mots vides des termes de la requête.

[Haut de la page]

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft