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 se aplicam apenas a soluções de modelo 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 linguagem e ordenação.

Usar ordenações semelhantes em toda a pilha

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

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

Mesmo quando as configurações de ordenação são funcionalmente equivalentes, você pode encontrar 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 SBCS (byte único) ou um conjunto de caracteres de byte duplo (DBCS) no Unicode. No mecanismo relacional, duas cadeias de caracteres compostas separadas por um espaço - uma usando SBCS, a outra no 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 duplicada.

Para obter mais detalhes e soluções alternativas sugeridas, consulte Blanks em uma cadeia de caracteres Unicode ter resultados de processamento diferentes com base na ordenação.

Recomendações comuns de ordenação

O Analysis Services sempre apresenta a lista completa de todos os idiomas e ordenações disponíveis; ele não filtra as ordenações com base no idioma selecionado. Escolha uma combinação viável.

Algumas das ordenações mais usadas incluem as da lista a seguir.

Você deve considerar essa lista como um ponto de partida para uma investigação mais aprofundada, em vez de uma recomendação definitiva que exclua outras opções. Você pode achar que uma ordenação não recomendada especificamente é a que funciona melhor para seus dados. O teste completo é a única maneira de verificar se os valores de dados são classificados e comparados adequadamente. Como sempre, execute cargas de trabalho de processamento e consulta ao testar a ordenação.

• Latin1_General_100_AS geralmente é usado para aplicativos que usam os 26 caracteres do alfabeto latino básico iso.

• Idiomas norte-europeus que incluem letras escandinavas (como ø) podem usar Finnish_Swedish_100.

• Idiomas do Leste Europeu, como o russo, muitas vezes usam Cyrillic_General_100.

• O idioma chinês e as ordenações variam de acordo com a região, mas geralmente são chinês simplificado ou chinês tradicional.

  Na PRC e em Cingapura, o Suporte da Microsoft tende a ver chinês simplificado, com Pinyin como a ordem de classificação preferencial. As ordenações recomendadas 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ços: 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 Macao) também usam chinês tradicional. Para ordenações, no SAR de Hong Kong, não é incomum ver Chinese_Hong_Kong_Stroke_90 (no SQL Server 2005). Em Macao SAR, Chinese_Traditional_Stroke_Count_100 (no SQL Server 2008 e posterior) é usado com bastante frequência.

• Para japonês, a ordenação mais usada é Japanese_CI_AS. Japanese_XJIS_100 é usado em instalações que dão suporte a JIS2004. Japanese_BIN2 normalmente é visto em projetos de migração de dados, com dados provenientes 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, ela foi preterida.

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

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

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

Somente os identificadores de objeto, e não os nomes de objeto, estão sujeitos aos comportamentos de maiúsculas e minúsculas descritos na tabela. Se você vir uma alteração em como sua solução funciona (antes e depois da comparação -- depois de instalar o 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).

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 de cadeia de conexão do identificador de localidade. Experimente isso com o banco de dados multidimensional de exemplo do Adventure Works.

• Pesquise arquivos .odc existentes. Quando você encontrar aquele para Adventure Works multidimensional, clique com o botão direito do mouse no arquivo para abri-lo no Bloco de Notas.

• Adicione Locale Identifier=1036 à cadeia de conexão. Salve e feche o arquivo.

• Abrir o Excel | Dados | Conexões existentes. Filtre a lista apenas para arquivos de conexões neste computador. Localize a conexão para o Adventure Works (examine o nome com cuidado; você pode ter mais de um). Abra a conexão.

  Você deve ver as traduções em francês do banco de dados de exemplo do 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 localizar <localeidentifier>1036</localeidentifier>.

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

• No Pesquisador de Objetos | Ligar | Analysis Services | Opções, clique na guia Parâmetros de Conexão Adicionais .

• Insira Locale Identifier=1036 e clique em Conectar.

• Execute uma consulta MDX no banco de dados adventure works. Os resultados da consulta devem ser as traduções em francês.

  

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 as 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 membro para instruções MDX (Expressões Multidimensionais) e scripts para garantir a portabilidade em vários idiomas.

Escrevendo consultas MDX que contêm valores de data e hora

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

1. 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 de data e hora numéricas 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 de idioma.

2. 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.

3. Usar 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, ou seja,mm-dd para todas as cadeias de caracteres de data que passo para consultas no SQL ou MDX porque ela é inequívoca e funcionará independentemente das configurações regionais do cliente ou do servidor. Concordo que o servidor deve adiar suas configurações regionais ao analisar um formato de data ambíguo, mas também acho que se você tiver uma opção que não esteja aberta à interpretação, é melhor escolher isso de qualquer maneira".

4. Use a função Formatar para impor um formato específico, independentemente das configurações de idioma regional

   A consulta MDX a seguir, emprestada de uma postagem do fórum, ilustra como usar o Formato 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 instruções de Transact-SQL internacionais