Советы и рекомендации по глобализации (службы Analysis Services)

Статья
07/04/2023

Применимо к: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Важно: Сведения в этой статье относятся только к решениям многомерных моделей.

Эти советы и рекомендации помогут повысить переносимость решений многомерной бизнес-аналитики и избежать ошибок, непосредственно связанных с языком и параметрами сортировки.

Использование одинаковых параметров сортировки во всем стеке

По возможности попробуйте использовать те же параметры сортировки в SQL Server Analysis Services, которые используются для ядра СУБД, стремясь к соответствию с учетом ширины и регистра, а также с учетом доступа.

Каждая служба имеет свои собственные параметры сортировки. По умолчанию для ядра СУБД используется SQL_Latin1_General_CP1_CI_AS, а для Analysis Services — Latin1_General_AS. Значения по умолчанию совместимы с точки зрения чувствительности к регистру, ширине и диакритическим знакам. Помните, что, если изменить какие-либо параметры сортировки, могут возникнуть проблемы, если свойства параметров сортировки существенно отличаются.

Даже если параметры сортировки функционально эквивалентны, может возникнуть особый случай, где пустое место в любом месте строки интерпретируется каждой службой по-разному.

Символ пробела — это особый случай, так как он может быть представлен однобайтовым (SBCS) или двухбайтовым (DBCS) набором символов в кодировке Юникод. В реляционном механизме две составные строки, разделенные пробелом (одна из которых использует SBCS, а другая —DBCS), считаются идентичными. Во время обработки в службах Analysis Services те же составные строки не совпадают, а второй экземпляр будет отмечен как дубликат.

Дополнительные сведения и рекомендуемые пути устранения проблем см. в разделе Пробелы в строке Юникода обрабатываются по-разному в зависимости от параметров сортировки.

Общие рекомендации для параметров сортировки

В Analysis Services всегда представлен полный список всех доступных языков и параметров сортировки; список параметров сортировки не отфильтровывается в зависимости от выбранного языка. Обязательно выберите пригодное для работы сочетание.

Некоторые из наиболее часто используемых параметров сортировки перечислены в следующем списке.

Этот список следует считать основой для дальнейшей работы, но не окончательной рекомендацией, исключающей другие варианты. Может оказаться, что для ваших данных лучше всего подходят параметры сортировки, не рекомендованные явным образом. Тщательное тестирование является единственным способом проверить правильность сортировки и сравнения данных. При тестировании параметров сортировки всегда запускайте нагрузку по обработке и по запросам.

Latin1_General_100_AS часто используется для приложений, использующих 26 букв основного латинского алфавита ISO.
В языках стран Северной Европы, где встречаются скандинавские буквы (например, ø), можно использовать Finnish_Swedish_100.
В языках Восточной Европы, например в русском, часто используется Cyrillic_General_100.
Китайский язык и параметры сортировки различаются в зависимости от региона, но чаще всего это либо китайский (упрощенное письмо), либо китайский (традиционное письмо).

В КНР и Сингапуре служба поддержки Майкрософт обычно применяет китайский (упрощенное письмо) и порядок сортировки пиньинь. Рекомендуемые параметры сортировки: Chinese_PRC (для SQL Server 2000), Chinese_PRC_90 (для SQL Server 2005) или Chinese_Simplified_Pinyin_100 (SQL Server 2008 и более поздних версий).

На Тайване чаще используется китайский (традиционное письмо), а порядок сортировки основывается на количестве штрихов: Chinese_Taiwan_Stroke (для SQL Server 2000), Chinese_Taiwan_Stroke_90 (для SQL Server 2005) или Chinese_Traditional_Stroke_Count_100 (для SQL Server 2008 и более поздних версий).

Другие регионы (например, Специальный административный район Гонконг и Специальный административный район Макао) также используют китайский язык традиционного языка. Для параметров сортировки, в Гонконге SAR, это не редкость, чтобы увидеть Chinese_Hong_Kong_Stroke_90 (на SQL Server 2005). В САР Макао Chinese_Traditional_Stroke_Count_100 (SQL Server 2008 и более поздних версиях) используется довольно часто.
Для японского языка наиболее часто используется Japanese_CI_AS. Japanese_XJIS_100 применяется в установках, поддерживающих JIS2004. Japanese_BIN2 обычно применяется в проектах миграции данных, где исходные данные получены с платформ, отличных от Windows, или из источников данных, отличных от реляционной СУБД SQL Server.

Japanese_Bushu_Kakusu_100 редко встречается на серверах с Analysis Services.
Для корейского языка рекомендуется использовать Korean_100. В списке есть и Korean_Wansung_Unicode, но эта сортировка считается устаревшей.

Чувствительность к регистру идентификаторов объекта

Начиная с SQL Server 2012 SP2 учет регистра идентификаторов объектов применяется независимо от параметров сортировки, но поведение зависит от языка.

Набор знаков	Чувствительность к регистру
Основной латинский алфавит	Идентификаторы объектов, выраженные латинским алфавитом (любой из 26 английских символов верхнего или нижнего регистра), обрабатываются без учета регистра независимо от параметров сортировки. Например, следующие идентификаторы объектов считаются равнозначными: 54321abcdef, 54321ABCDEF, 54321AbCdEf. Службы Analysis Services обрабатывают символы в строке так, будто все они прописные, а затем выполняют простое побайтное сравнение, которое не зависит от языка. Обратите внимание, что затрагиваются только 26 символов. У западноевропейских языков со скандинавскими символами дополнительные символы не будут в верхнем регистре.
Кириллица, греческий, коптский, армянский	В идентификаторах объектов на языках с письмом, отличным от латинского, где строчные и заглавные буквы различаются, всегда учитывается регистр. Например, "Измерение" и "измерение" считаются различными значениями, хотя единственная разница — первая буква.

Набор знаков

Чувствительность к регистру

Основной латинский алфавит

Идентификаторы объектов, выраженные латинским алфавитом (любой из 26 английских символов верхнего или нижнего регистра), обрабатываются без учета регистра независимо от параметров сортировки. Например, следующие идентификаторы объектов считаются равнозначными: 54321abcdef, 54321ABCDEF, 54321AbCdEf. Службы Analysis Services обрабатывают символы в строке так, будто все они прописные, а затем выполняют простое побайтное сравнение, которое не зависит от языка.

Обратите внимание, что затрагиваются только 26 символов. У западноевропейских языков со скандинавскими символами дополнительные символы не будут в верхнем регистре.

Кириллица, греческий, коптский, армянский

В идентификаторах объектов на языках с письмом, отличным от латинского, где строчные и заглавные буквы различаются, всегда учитывается регистр. Например, "Измерение" и "измерение" считаются различными значениями, хотя единственная разница — первая буква.

Влияния учета регистра в идентификаторах объектов

Только к идентификаторам, а не именам объектов применяются типы поведения, описанные в таблице. Если вы заметите изменения в работе решения (после установки SQL Server 2012 SP2 или более поздней версии), то это изменение, по всей видимости, будет связано с обработкой. Идентификаторы объектов не влияют на запросы. Для обоих языков запросов (DAX и MDX) механизм обработки формул использует имя объекта (а не идентификатор).

Примечание

Изменения в коде, связанные с учетом регистра, были критическими для некоторых приложений.

Тестирования языков с помощью Excel, SQL Server Profiler и SQL Server Management Studio

При тестировании переводов соединение должно указывать код языка перевода.

Это можно сделать вручную, добавив в ODC-файл свойство строки подключения кода языка. Попробуйте этот подход с примером многомерной базы данных Adventure Works.

Найдите существующие ODC-файлы. Затем найдите файл для многомерной базы данных Adventure Works и щелкните правой кнопкой мыши файл, чтобы открыть его в программе "Блокнот".
Добавьте Locale Identifier=1036 в строку подключения. Сохраните файл и закройте его.
Открыть Excel | Данных | Существующие подключения. Отфильтруйте список, чтобы показать только файлы подключений на этом компьютере. Найдите подключение для Adventure Works (внимательно посмотрите на имя, их может быть несколько). открывает подключение;

Вы увидите переводы на французский из образца базы данных Adventure Works.

Затем можно использовать приложение SQL Server Profiler для подтверждения кода языка. Щелкните событие Session Initialize , а затем найдите <localeidentifier>1036</localeidentifier>в текстовом поле под списком свойств.

В среде Management Studio можно указать код языка для соединения с сервером.

В обозреватель объектов | Подключения | Службы Analysis Services | Параметры перейдите на вкладку Дополнительные параметры подключения.
Введите Locale Identifier=1036 и нажмите кнопку Подключить.
Выполните MDX-запрос к базе данных Adventure Works. Результатами запроса должны быть переводы на французский.

Написание MDX-запросов в решении, содержащем переводы

Переводы предоставляют отображаемые сведения для имен SQL Server Analysis Services объектов, но идентификаторы для этих же объектов не переводятся. По возможности используйте идентификаторы и ключи для объектов SQL Server Analysis Services вместо переведенных субтитров и имен. Например, для обеспечения мобильности в нескольких языках необходимо использовать ключи элементов, а не имена элементов для инструкций многомерных выражений и скриптов.

Примечание

Помните, что в именах табличных объектов регистр никогда не учитывается, независимо от параметров сортировки. В именах многомерных объектов, напротив, регистр учитывается таким же образом, как в параметрах сортировки. Поскольку регистр учитывается только в именах многомерных объектов, убедитесь, что все запросы MDX, ссылающиеся на многомерные объекты, имеют правильный регистр.

Написание MDX-запросов, содержащих значения даты и времени

Следующие рекомендации помогут удобнее переносить запросы MDX на основе даты и времени на разные языки:

Использование числовых частей для сравнения и операций

При выполнении операций и сравнений месяцев и дней недели используйте числовые части даты и времени, а не строковые эквиваленты (например, используйте MonthNumberofYear вместо MonthName). Числовые значения в меньше степени затрагиваются различиями в переводах.
Использование строковых эквивалентов в результирующем наборе

При построении результирующих наборов, видимых конечным пользователям, используйте строки (например, MonthName), чтобы многоязычная аудитория могла пользоваться предоставленными переводами.
Использование форматов даты ISO для получения универсальных сведений о дате и времени

Один эксперт по службам Analysis Services дает следующую рекомендацию: "Я всегда использую ISO-формат даты гггг-мм-дд для любой строки даты, которая передается в запросах SQL или MDX, так как он однозначный и будет работать независимо от региональных параметров клиента или сервера. Я соглашусь с тем, что сервер должен игнорировать свои региональные настройки при синтаксическом анализе неоднозначного формата даты, но я также думаю, если у вас есть вариант, интерпретируемый одинаково, лучше остановиться на нем".
Воспользуйтесь функцией "Формат", чтобы принудительно использовать определенный формат, не учитывая установленные региональные настройки языка.

В следующем запросе MDX, взятом из публикации на форуме, показано использование параметра Format для возврата данных в определенном формате вне зависимости от базовых региональных параметров.
```
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]  
```

См. также раздел

Сценарии глобализации для служб Analysis Services
Написание инструкций Transact-SQL, адаптированных к международному использованию

Поделиться через