Sugerencias de globalización y procedimientos recomendados (Analysis Services)

Se aplica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Importante: La información de este artículo solo se aplica a las soluciones de modelos multidimensionales .

Estas sugerencias e instrucciones pueden ayudar a aumentar la portabilidad de las soluciones de inteligencia empresarial multidimensional y evitar errores relacionados directamente con la configuración de idioma e intercalación.

Usar intercalaciones similares en toda la pila

Si es posible, intente usar la misma configuración de intercalación en SQL Server Analysis Services que usa para el motor de base de datos, esforzarse por la correspondencia en confidencialidad de ancho y distinción entre mayúsculas y minúsculas y la sensibilidad del acceso.

La intercalación de cada servicio tiene su propia configuración, con el valor predeterminado del motor de la base de datos establecido en SQL_Latin1_General_CP1_CI_AS y con Analysis Services establecido en Latin1_General_AS. Los valores predeterminados son compatibles en términos de distinción de mayúsculas y minúsculas, ancho y acentos. Tenga en cuenta que si cambia la configuración de intercalaciones en uno de estos elementos, pueden surgir problemas cuando las propiedades de intercalación difieran en aspectos fundamentales.

Aunque la configuración de intercalación tenga funciones equivalentes, puede encontrarse con un caso especial en el que cada servicio interprete de manera distinta un espacio vacío en algún lugar de una cadena.

El carácter de espacio es un “caso especial” porque se puede representar como un juego de caracteres de byte único (SBCS) o de doble byte (DBCS) en Unicode. En el motor relacional, dos cadenas compuestas separadas por un espacio, una en SBCS y la otra en DBCS, se consideran idénticas. En Analysis Services, durante el procesamiento, las dos cadenas compuestas no son idénticas, y la segunda instancia se marcará como duplicado.

Para ver más detalles y las soluciones alternativas sugeridas, consulte el tema sobre espacios en blanco en una cadena Unicode que tienen resultados de procesamiento diferentes en función de la intercalación.

Recomendaciones de intercalación comunes

Analysis Services siempre muestra la lista completa de todos los idiomas e intercalaciones disponibles; no filtra las intercalaciones según el idioma seleccionado. Asegúrese de elegir una combinación factible.

Algunas de las intercalaciones más comúnmente usadas son las de la lista siguiente.

Debe considerar esta lista como un punto de partida para una investigación más detallada y no como una recomendación definitiva que excluya otras opciones. Puede ser que una intercalación no específicamente recomendada sea la más adecuada para sus datos. La única forma de comprobar si los valores de datos se ordenan y comparan adecuadamente es realizar pruebas minuciosas. Como siempre, asegúrese de ejecutar las cargas de trabajo tanto de procesamiento como de consulta al probar la intercalación.

• Latin1_General_100_AS se suele usar para las aplicaciones que usan los 26 caracteres del alfabeto ISO de latín básico.

• Los idiomas de Norte de Europa que utilizan letras escandinavas (como ø) pueden utilizar Finnish_Swedish_100.

• Los idiomas de la Europa del Este, como el ruso, a menudo usan Cyrillic_General_100.

• Las intercalaciones y el idioma chino varían según la región, pero normalmente se utiliza el chino simplificado o el chino tradicional.

  En RPC y Singapur, Microsoft Support acostumbra a preferir el chino simplificado con pinyin como orden de clasificación. Las intercalaciones recomendadas son Chinese_PRC (para SQL Server 2000), Chinese_PRC_90 (para SQL Server 2005) o Chinese_Simplified_Pinyin_100 (para SQL Server 2008 y versiones posteriores).

  En Taiwán, es más habitual ver chino tradicional con el criterio de ordenación recomendado basado en el número de trazos: Chinese_Taiwan_Stroke (para SQL Server 2000), Chinese_Taiwan_Stroke_90 (para SQL Server 2005) o Chinese_Traditional_Stroke_Count_100 (para SQL Server 2008 y versiones posteriores).

  Otras regiones (como la región administrativa especial de Hong Kong y la región administrativa especial de Macao) también usan chino tradicional. Para las intercalaciones, en la RAE de Hong Kong, no es inusual ver Chinese_Hong_Kong_Stroke_90 (en SQL Server 2005). En la RAE de Macao, Chinese_Traditional_Stroke_Count_100 (en SQL Server 2008 y versiones posteriores) se usa con bastante frecuencia.

• Para el japonés, la intercalación utiliza con más frecuencia es Japanese_CI_AS. Japanese_XJIS_100 se usa en instalaciones que admiten JIS2004. Japanese_BIN2 suele aparecer en proyectos de migración de datos, con datos que se originan en plataformas que no son de Windows o en orígenes de datos distintos al motor de base de datos relacional de SQL Server.

  Japanese_Bushu_Kakusu_100 raramente aparece en servidores que ejecutan cargas de trabajo de Analysis Services.

• Para el coreano se recomienda Korean_100. Aunque en la lista sigue apareciendo Korean_Wansung_Unicode, ya no se utiliza.

Distinción entre mayúsculas y minúsculas de los identificadores de objetos

Desde SQL Server 2012 SP2, la distinción entre mayúsculas y minúsculas de los identificadores de objetos se exige independientemente de la intercalación, pero el comportamiento varía según el idioma:

Implicaciones de la distinción entre mayúsculas y minúsculas para los identificadores de objetos

Solo los identificadores de objetos, y no los nombres de objetos, están sujetos a los comportamientos de mayúsculas y minúsculas que se describen en la tabla. Si ve un cambio en el funcionamiento de la solución (una comparación del antes y el después de instalar SQL Server 2012 SP2 o una versión posterior), probablemente se trate de un problema de procesamiento. Las consultas no se ven afectadas por los identificadores de objeto. En los dos lenguajes de consulta (DAX y MDX), el motor de fórmulas utiliza el nombre del objeto (no el identificador).

Pruebas de configuración regional con Excel, SQL Server Profiler y SQL Server Management Studio

Al probar las traducciones, la conexión debe especificar el LCID de la traducción.

Puede hacerlo manualmente, editando el archivo .odc para incluir la propiedad de cadena de conexión del identificador de configuración regional. Pruebe con la base de datos multidimensional de muestra de Adventure Works.

• Busque los archivos .odc existentes. Cuando encuentre el de la base de datos multidimensional de Adventure Works, haga clic con el botón derecho en el archivo para abrirlo en el Bloc de notas.

• Agregue Locale Identifier=1036 a la cadena de conexión. Guarde y cierre el archivo.

• Abrir Excel | Datos | Conexiones existentes. Filtre la lista para que solo aparezcan los archivos de las conexiones de este equipo. Busque la conexión de Adventure Works (observe el nombre con atención: puede que haya más de una). Abrir la conexión.

  Debería ver las traducciones al francés de la base de datos de muestra de Adventure Works.

  tabla dinámica de

A modo de seguimiento, puede usar SQL Server Profiler para confirmar la configuración regional. Haga clic en un evento de Session Initialize y, luego, observe la lista de propiedades del área de texto inferior para buscar <localeidentifier>1036</localeidentifier>.

En Management Studio, puede especificar el identificador de configuración regional en una conexión de servidor.

• En Explorador de objetos | Conectar | Analysis Services | Opciones, haga clic en la pestaña Parámetros de conexión adicionales.

• Escriba Locale Identifier=1036 y, a continuación, haga clic en Conectar.

• Ejecute una consulta MDX en la base de datos de Adventure Works. Los resultados de la consulta deberían ser las traducciones al francés.

  

Escritura de consultas MDX en una solución que contiene traducciones

Las traducciones proporcionan información para mostrar los nombres de los objetos SQL Server Analysis Services, pero los identificadores de los mismos objetos no se traducen. Siempre que sea posible, use los identificadores y las claves para SQL Server Analysis Services objetos en lugar de los nombres y subtítulos traducidos. Por ejemplo, utilice claves de miembro en lugar de nombres de miembro en los scripts e instrucciones MDX (Expresiones multidimensionales) con el fin de asegurar la portabilidad entre diferentes idiomas.

Escritura de consultas MDX que contengan valores de fecha y hora

Las siguientes sugerencias permiten hacer que las consultas MDX basadas en el tiempo y en la fecha sean más portables en los diferentes idiomas:

1. Utilizar elementos numéricos para las comparaciones y operaciones

   Cuando realice operaciones y comparaciones de día de la semana y mes, utilice los elementos numéricos de hora y fecha en lugar de los equivalentes de cadena (por ejemplo, utilice MonthNumberofYear en lugar de MonthName). Los valores numéricos se ven menos afectados por las diferencias en las traducciones de idiomas.

2. Utilizar los equivalentes de cadena en un conjunto de resultados

   Al generar conjuntos de resultados vistos por los usuarios finales, plantéese la posibilidad de utilizar una cadena (como MonthName) para que la audiencia multilingüe pueda utilizar las traducciones proporcionadas.

3. Usar formatos de fecha ISO para información de fecha y hora universal

   Un experto en Analysis Services tiene esta recomendación: “Siempre uso el formato de fecha ISO, aaaa-mm-dd, para las cadenas de fecha que paso a las consultas en SQL o MDX, porque no es ambiguo y funciona sea cual sea la configuración regional del servidor o del cliente. Sé que el servidor debería recurrir a su configuración regional al analizar formatos de fecha ambiguos, pero también creo que si hay una opción que no da pie a varias interpretaciones, lo mejor es elegir esa opción en cualquier caso”.

4. Use la función Format para aplicar un formato específico, con independencia de la configuración regional de idioma.

   La siguiente consulta MDX, extraída de una entrada de foro, muestra cómo utilizar el formato para devolver las fechas en un formato específico, independientemente de la configuración regional subyacente.

   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 también

Escenarios de globalización para Analysis Services
Escribir instrucciones Transact-SQL internacionales