Dicas de globalização e práticas recomendadas (Analysis Services)

Aplica-se a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Importante: As informações neste artigo aplicam-se apenas a soluções de modelos multidimensionais .

Essas dicas e diretrizes podem ajudar a aumentar a portabilidade de suas soluções multidimensionais de business intelligence e evitar erros diretamente relacionados às configurações de idioma e agrupamento.

Use agrupamentos semelhantes em toda a pilha

Se possível, tente usar as mesmas configurações de agrupamento no SQL Server Analysis Services que você usa para o mecanismo de banco de dados, procurando correspondência em sensibilidade de largura e maiúsculas e minúsculas e sensibilidade de acesso.

Cada serviço tem suas próprias configurações de agrupamento, com o mecanismo de banco de dados padrão definido como SQL_Latin1_General_CP1_CI_AS e o Analysis Services definido como Latin1_General_AS. Os padrões são compatíveis em termos de sensibilidade a maiúsculas e minúsculas, largura e acento. Esteja avisado de que, se você variar as configurações de qualquer agrupamento, poderá ter problemas quando as propriedades de agrupamento divergirem de maneiras fundamentais.

Mesmo quando as configurações de agrupamento são funcionalmente equivalentes, você pode se deparar com um caso especial em que um espaço vazio em qualquer lugar dentro de uma cadeia de caracteres é interpretado de forma diferente por cada serviço.

O caractere de espaço é um 'caso especial' porque pode ser representado como um byte único (SBCS) ou conjunto de caracteres de byte duplo (DBCS) em Unicode. No mecanismo relacional, duas cadeias de caracteres compostas separadas por um espaço -- uma usando SBCS, a outra em DBCS -- são consideradas idênticas. No Analysis Services, durante o processamento, as mesmas duas cadeias de caracteres compostas não são idênticas e a segunda instância será sinalizada como uma duplicata.

Para obter mais detalhes e sugestões de soluções alternativas, consulte Espaços em branco em uma cadeia de caracteres Unicode têm resultados de processamento diferentes com base no agrupamento.

Recomendações comuns de agrupamento

O Analysis Services sempre apresenta a lista completa de todos os idiomas e agrupamentos disponíveis; ele não filtra os agrupamentos com base no idioma selecionado. Certifique-se de escolher uma combinação viável.

Alguns dos agrupamentos mais comumente usados incluem aqueles na lista a seguir.

Deve considerar esta lista como um ponto de partida para uma investigação mais aprofundada, em vez de uma recomendação definitiva que exclui outras opções. Você pode achar que um agrupamento não especificamente recomendado é o que funciona melhor para seus dados. O teste completo é a única maneira de verificar se os valores dos dados são classificados e comparados adequadamente. Como sempre, certifique-se de executar as cargas de trabalho de processamento e consulta ao testar o agrupamento.

Latin1_General_100_AS é frequentemente usado para aplicações que usam os 26 caracteres do alfabeto latino básico ISO.
As línguas do norte da Europa que incluem letras escandinavas (como ø) podem usar Finnish_Swedish_100.
As línguas da Europa Oriental, como o russo, usam frequentemente Cyrillic_General_100.
O idioma chinês e os agrupamentos variam de acordo com a região, mas geralmente são chineses simplificados ou chineses tradicionais.

Na RPC e em Singapura, o Suporte da Microsoft tende a ver o chinês simplificado, com o Pinyin como a ordem de classificação preferida. Os agrupamentos recomendados são Chinese_PRC (para SQL Server 2000), Chinese_PRC_90 (para SQL Server 2005) ou Chinese_Simplified_Pinyin_100 (para SQL Server 2008 e posterior).

Em Taiwan, é mais comum ver Chinês tradicional com a ordem de classificação recomendada é baseada em Contagem de Traçados: Chinese_Taiwan_Stroke (para SQL Server 2000), Chinese_Taiwan_Stroke_90 (para SQL Server 2005) ou Chinese_Traditional_Stroke_Count_100 (para SQL Server 2008 e posterior).

Outras regiões (como a Região Administrativa Especial de Hong Kong e a Região Administrativa Especial de Macau) também utilizam o chinês tradicional. Para agrupamentos, na RAE de Hong Kong, não é incomum ver Chinese_Hong_Kong_Stroke_90 (no SQL Server 2005). Na RAEM, a Chinese_Traditional_Stroke_Count_100 (no SQL Server 2008 e posterior) é utilizada com bastante frequência.
Para o japonês, o agrupamento mais usado é o Japanese_CI_AS. Japanese_XJIS_100 é usado em instalações de suporte JIS2004. Japanese_BIN2 normalmente é visto em projetos de migração de dados, com dados originários de plataformas não Windows ou de fontes de dados diferentes do mecanismo de banco de dados relacional do SQL Server.

Japanese_Bushu_Kakusu_100 raramente é visto em servidores que executam cargas de trabalho do Analysis Services.
Korean_100 é recomendado para coreano. Embora Korean_Wansung_Unicode ainda esteja disponível na lista, ele foi preterido.

Diferenciação de maiúsculas e minúsculas dos identificadores de objeto

A partir do SQL Server 2012 SP2, a diferenciação de maiúsculas e minúsculas das IDs de objeto é imposta independentemente do agrupamento, mas o comportamento varia de acordo com o idioma:

Script de linguagem	Sensível às maiúsculas e minúsculas
Alfabeto latino básico	Os identificadores de objeto expressos em alfabeto latino (qualquer uma das 26 letras maiúsculas ou minúsculas em inglês) são tratados como insensíveis a maiúsculas e minúsculas, independentemente do agrupamento. Por exemplo, os seguintes IDs de objeto são considerados idênticos: 54321abcdef, 54321ABCDEF, 54321AbCdEf. Internamente, o Analysis Services trata os caracteres na cadeia de caracteres como se todos estivessem em maiúsculas e, em seguida, executa uma comparação de bytes simples que é independente do idioma. Observe que apenas os 26 caracteres são afetados. Se o idioma for europeu ocidental, mas usar caracteres escandinavos, o caractere adicional não será maiúsculo.
Cirílico, Grego, Copta, Arménio	Os identificadores de objeto em script bicameral não latino, como o cirílico, são sempre sensíveis a maiúsculas e minúsculas. Por exemplo, Измерение e измерение são considerados dois valores distintos, embora a única diferença seja o caso da primeira letra.

Script de linguagem

Sensível às maiúsculas e minúsculas

Alfabeto latino básico

Os identificadores de objeto expressos em alfabeto latino (qualquer uma das 26 letras maiúsculas ou minúsculas em inglês) são tratados como insensíveis a maiúsculas e minúsculas, independentemente do agrupamento. Por exemplo, os seguintes IDs de objeto são considerados idênticos: 54321abcdef, 54321ABCDEF, 54321AbCdEf. Internamente, o Analysis Services trata os caracteres na cadeia de caracteres como se todos estivessem em maiúsculas e, em seguida, executa uma comparação de bytes simples que é independente do idioma.

Observe que apenas os 26 caracteres são afetados. Se o idioma for europeu ocidental, mas usar caracteres escandinavos, o caractere adicional não será maiúsculo.

Cirílico, Grego, Copta, Arménio

Os identificadores de objeto em script bicameral não latino, como o cirílico, são sempre sensíveis a maiúsculas e minúsculas. Por exemplo, Измерение e измерение são considerados dois valores distintos, embora a única diferença seja o caso da primeira letra.

Implicações da diferenciação de maiúsculas e minúsculas para identificadores de objeto

Somente identificadores de objeto, e não nomes de objeto, estão sujeitos aos comportamentos de invólucro descritos na tabela. Se você vir uma alteração na forma como sua solução funciona (uma comparação antes e depois -- após a instalação do SQL Server 2012 SP2 ou posterior), provavelmente será um problema de processamento. As consultas não são afetadas por identificadores de objeto. Para ambas as linguagens de consulta (DAX e MDX), o mecanismo de fórmula usa o nome do objeto (não o identificador).

Observação

As alterações de código relacionadas à diferenciação de maiúsculas e minúsculas têm sido uma mudança importante para alguns aplicativos.

Teste de localidade usando Excel, SQL Server Profiler e SQL Server Management Studio

Ao testar traduções, a conexão deve especificar o LCID da tradução.

Você pode fazer isso editando manualmente o arquivo .odc para incluir a propriedade da cadeia de conexão do identificador de localidade. Experimente isso com o banco de dados multidimensional de exemplo da Adventure Works.

Procure arquivos .odc existentes. Quando você encontrar o do Adventure Works multidimensional, clique com o botão direito do mouse no arquivo para abri-lo no Bloco de Notas.
Adicionar Locale Identifier=1036 à cadeia de conexão. Salve e feche o arquivo.
Abrir o Excel | Dados | Conexões existentes. Filtre a lista para apenas conectar arquivos neste computador. Encontre a conexão para a Adventure Works (olhe para o nome com cuidado; você pode ter mais de um). Abra a conexão.

Você deve ver as traduções para francês do banco de dados de exemplo da Adventure Works.

Como acompanhamento, você pode usar o SQL Server Profiler para confirmar a localidade. Clique em um Session Initialize evento e, em seguida, examine a lista de propriedades na área de texto abaixo para encontrar <localeidentifier>1036</localeidentifier>.

No Management Studio, você pode especificar o identificador de localidade em uma conexão de servidor.

No Pesquisador de Objetos | Ligar | | Opções, clique na guia Parâmetros de conexão adicionais.
Entre Locale Identifier=1036 e clique em Conectar.
Execute uma consulta MDX no banco de dados da Adventure Works. Os resultados da consulta devem ser as traduções francesas.

Escrevendo consultas MDX em uma solução que contém traduções

As traduções fornecem informações de exibição para os nomes dos objetos do SQL Server Analysis Services, mas os identificadores dos mesmos objetos não são traduzidos. Sempre que possível, use os identificadores e chaves para objetos do SQL Server Analysis Services em vez das legendas e nomes traduzidos. Por exemplo, use chaves de membro em vez de nomes de membros para instruções e scripts MDX (Multidimensional Expressions) para garantir a portabilidade em vários idiomas.

Observação

Lembre-se de que os nomes de objetos tabulares não diferenciam maiúsculas de minúsculas, independentemente do agrupamento. Os nomes de objetos multidimensionais, por outro lado, seguem a sensibilidade a maiúsculas e minúsculas do agrupamento. Como apenas nomes de objetos multidimensionais diferenciam maiúsculas de minúsculas, certifique-se de que todas as consultas MDX que fazem referência a objetos multidimensionais estejam inseridas corretamente.

Escrevendo consultas MDX contendo valores de data e hora

As sugestões a seguir para tornar suas consultas MDX baseadas em data e hora mais portáteis em diferentes idiomas:

Usar partes numéricas para comparações e operações

Ao executar comparações e operações de mês e dia da semana, use as partes numéricas de data e hora em vez dos equivalentes de cadeia de caracteres (por exemplo, use MonthNumberofYear em vez de MonthName). Os valores numéricos são menos afetados pelas diferenças nas traduções linguísticas.
Usar equivalentes de cadeia de caracteres em um conjunto de resultados

Ao criar conjuntos de resultados vistos pelos usuários finais, considere usar a cadeia de caracteres (como MonthName) para que seu público multilíngue possa se beneficiar das traduções fornecidas.
Use formatos de data ISO para informações universais de data e hora

Um especialista do Analysis Services tem esta recomendação: "Eu sempre uso o formato de data ISO aaaa-mm-dd para quaisquer cadeias de caracteres de data que eu passar para consultas em SQL ou MDX porque é inequívoco e funcionará independentemente das configurações regionais do cliente ou servidor. Eu concordo que o servidor deve deferir suas configurações regionais ao analisar um formato de data ambíguo, mas também acho que, se você tem uma opção que não está aberta à interpretação, é melhor escolher isso de qualquer maneira".
Use a função Formato para impor um formato específico, independentemente das configurações de idioma regionais

A consulta MDX a seguir, emprestada de uma postagem do fórum, ilustra como usar Format para retornar datas em um formato específico, independentemente das configurações regionais subjacentes.
```
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]  
```

Consulte também

Cenários de globalização para o Analysis Services
Escrever declarações de Transact-SQL internacionais

Comentários

Esta página foi útil?

Last updated on 2025-09-05