Langues et classements (Analysis Services)

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

SQL Server Analysis Services prend en charge les langues et classements fournis par les systèmes d’exploitation Microsoft Windows. Les propriétés de langage et de classement sont initialement définies au niveau de l’instance pendant l’installation, mais peuvent être modifiées 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 un cube. Vous pouvez également les définir sur les traductions que vous créez pour les objets au sein d’un cube. Dans un modèle tabulaire, la langue et le classement sont hérités du système d’exploitation hôte.

Lorsque vous définissez la langue et le classement dans un modèle multidimensionnel, 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 vous équipez un modèle avec plusieurs traductions afin que les haut-parleurs de langue étrangère puissent travailler avec le modèle dans leur langue native. La définition explicite des propriétés Language et Collation sur un objet (base de données, modèle ou cube) concerne les situations où l’environnement de développement et le serveur de production sont configurés pour différents paramètres régionaux, et que vous souhaitez vous assurer que la langue et le classement correspondent à ceux de l’environnement cible prévu.

Objets qui prennent en charge les propriétés de langue et de collation

Les propriétés de langue et de classement sont souvent exposées ensemble : où vous pouvez définir la langue, vous pouvez également définir le classement.

Vous pouvez définir la langue et le classement 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 sont pas définis. Par défaut, un modèle multidimensionnel laisse le langage et le classement vides. Lorsque le projet est déployé, la base de données et les cubes résultants obtiennent la langue et le classement de l’instance.

  Initialement, les propriétés de langage et de classement sont établies pendant l’installation, mais un administrateur peut les remplacer dans Management Studio. Pour plus d’informations, consultez Modifier la langue ou le classement par défaut de l’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 obtiendront la langue et le classement que vous spécifiez à ce niveau. Si vous codez et déployez régulièrement sur différents paramètres régionaux (par exemple, le développement de la solution sur un ordinateur chinois, mais le 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 étape et la plus importante pour garantir que la solution fonctionne dans l’environnement cible. Le meilleur endroit 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 en tant qu’objets autonomes. Il peut donc être difficile s’il n’est pas 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. Toutes les valeurs que vous avez définies sur l’objet dimension de base de données autonome sont ignorées.

• Cube. En tant que structure de requête principale, vous pouvez définir la langue et les paramètres de collation au niveau du cube. Par exemple, vous pouvez créer plusieurs versions linguistiques d’un cube, telles que les versions anglaises et chinoises, dans le même projet, où chaque cube a sa propre langue et son classement.

  Le langage et le classement que vous définissez sur le cube sont utilisés par toutes les mesures et dimensions contenues dans le cube. La seule façon de définir des propriétés de classement à un grain plus fin est si vous créez 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 langue, par lui-même, sur un objet Translation .

Un objet de traduction est créé lorsque vous ajoutez des traductions à un cube ou à une dimension. La langue fait partie de la définition de 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. Cela est évident dans le XMLA d’un cube contenant des traductions, où vous verrez plusieurs propriétés de langue (une pour chaque traduction), mais un seul classement. Notez qu’il y a une exception concernant les traductions d’attributs de dimension : vous pouvez remplacer le classement du cube pour préciser un classement d’attribut qui correspond à la colonne source. Le moteur de base de données permet de définir le classement sur des colonnes individuelles et il est courant de configurer des traductions spécifiques pour obtenir des données membres à partir de différentes colonnes sources. Mais sinon, pour toutes les autres traductions, la propriété Language est utilisée seule, sans corollaire Collation . Pour plus d’informations, consultez la prise en charge de la traduction dans Analysis Services .

Prise en charge linguistique dans Analysis Services

La propriété Language définit les paramètres régionaux d’un objet, utilisé pendant le traitement, les requêtes et avec les légendes et les traductions pour prendre en charge les scénarios multilingues. Les paramètres régionaux sont basés sur un identificateur de langue, tel que l’anglais et un territoire, comme les États-Unis ou l’Australie, qui affinent davantage les représentations de date et d’heure.

Au niveau de l’instance, la propriété est définie pendant l’installation et est basée sur la langue du système d’exploitation Windows Server (l’une des 37 langues, en supposant qu’un module linguistique est installé). Vous ne pouvez pas modifier la langue dans le programme d’installation.

Après l’installation, vous pouvez remplacer la langue à l’aide de la page des propriétés du serveur dans Management Studio ou dans le fichier de configuration msmdsrv.ini. Vous pouvez choisir parmi de nombreuses langues supplémentaires, 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 langue détermine les paramètres régionaux de toutes les bases de données qui sont ensuite déployées. Par exemple, si vous définissez la langue sur l’allemand, toutes les bases de données déployées sur l’instance ont une propriété Language de 1031, le LCID pour l’allemand.

La valeur de la propriété Language est un identifiant de locale (LCID)

Les valeurs valides incluent n’importe quel LCID qui apparaît dans la liste déroulante. Dans Management Studio et SQL Server Data Tools, les LCID sont représentés dans des équivalents de chaîne. Les mêmes langues s’affichent partout où la propriété Language est exposée, quel que soit l’outil. Disposer d’une liste identique de langues garantit que vous pouvez implémenter et tester des traductions de manière cohérente dans tout le modèle.

Bien que Analysis Services répertorie les langues par nom, la valeur réelle stockée pour la propriété est un LCID. Lorsque vous définissez une propriété de langage 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 composée d’un ID de langage, d’un ID de tri et de bits réservés qui identifient une langue particulière. SQL Server Analysis Services utilise des LCID pour spécifier le langage sélectionné pour les instances et les objets SQL Server Analysis Services.

Vous pouvez définir le LCID à l’aide de formats hexadécimaux ou décimaux. Voici quelques exemples de valeurs valides pour la propriété Language :

• 0x0409 ou 1033 pour l’anglais (États-Unis)

• 0x0411 ou 1041 pour le japonais

• 0x0407 ou 1031 pour l’Allemagne (allemand)

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

Pour afficher une liste plus longue, consultez les ID de paramètres régionaux attribués par Microsoft. Pour plus d’arrière-plan, consultez Encodage et pages de codes.

Note

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

Prise en charge du classement dans Analysis Services

SQL Server Analysis Services utilise windows (versions _90 et _100) et les classements binaires exclusivement. 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 la prise en charge de la traduction dans 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 SQL Server 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 les conseils et les meilleures pratiques 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 maintenez la parité dans les options de tri que vous sélectionnez pour chaque service. Par exemple, si la base de données relationnelle est sensible à l'accentuation, vous devez configurer le cube de la même façon. Des problèmes peuvent se produire lorsque les paramètres de classement diffèrent. Pour obtenir un exemple et des solutions de contournement, consultez Les espaces dans une chaîne Unicode ont des résultats de traitement différents en fonction du classement. Pour en savoir plus sur le classement et le moteur de base de données, consultez Prise en charge du classement et unicode.

Types de classements

Analysis Services prend en charge deux types de classements :

• Collations Windows (versions _90 et _100)

  Les versions de classement Windows sont _90 (version antérieure non marquée) et la version _100 la plus récente. Seule la version _100 affiche le numéro de version dans le nom du classement :

  • latin1_general

  • latin1_general_100

  Un classement Windows trie les caractères en fonction des caractéristiques linguistiques et culturelles de la langue. Dans Windows, les classements dépassent les localisations (ou langues) qui leur sont associées, en raison de nombreuses langues partageant des alphabets et des règles communes pour le tri et la comparaison des caractères. Par exemple, 33 paramètres régionaux Windows, y compris tous les paramètres régionaux Portugais et Anglais, utilisent la page de codes Latin1 (1252) et suivent un ensemble commun de règles pour le tri et la comparaison des caractères.

  Note

  Lorsque vous décidez d’un classement, vous devez utiliser le même classement que celui utilisé par la base de données sous-jacente. Toutefois, si vous pouvez choisir, la version _100 est plus up-to-date et offre une convention de tri culturelle plus précise sur le plan linguistique.

• Classements binaires (BIN ou BIN2)

  Les classements binaires trient sur les points de code Unicode, et non sur les valeurs linguistiques. Par exemple, Latin1_General_BIN et Japanese_BIN produisent des résultats de tri identiques lorsqu’ils sont utilisés sur des données Unicode. Alors qu’un tri linguistique peut produire des résultats comme aAbBcCdD, un tri binaire serait ABCDabcd, car le point de code de tous les caractères majuscules est collectivement supérieur aux 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 pour SQL Server 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 exclusifs par rapport à d'autres options de tri; si vous souhaitez utiliser BIN ou BIN2, désactivez l'option de tri pour la sensibilité à l'accent. 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 de classement Windows et les suffixes associés pour SQL Server Analysis Services.

Ordre de tri (suffixe)	Description de l'ordre de tri
Binaire (_BIN) ou BIN2 (_BIN2)	Il existe deux types de classements binaires dans SQL Server ; les classements BIN plus anciens et les classements BIN2 les plus récents. Dans un classement BIN2, tous les caractères sont triés en fonction de leurs points de code. Dans un classement BIN, seul le premier caractère est trié en fonction du point de code, et les caractères restants sont triés en fonction de leurs valeurs d’octet. (Étant donné que la plateforme Intel est une architecture un peu endienne, les caractères de code Unicode sont toujours stockés par octets permutés.) Pour les classements binaires sur les types de données Unicode, les paramètres régionaux ne sont pas pris en compte dans les tris de données. Par exemple, Latin_1_General_BIN et Japanese_BIN produisent des résultats de tri identiques lorsqu’ils sont utilisés sur des données Unicode. L'ordre de tri binaire respecte la casse et les accents. L’ordre de tri Binaire est aussi le plus rapide.
Respect de la casse (_CS)	Fait la distinction entre les majuscules et les minuscules. Si cette option est sélectionnée, les lettres minuscules précèdent leurs versions majuscules. Vous pouvez explicitement définir le non-respect de la casse en spécifiant _CI. Les paramètres de casse spécifiques au classement ne s'appliquent pas aux identificateurs d'objets, tels que l'ID d'une dimension, le cube et d'autres objets. Pour plus d’informations, consultez les conseils et les meilleures pratiques de globalisation (Analysis Services ).
Sensible à l'accent (_AS)	Fait la distinction entre les caractères accentués et non accentués. Par exemple, 'a' n’est pas égal à 'ấ'. Si cette option n’est pas sélectionnée, SQL Server Analysis Services considère que les versions accentuées et nonaccentées des lettres sont identiques à des fins de tri. Vous pouvez définir explicitement l’accent-insensitivité en spécifiant _AI.
Respecter le jeu de caractères Kana (_KS)	Fait la distinction entre les deux types de caractères japonais kana : hiragana et katakana. Si cette option n’est pas sélectionnée, SQL Server Analysis Services considère que les caractères hiragana et katakana sont égaux à des fins de tri. Il n’existe aucun suffixe d’ordre de tri pour le tri non sensible aux kana.
Sensible à la largeur (_WS)	Fait la distinction entre un caractère d’un octet et le même caractère lorsqu’il est représenté sous la forme d’un caractère double octet. Si cette option n’est pas sélectionnée, SQL Server Analysis Services considère que la représentation à octet unique et double octet du même caractère doit être identique à des fins de tri. Il n’existe aucun suffixe d’ordre de tri pour le tri sans respect de la largeur.

Modifier la langue ou le classement par défaut sur l’instance

La langue et le classement par défaut sont établis pendant l’installation, mais peuvent être modifiés dans le cadre de la configuration 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 d’un service.

• Mettez à jour les 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 tri doivent être effectuées manuellement. Consultez Modifier le langage et le classement dans un modèle de données à l’aide de XMLA pour obtenir des conseils sur la propagation des modifications de classement dans tout le modèle.

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

Vous pouvez utiliser SQL Server Management Studio ou AMO PowerShell 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 avec le bouton droit sur le nom du serveur Propriétés | Langue/Collation.

2. Choisissez les options de tri. Pour sélectionner Binaire ou Binaire 2, désactivez d’abord la case à cocher pour Accentuation Sensible.

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

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

4. Redémarrez le service.

Modifier la langue ou le classement d'un cube

1. Dans l’Explorateur de solutions, double-cliquez sur le 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 pour l’un ou l’autre volet est le cube.

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

   La seule façon d’incorporer d’autres propriétés de langage et de classement sur des objets au sein du cube consiste à effectuer des traductions. Pour plus d’informations, consultez la prise en charge de la traduction dans Analysis Services .

Modifier le langage 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 que l’objet est créé. Les modifications suivantes apportées à ces propriétés doivent être effectuées manuellement. Une approche pour modifier rapidement le classement de plusieurs objets consiste à utiliser une commande ALTER sur un script XMLA.

Par défaut, le classement est défini une 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. Sinon, 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 que vous n’introduisez pas d’écarts entre la base de données et les fichiers sources utilisés pour la générer. Par exemple, vous pouvez utiliser XMLA pour modifier rapidement la langue ou le classement pour les tests de preuve de concept, mais ensuite suivre les modifications apportées au fichier source (voir Modifier la langue ou le classement sur un cube), redéployer la solution à l’aide des procédures d’exploitation existantes déjà en place.

1. Dans Management Studio, cliquez avec le bouton droit sur la base de données | Générer un script de la base de données | 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.

Améliorer les performances pour les locales en anglais via EnableFast1033Locale

Si vous utilisez l’identificateur de langue anglais (États-Unis) (0x0409 ou 1033) comme langue par défaut pour l’instance SQL Server Analysis Services, vous pouvez obtenir des avantages supplémentaires en définissant la propriété de configuration EnableFast1033Locale , une propriété de configuration avancée disponible uniquement pour cet identificateur de langue. La définition de la valeur de cette propriété sur true permet à SQL Server Analysis Services d’utiliser un algorithme plus rapide pour le hachage et la comparaison de chaînes. Pour plus d’informations sur la définition des propriétés de configuration, consultez 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’existe aucune conversion de données lors du traitement des données à partir de sources externes. Les données sont simplement stockées en tant qu’Unicode. Au moment de la requête, une conversion de GB18030 est effectuée via les bibliothèques clientes Analysis Services (en particulier, le fournisseur OLE DB MSOLAP.dll) lorsque des données de 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 GB18030. Pour plus d'informations, consultez Collation and Unicode Support.

Voir aussi

Scénarios de globalisation pour Analysis Services
Conseils et bonnes pratiques de globalisation (Analysis Services)
Prise en charge d’Unicode et des classements