Langues et classements (Analysis Services)

Analysis Services prend en charge les langues et les classements fournis par les systèmes d'exploitation Microsoft Windows. Les propriétés Language et Collation sont définies initialement au niveau de l'instance pendant l'installation, mais vous pouvez les modifier ultérieurement à différents niveaux de la hiérarchie d'objets.

Dans un modèle multidimensionnel (uniquement), vous pouvez définir ces propriétés sur une base de données ou sur un cube. Vous pouvez également les définir sur les traductions que vous créez pour des objets dans un cube.

Lors de la définition de Language et Collation, vous spécifiez les paramètres utilisés par le modèle de données pendant le traitement et l'exécution des requêtes ou (pour les modèles multidimensionnels uniquement) vous intégrez plusieurs traductions dans un modèle pour que les locuteurs de langue étrangère puissent l'utiliser dans leur langue maternelle. La définition explicite des propriétés Language et Collation d'un objet (base de données, modèle ou cube) concerne les situations dans lesquelles les serveurs de production et d'environnement de développement sont configurés pour différents paramètres régionaux et vous voulez être sûr que la langue et le classement correspondent à ceux de l'environnement cible.

Cette rubrique comprend les sections suivantes :

• Objects that support Language and Collation properties

• Language support in Analysis Services

• Collation support in Analysis Services

• Change the default language or collation on the instance

• Change the language or collation on a cube

• Change language or collation within a data model using XMLA

• Boost performance for English locales through EnableFast1033Locale

• GB18030 Support in Analysis Services

Objets qui prennent en charge les propriétés Language et Collation

Les propriétés Language et Collation sont souvent exposées ensemble. Là où vous pouvez définir Language, vous pouvez aussi définir Collation.

Vous pouvez définir Language et Collation sur ces objets :

• Instance. Tous les projets déployés sur l'instance adoptent la langue et le classement de l'instance, en supposant que la langue et le classement ne soient pas définis. Par défaut, un modèle multidimensionnel laisse la langue et le classement vide. Quand le projet est déployé, la base de données et les cubes obtenus reçoivent la langue et le classement de l'instance.

  Initialement, les propriétés de langue et de classement sont établies pendant l'installation, mais un administrateur peut les remplacer dans Management Studio. Pour plus d'informations, consultez Change the default language or collation on the instance.

• Base de données. Pour rompre l'héritage, vous pouvez définir explicitement la langue et le classement au niveau du projet utilisé par tous les cubes contenus dans la base de données. Sauf indication contraire, tous les cubes de la base de données reçoivent la langue et le classement que vous spécifiez à ce niveau. Si vous codez et déployez régulièrement avec différents paramètres régionaux (par exemple, si vous développez la solution sur un ordinateur chinois, mais que vous la déployez sur un serveur appartenant à une filiale française), la définition de la langue et du classement au niveau de la base de données est la première et la plus importante étape pour garantir le fonctionnement de la solution dans l'environnement cible. Le meilleur emplacement pour définir ces propriétés est à l'intérieur du projet (via la commande Modifier la base de données sur le projet).

• Dimension de base de données. Bien que le concepteur expose les propriétés Language et Collation sur une dimension de base de données, la définition des propriétés sur cet objet n'est pas utile. Les dimensions de base de données ne sont pas utilisées comme objets autonomes. Il peut donc être difficile, voire impossible, d'utiliser les propriétés que vous définissez. Dans un cube, une dimension hérite toujours des propriétés Language et Collation de son cube parent. Les valeurs que vous avez pu définir sur l'objet de dimension de base de données autonome sont ignorées.

• Cube. S'agissant d'une structure de requête principale, vous pouvez définir la langue et le classement au niveau du cube. Par exemple, vous souhaiterez peut-être créer plusieurs versions linguistiques d'un cube (une en anglais et une en chinois) dans le même projet, où chaque cube a son propre langage et son propre classement.

  Quels que soient la langue et le classement que vous définissez sur le cube, ils sont utilisés par toutes les mesures et les dimensions contenues dans le cube. La seule façon de définir des propriétés de classement plus fines consiste à créer des traductions sur un attribut de dimension. Sinon, en supposant qu'il n'existe aucune traduction au niveau des attributs, il existe un classement par cube.

En outre, vous pouvez définir la propriété Language sur un objet de traduction.

Un objet de traduction est créé lorsque vous ajoutez des traductions à un cube ou à une dimension. Language fait partie de la définition de la traduction. La propriété Collation, quant à elle, est définie sur le cube ou plus haut et elle est partagée par toutes les traductions. Ceci est évident dans le code XMLA d'un cube contenant des traductions, où figurent plusieurs propriétés de langue (une pour chaque traduction), mais un seul classement. Notez qu'il existe une exception pour les traductions d'attributs de dimension, où vous pouvez remplacer le classement de cube pour spécifier un classement d'attribut qui correspond à la colonne source (le moteur de base de données prend en charge la définition du classement sur des colonnes spécifiques et il est courant de configurer des traductions pour obtenir des données de membres à partir de colonnes sources différentes). Mais sinon, pour toutes les autres traductions, la propriété Language est utilisée seule, sans corollaire Collation. Pour plus d'informations, consultez Traductions (Analysis Services).

Prise en charge linguistique dans Analysis Services

La propriété Language définit les paramètres régionaux d'un objet, utilisés durant le traitement, les requêtes et avec Captions et Translations pour prendre en charge les scénarios multilingues. Les paramètres régionaux sont basés sur un identificateur de langue, tel qu'Anglais, et un territoire, tel qu'États-Unis ou Australie, qui affine les représentations de date et d'heure.

Au niveau de l'instance, la propriété est définie lors de l'installation et elle est basée sur la langue du système d'exploitation de serveur Windows (l'une des 37 langues, en supposant qu'un module linguistique soit installé). Vous ne pouvez pas modifier la langue lors de l'exécution du programme d'installation.

Après l'installation, vous pouvez remplacer Language à l'aide de la page de propriétés du serveur dans Management Studio ou dans le fichier de configuration msmdsrv.ini. Vous pouvez choisir parmi de nombreuses langues, y compris toutes celles prises en charge par le client Windows. Quand elle est définie au niveau de l'instance, sur le serveur, la propriété Language détermine les paramètres régionaux de toutes les bases de données déployées par la suite. Par exemple, si vous affectez la valeur Allemand à la propriété Language, toutes les bases de données déployées sur l'instance auront une propriété Language 1031 (le LCID correspondant à l'allemand).

La valeur de la propriété Language est un identificateur de paramètres régionaux (LCID)

Les valeurs valides incluent tout LCID qui figure dans la liste déroulante. Dans Management Studio et SQL Server Data Tools, les LCID sont représentés sous formes de chaînes équivalentes. Les mêmes langues sont utilisées partout où la propriété Language est exposée, indépendamment de l'outil. Le fait d'avoir une liste de langues identique permet de s'assurer que vous pouvez implémenter et tester les traductions de manière cohérente dans tout le modèle.

Bien qu'Analysis Services répertorie les langues par nom, la valeur réelle stockée pour la propriété est un LCID. Quand vous définissez une propriété de langue par programmation ou via le fichier msmdsrv.ini, utilisez l'identificateur de paramètres régionaux (LCID) comme valeur. Un LCID est une valeur 32 bits constituée d'un ID de langue, d'un ID de tri et de bits réservés qui identifient une langue particulière. Analysis Services utilise les LCID pour spécifier la langue sélectionnée pour les instances et les objets Analysis Services.

Vous pouvez définir le LCID au format hexadécimal ou décimal. Voici quelques exemples de valeurs valides pour la propriété Language :

• 0x0409 ou 1033 pour Anglais (États-Unis)

• 0x0411 ou 1041 pour Japonais

• 0x0407 ou 1031 pour Allemand (Allemagne)

• 0x0416 ou 1046 pour Portugais (Brésil).

Pour afficher une liste plus longue, consultez ID de paramètres régionaux assignés par Microsoft. Pour plus d'informations, consultez Codage et pages de codes.

[!REMARQUE]

La propriété Language ne détermine pas la langue du retour des messages système ou des chaînes qui apparaissent dans l'interface utilisateur. Les erreurs, avertissements et messages sont traduits dans toutes les langues prises en charge dans Office et Office 365 et sont automatiquement utilisés quand la connexion cliente spécifie l'un des paramètres régionaux pris en charge.

Prise en charge du classement dans Analysis Services

Analysis Services utilise exclusivement les classements Windows et binaires. Il n'utilise pas les classements SQL Server hérités. Dans un cube, un classement unique est utilisé partout, à l'exception des traductions au niveau de l'attribut. Pour plus d'informations sur la définition des traductions d'attributs, consultez Traductions (Analysis Services).

Les classements contrôlent le respect de la casse pour toutes les chaînes dans un script de langue bicaméral, à l'exception des identificateurs d'objets. Si vous utilisez des caractères minuscules et majuscules dans un identificateur d'objet, sachez que le respect de la casse des identificateurs d'objets n'est pas déterminé par le classement, mais par Analysis Services. Les identificateurs d'objets composés en script anglais ne respectent jamais la casse, quel que soit le classement. Pour le cyrillique et les autres langues bicamérale, c'est l'inverse (la casse est toujours respectée). Pour plus d'informations, consultez Conseils et meilleures pratiques en matière de globalisation (Analysis Services).

Le classement dans Analysis Services est compatible avec celui du moteur de base de données relationnelle SQL Server, en supposant que vous mainteniez la parité dans les options de tri que vous sélectionnez pour chaque service. Par exemple, si la base de données relationnelle respecte les accents, vous devez configurer le cube de la même façon. Des problèmes peuvent survenir quand les paramètres de classement divergent. Pour obtenir un exemple et des solutions de contournement, consultez Les vides dans une chaîne Unicode sont traités différemment selon le classement. Pour plus d'informations sur le classement et le moteur de base de données, consultez Prise en charge d'Unicode et du classement.

Types de classements

Analysis Services prend en charge deux types de classements :

• Classements Windows

  Les classements Windows trient les caractères selon les caractéristiques linguistiques et culturelles de la langue. Dans Windows, les classements sont plus nombreux que les paramètres régionaux (ou langues) utilisés avec eux, car de nombreuses langues partagent le même alphabet et les mêmes règles de tri et de comparaison des caractères. Par exemple, 33 groupes de paramètres régionaux Windows, notamment tous les groupes de paramètres régionaux portugais et anglais, utilisent la page de codes Latin1 (1252) et possèdent un ensemble de règles communes pour le tri et la comparaison des caractères.

• Classements binaires (BIN ou BIN2)

  Les classements binaires effectuent un tri sur des points de code Unicode, et non sur des valeurs linguistiques. Par exemple, Latin1_General_BIN et Japanese_BIN renvoient les mêmes résultats de tri lorsqu'ils sont appliqués à des données Unicode. Alors qu'un tri linguistique peut générer des résultats comme aAbBcCdD, un tri binaire serait ABCDabcd car le point de code de tous les caractères majuscules est collectivement plus élevé que les points de code des caractères minuscules.

Options d'ordre de tri

Des options de tri sont utilisées pour affiner les règles de tri et de comparaison en fonction du respect de la casse, des accents, des caractères kana et de la largeur. Par exemple, la valeur par défaut de la propriété de configuration Collation d'Analysis Services est Latin1_General_AS_CS, ce qui indique que le classement Latin1_General est utilisé avec un ordre de tri respectant les accents et la casse.

Notez que BIN et BIN2 sont mutuellement exclusifs d'autres options de tri. Si vous souhaitez utiliser BIN ou BIN2, désactivez l'option de tri pour le respect des accents. De même, quand BIN2 est activé, les options Respecter la casse, Non-respect de la casse, Respecter les accents, Non-respect des accents, Respecter les caractères Kana et Respecter la largeur ne sont pas disponibles.

Le tableau suivant décrit les options d'ordre de tri des classements Windows et les suffixes correspondants pour Analysis Services.

Modifier la langue ou le classement par défaut de l'instance

La langue et le classement par défaut sont établis pendant l'installation, mais vous pouvez les modifier dans le cadre de la configuration de post-installation. La modification du classement au niveau de l'instance n'est pas une opération triviale. Elle comporte les exigences suivantes :

• Redémarrage du service.

• Mise à jour des paramètres de classement des objets existants. Les paramètres de classement sont hérités une fois quand l'objet est créé. Les modifications ultérieures apportées au classement doivent être effectuées manuellement. Pour obtenir des conseils sur la façon de propager les modifications de classement dans le modèle, voir Change collation within a data model using XMLA.

• Retraitement des partitions et des dimensions une fois le classement mis à jour.

Vous pouvez utiliser SQL Server Management Studio ou PowerShell AMO pour modifier la langue ou le classement par défaut au niveau du serveur. Vous pouvez également modifier les paramètres <Language> et <CollationName> dans le fichier msmdsrv.ini, en spécifiant le LCID de la langue.

1. Dans Management Studio, cliquez sur le nom du serveur | Propriétés | Langue/Classement.

2. Choix des options de tri. Pour sélectionner Binaire ou Binaire 2, décochez d'abord la case Respecter les accents.

   Notez que le classement et la langue sont des paramètres entièrement indépendants. Si vous en changez un, les valeurs de l'autre ne sont pas filtrés pour afficher les combinaisons courantes.

3. Mise à jour du modèle de données pour utiliser le nouveau classement (voir la section suivante).

4. Redémarrage du service.

Modifier la langue ou le classement d'un cube

1. Dans l'Explorateur de solutions, double-cliquez sur un cube pour l'ouvrir dans le Concepteur de cube.

2. Dans le volet Mesures ou Dimensions, sélectionnez le nœud supérieur. L'objet de niveau supérieur de l'un des volets est le cube.

3. Dans Propriétés, définissez Language et Collation. Les valeurs que vous choisissez sont utilisés par tous les objets du cube, y compris les dimensions et les mesures du cube, et elles affectent les opérations de traitement et de requête.

   La seule façon d'incorporer d'autres propriétés de langue et de classement sur des objets dans le cube consiste à passer par des traductions. Pour plus d'informations, consultez Traductions (Analysis Services).

Modifier la langue et le classement dans un modèle de données à l'aide de XMLA

Les paramètres de langue et de classement sont hérités une fois quand l'objet est créé. Les modifications ultérieures apportées à ces propriétés doivent être effectuées manuellement. Une approche pour la modification rapide du classement de plusieurs objets consiste à utiliser une commande ALTER sur un script XMLA.

Par défaut, le classement est défini une seule fois, au niveau de la base de données. L'héritage est implicite dans le reste de la hiérarchie d'objets. Si vous définissez explicitement Collation sur des objets du cube, ce qui est autorisé sur des attributs de dimension spécifiques, cela apparaît dans la définition XMLA. Dans le cas contraire, seule la propriété de classement de niveau supérieur existe.

Avant d'utiliser XMLA pour modifier une base de données existante, assurez-vous de ne pas introduire d'incohérences entre la base de données et les fichiers sources utilisés pour la générer. Par exemple, vous souhaiterez peut-être utiliser XMLA pour modifier rapidement la langue ou le classement à des fins de test de preuve de concept, mais apporter ensuite des modifications au fichier source (voir Change the language or collation on a cube) et redéployer la solution à l'aide des procédures opérationnelles déjà en place.

1. Dans Management Studio, cliquez sur la base de données | Générer un script de la base de données en tant que | ALTER To | Nouvelle fenêtre d'éditeur de requête.

2. Recherchez et remplacez la langue ou le classement existant par une autre valeur.

3. Appuyez sur F5 pour exécuter le script.

4. Retraitez le cube.

Optimisation des performances pour les paramètres régionaux Anglais via EnableFast1033Locale

Si vous utilisez l'identificateur de langue Anglais (États-Unis) (0x0409 ou 1033) en tant que langue par défaut de l'instance d'Analysis Services, vous pouvez obtenir de meilleures performances en définissant la propriété de configuration EnableFast1033Locale, une propriété de configuration avancée disponible uniquement pour cet identificateur de langue. Si vous attribuez la valeur True à cette propriété, Analysis Services utilise un algorithme plus rapide pour le hachage de chaînes et les comparaisons. Pour plus d'informations sur la définition des propriétés de configuration, consultez Configurer les propriétés du serveur dans Analysis Services.

Prise en charge de GB18030 dans Analysis Services

GB18030 est une norme distincte utilisée en République populaire de Chine pour l'encodage des caractères chinois. Dans la norme GB18030, les caractères peuvent être encodés sur 1, 2 ou 4 octets de longueur. Dans Analysis Services, il n'y a aucune conversion de données lors du traitement de données provenant de sources externes. Les données sont simplement stockées au format Unicode. Au moment de la requête, une conversion GB18030 est effectuée via les bibliothèques clientes Analysis Services (plus précisément, le fournisseur OLE DB MSOLAP.dll) quand des données texte sont retournées dans les résultats de la requête, en fonction des paramètres du système d'exploitation client. Le moteur de base de données prend également en charge la norme GB18030. Pour plus d'informations, consultez Prise en charge d'Unicode et du classement.

Voir aussi

Concepts

Scénarios de globalisation pour les instances multidimensionnelles d'Analysis Services

Conseils et meilleures pratiques en matière de globalisation (Analysis Services)

Prise en charge d'Unicode et du classement