Conseils et bonnes pratiques de globalisation (Analysis Services)

S’applique à : Multidimensionnel uniquement

Ces conseils et recommandations peuvent aider à augmenter la portabilité de vos solutions décisionnels et à éviter les erreurs directement liées aux paramètres de langue et de classement.

• Utiliser des classements similaires dans toute la pile

• Recommandations de classement courantes

• Respect de la casse des identificateurs d’objet

• Tests de paramètres régionaux à l’aide d’Excel et sql Server Profiler

• Écriture de requêtes MDX dans une solution contenant des traductions

• Écriture de requêtes MDX contenant des valeurs de date et d’heure

Utiliser des classements similaires dans toute la stack

Si possible, essayez d’utiliser les mêmes paramètres de classement dans Analysis Services que ceux que vous utilisez pour le moteur de base de données, en cherchant à correspondre dans la sensibilité à la largeur, à la casse, et à l'accès.

Chaque service a ses propres paramètres de classement, avec le moteur de base de données par défaut défini sur SQL_Latin1_General_CP1_CI_AS et Analysis Services défini sur Latin1_General_AS. Les valeurs par défaut sont compatibles en termes de casse, de largeur et de sensibilité aux accents. Soyez averti que si vous modifiez les paramètres de l’un ou l’autre classement, vous pouvez rencontrer des problèmes lorsque les propriétés de classement diffèrent de manière fondamentale.

Même lorsque les paramètres de classement sont fonctionnellement équivalents, vous pouvez entrer dans un cas spécial où un espace vide n’importe où dans une chaîne est interprété différemment par chaque service.

Le caractère d’espace est un « cas spécial », car il peut être représenté sous forme d’un jeu de caractères à octet unique (SBCS) ou d’un jeu de caractères double octet (DBCS) dans Unicode. Dans le moteur relationnel, deux chaînes composées séparées par un espace (l’une utilisant SBCS, l’autre dans DBCS) sont considérées comme identiques. Dans Analysis Services, pendant le traitement, les deux mêmes chaînes composées ne sont pas identiques et la deuxième instance est marquée comme dupliquée.

Pour plus d’informations et des solutions de contournement suggérées, consultez Les espaces dans une chaîne Unicode ont des résultats de traitement différents en fonction du classement.

Recommandations de classement courantes

Analysis Services présente toujours la liste complète de toutes les langues et classements disponibles ; il ne filtre pas les classements en fonction de la langue que vous avez sélectionnée. Veillez à choisir une combinaison utilisable.

Certains des classements les plus couramment utilisés incluent ceux de la liste suivante.

Vous devez considérer cette liste comme un point de départ pour un examen approfondi, plutôt qu’une recommandation définitive qui exclut d’autres options. Vous pouvez constater qu’un classement non spécifiquement recommandé est celui qui fonctionne le mieux pour vos données. Les tests approfondis sont le seul moyen de vérifier si les valeurs de données sont triées et comparées de manière appropriée. Comme toujours, veillez à exécuter simultanément les charges de traitement et de requête lors du test du classement.

• Latin1_General_100_AS est souvent utilisé pour les applications qui utilisent les 26 caractères de l’alphabet latin de base ISO.

• Les langues nord-européennes qui incluent des lettres scandinaves (telles que ø) peuvent utiliser Finnish_Swedish_100.

• Les langues de l’Europe orientale, comme le russe, utilisent souvent Cyrillic_General_100.

• La langue et les classements chinois varient selon la région, mais sont généralement chinois simplifié ou chinois traditionnel.

  Dans PRC et Singapour, le support Microsoft a tendance à voir chinois simplifié, avec Pinyin comme ordre de tri préféré. Les classements recommandés sont Chinese_PRC (pour SQL Server 2000), Chinese_PRC_90 (pour SQL Server 2005) ou Chinese_Simplified_Pinyin_100 (pour SQL Server 2008 et versions ultérieures).

  À Taiwan, il est plus courant de voir le chinois traditionnel, où l'ordre de tri recommandé est basé sur le nombre de traits : Chinese_Taiwan_Stroke (pour SQL Server 2000), Chinese_Taiwan_Stroke_90 (pour SQL Server 2005) ou Chinese_Traditional_Stroke_Count_100 (pour SQL Server 2008 et versions ultérieures).

  D’autres régions (telles que la région administrative spéciale de Hong Kong et la région administrative spéciale de Macao) utilisent également le chinois traditionnel. Pour les classements, dans la Région administrative spéciale de Hong Kong, il n'est pas rare de voir Chinese_Hong_Kong_Stroke_90 (sur SQL Server 2005). À Macao SAR, Chinese_Traditional_Stroke_Count_100 (sur SQL Server 2008 et versions ultérieures) est utilisé assez souvent.

• Le classement le plus couramment utilisé pour le japonais est Japanese_CI_AS. Japanese_XJIS_100 est utilisé dans les installations prenant en charge JIS2004. Japanese_BIN2 est généralement vu dans les projets de migration de données, avec des données provenant de plateformes non Windows ou provenant de sources de données autres que le moteur de base de données relationnelle SQL Server.

  Japanese_Bushu_Kakusu_100 est rarement vu dans les serveurs qui exécutent des charges de travail Analysis Services.

• Korean_100 est recommandé pour le coréen. Bien que Korean_Wansung_Unicode soit toujours disponible dans la liste, elle a été déconseillée.

Sensibilité à la casse des identificateurs d’objet

À compter de SQL Server 2012 SP2, la sensibilité à la casse des ID d'objet est imposée indépendamment de la collation, mais le comportement varie selon la langue :

Les conséquences de la distinction entre majuscules et minuscules pour les identificateurs d’objet

Seuls les identificateurs d’objet, et non les noms d’objets, sont soumis aux comportements de casse décrits dans le tableau. Si vous voyez un changement dans le fonctionnement de votre solution (avant et après comparaison - après l’installation de SQL Server 2012 SP2 ou version ultérieure), il s’agit probablement d’un problème de traitement. Les requêtes ne sont pas affectées par les identificateurs d’objet. Pour les deux langages de requête (DAX et MDX), le moteur de formule utilise le nom de l’objet (et non l’identificateur).

Tests de paramètres régionaux à l’aide d’Excel, SQL Server Profiler et SQL Server Management Studio

Lors du test des traductions, la connexion doit spécifier le LCID de la traduction. Comme documenté dans Obtenir une langue différente de SSAS dans Excel, vous pouvez utiliser Excel pour tester vos traductions.

Pour ce faire, modifiez manuellement le fichier .odc pour inclure la propriété de chaîne de connexion avec l'identificateur de paramètres régionaux. Essayez cette opération avec l’exemple de base de données multidimensionnelle Adventure Works.

• Recherchez les fichiers .odc existants. Lorsque vous trouvez celui pour Adventure Works multidimensionnel, cliquez avec le bouton droit sur le fichier pour l’ouvrir dans le Bloc-notes.

• Ajoutez Locale Identifier=1036 à la chaîne de connexion. Enregistrez et fermez le fichier.

• Ouvrir Excel | Données | Connexions existantes. Filtrez la liste pour uniquement connecter des fichiers sur cet ordinateur. Recherchez la connexion pour Adventure Works (examinez attentivement le nom ; vous en avez peut-être plusieurs). Ouvrir la connexion.

  Vous devez voir les traductions françaises de l’exemple de base de données Adventure Works.

  

En guise de suivi, vous pouvez utiliser SQL Server Profiler pour confirmer les paramètres régionaux. Cliquez sur un Session Initialize événement, puis examinez la liste des propriétés dans la zone de texte ci-dessous pour rechercher <localeidentifier>1036</localeidentifier>.

Dans Management Studio, vous pouvez spécifier l’identificateur de paramètres régionaux sur une connexion de serveur.

• Dans l’Explorateur d’objets | Connexion | Analysis Services | Options, cliquez sur l’onglet Paramètres de connexion supplémentaires.

• Entrez Local Identifier=1036 , puis cliquez sur Se connecter.

• Exécutez une requête MDX sur la base de données Adventure Works. Les résultats de la requête doivent être les traductions françaises.

  

Écriture de requêtes MDX dans une solution contenant des traductions

Les traductions fournissent des informations d’affichage pour les noms des objets Analysis Services, mais les identificateurs des mêmes objets ne sont pas traduits. Dans la mesure du possible, utilisez les identificateurs et les clés des objets Analysis Services au lieu des légendes et noms traduits. Par exemple, utilisez des clés de membre au lieu de noms de membres pour les instructions et scripts MDX (Multidimensional Expressions) pour garantir la portabilité entre plusieurs langages.

Écriture de requêtes MDX contenant des valeurs de date et d’heure

Les suggestions suivantes pour rendre vos requêtes MDX de date et d’heure plus portables dans différents langages :

1. Utiliser des parties numériques pour les comparaisons et les opérations

   Lorsque vous effectuez des comparaisons et des opérations de mois et de jour de semaine, utilisez les parties de date et d’heure numériques au lieu des équivalents de chaîne (par exemple, utilisez MonthNumberofYear au lieu de MonthName). Les valeurs numériques sont les moins affectées par les différences dans les traductions linguistiques.

2. Utiliser des équivalents de chaîne dans un jeu de résultats

   Lorsque vous créez des jeux de résultats vus par les utilisateurs finaux, envisagez d’utiliser la chaîne (par exemple MonthName) afin que votre audience multilingue puisse tirer parti des traductions que vous avez fournies.

3. Utiliser des formats de date ISO pour les informations de date et d’heure universelles

   Un expert Analysis Services a cette recommandation : « J’utilise toujours le format de date ISO aaaa-mm-dd pour toutes les chaînes de date que je passe à des requêtes dans SQL ou MDX, car il est non ambigu et fonctionne indépendamment des paramètres régionaux du client ou du serveur. Je suis d’accord que le serveur doit se conformer à ses paramètres régionaux lors de l’analyse d’un format de date ambiguë, mais je pense également que s’il existe une option qui n’est pas ouverte à l’interprétation, il est préférable de choisir cette option de toute manière.

4. Use the Format function to enforce a specific format, regardless of regional language settings

   La requête MDX suivante, empruntée à partir d’un billet de forum, montre comment utiliser format pour retourner des dates dans un format spécifique, indépendamment des paramètres régionaux sous-jacents.

   Voir le billet d'origine sur SSAS 2012 génère des dates non valides (billet de forum sur Network Steve.

   WITH MEMBER [LinkTimeAdd11Date_Manual] as Format(dateadd("d",15,"2014-12-11"), "mm/dd/yyyy")  
   member [LinkTimeAdd15Date_Manual] as Format(dateadd("d",11,"2014-12-13"), "mm/dd/yyyy")  
   SELECT  
   { [LinkTimeAdd11Date_Manual]  
   ,[LinkTimeAdd15Date_Manual]  
   }  
   ON COLUMNS   
   FROM [Adventure Works]  
   
   

Voir aussi

Scénarios de globalisation pour Analysis Services Multidimensionnel
Rédiger des instructions Transact-SQL internationales