Porady dotyczące globalizacji i najlepsze rozwiązania (Analysis Services)

Dotyczy: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Ważny: Informacje w tym artykule dotyczą tylko rozwiązań modelu wielowymiarowego .

Te wskazówki i wskazówki mogą pomóc zwiększyć przenośność wielowymiarowych rozwiązań analizy biznesowej i uniknąć błędów, które są bezpośrednio związane z ustawieniami języka i sortowania.

Użyj podobnych sortowania w całym stosie

Jeśli to możliwe, spróbuj użyć tych samych ustawień sortowania w usługach SQL Server Analysis Services, które są używane dla aparatu bazy danych, dążąc do korespondencji w zakresie poufności i poufności liter oraz poufności dostępu.

Każda usługa ma własne ustawienia sortowania z domyślnym aparatem bazy danych ustawionym na SQL_Latin1_General_CP1_CI_AS i usługi Analysis Services ustawione na Latin1_General_AS. Wartości domyślne są zgodne z terminem wielkości liter, szerokości i poufności akcentu. Ostrzegaj, że jeśli zmieniasz ustawienia obu sortowania, możesz napotkać problemy, gdy właściwości sortowania różnią się w fundamentalny sposób.

Nawet jeśli ustawienia sortowania są funkcjonalnie równoważne, można napotkać specjalny przypadek, w którym puste miejsce w dowolnym miejscu w ciągu jest interpretowane inaczej przez każdą usługę.

Znak spacji jest "specjalnym przypadkiem", ponieważ może być reprezentowany jako pojedynczy bajt (SBCS) lub zestaw znaków dwubajtowych (DBCS) w standardzie Unicode. W asilniku relacyjnym dwa ciągi złożone oddzielone spacją — jedną przy użyciu SBCS, drugą w DBCS — są uważane za identyczne. W usługach Analysis Services podczas przetwarzania te same dwa ciągi złożone nie są identyczne, a drugie wystąpienie zostanie oznaczone jako duplikat.

Aby uzyskać więcej szczegółów i sugerowanych obejść, zobacz Blanks in a Unicode string have different processing outcomes based on collation (Wartości puste w ciągu Unicode mają różne wyniki przetwarzania na podstawie sortowania).

Typowe zalecenia dotyczące sortowania

Usługi Analysis Services zawsze wyświetla pełną listę wszystkich dostępnych języków i sortowania; nie filtruje sortowania na podstawie wybranego języka. Pamiętaj, aby wybrać możliwą do wykonania kombinację.

Niektóre z najczęściej używanych sortowania obejmują te z poniższej listy.

Należy rozważyć, że ta lista jest punktem wyjścia do dalszego badania, a nie ostatecznym zaleceniem, które wyklucza inne opcje. Może się okazać, że sortowanie, które nie jest specjalnie zalecane, jest tym, który działa najlepiej dla Twoich danych. Dokładne testowanie to jedyny sposób sprawdzania, czy wartości danych są sortowane i porównywane odpowiednio. Jak zawsze podczas testowania sortowania należy uruchamiać obciążenia przetwarzania i wykonywania zapytań.

• Latin1_General_100_AS jest często używany w przypadku aplikacji korzystających z 26 znaków podstawowego alfabetu łacińskiego ISO.

• Języki północnoeuropejskie, które zawierają skandynawskie litery (takie jak ø), mogą używać Finnish_Swedish_100.

• Języki wschodnioeuropejskie, takie jak rosyjski, często używają Cyrillic_General_100.

• Język chiński i sortowanie różnią się w zależności od regionu, ale zazwyczaj są to chiński uproszczony lub chiński tradycyjny.

  W CHRL i Singapurze pomoc techniczna firmy Microsoft zwykle widzi uproszczony chiński, z Pinyin jako preferowaną kolejnością sortowania. Zalecane sortowania to Chinese_PRC (dla programu SQL Server 2000), Chinese_PRC_90 (dla programu SQL Server 2005) lub Chinese_Simplified_Pinyin_100 (dla programu SQL Server 2008 i nowszych).

  Na Tajwanie częściej spotyka się chiński tradycyjny z zalecanym kolejnością sortowania na podstawie liczby pociągnięć: Chinese_Taiwan_Stroke (dla programu SQL Server 2000), Chinese_Taiwan_Stroke_90 (dla programu SQL Server 2005) lub Chinese_Traditional_Stroke_Count_100 (dla programu SQL Server 2008 i nowszych).

  Inne regiony (takie jak specjalny region administracyjny Hongkongu i specjalny region administracyjny Makau) również używają tradycyjnego chińskiego. W przypadku sortowania w Hong Kongu SAR nie jest niczym niezwykłym, aby zobaczyć Chinese_Hong_Kong_Stroke_90 (w programie SQL Server 2005). W programie Macao SAR Chinese_Traditional_Stroke_Count_100 (w programie SQL Server 2008 lub nowszym) jest często używany dość często.

• W przypadku języka japońskiego najczęściej używane sortowanie jest Japanese_CI_AS. Japanese_XJIS_100 jest używana w instalacjach obsługujących JIS2004. Japanese_BIN2 jest zwykle widoczny w projektach migracji danych, z danymi pochodzącymi z platform innych niż Windows lub ze źródeł danych innych niż aparat relacyjnej bazy danych programu SQL Server.

  Japanese_Bushu_Kakusu_100 rzadko występuje na serwerach z obciążeniami usług Analysis Services.

• Korean_100 jest zalecana dla języka koreańskiego. Mimo że Korean_Wansung_Unicode jest nadal dostępna na liście, została wycofana.

Ważność wielkości liter identyfikatorów obiektów

Począwszy od programu SQL Server 2012 SP2, ważność wielkości liter identyfikatorów obiektów jest wymuszana niezależnie od sortowania, ale zachowanie różni się w zależności od języka:

Implikacje uwzględniania wielkości liter dla identyfikatorów obiektów

Tylko identyfikatory obiektów, a nie nazwy obiektów, podlegają zachowaniom wielkości liter opisanym w tabeli. Jeśli zobaczysz zmianę sposobu działania rozwiązania (przed i po porównaniu — po zainstalowaniu programu SQL Server 2012 SP2 lub nowszego), najprawdopodobniej będzie to problem z przetwarzaniem. Zapytania nie mają wpływu na identyfikatory obiektów. W przypadku języków zapytań (DAX i MDX) aparat formuły używa nazwy obiektu (a nie identyfikatora).

Testowanie ustawień regionalnych przy użyciu programu Excel, programu SQL Server Profiler i programu SQL Server Management Studio

Podczas testowania tłumaczeń połączenie musi określać identyfikator LCID tłumaczenia.

Można to zrobić, edytując plik odc, aby uwzględnić właściwość parametrów połączenia identyfikatora ustawień regionalnych. Wypróbuj to za pomocą przykładowej wielowymiarowej bazy danych Adventure Works.

• Wyszukaj istniejące pliki odc. Po znalezieniu elementu wielowymiarowego firmy Adventure Works kliknij go prawym przyciskiem myszy, aby otworzyć go w Notatniku.

• Dodaj Locale Identifier=1036 do parametrów połączenia. Zapisz i zamknij plik.

• Otwórz program Excel | Dane | Istniejące połączenia. Przefiltruj listę tylko do plików połączeń na tym komputerze. Znajdź połączenie dla firmy Adventure Works (dokładnie przyjrzyj się nazwie; być może masz więcej niż jedno). Otwórz połączenie.

  Powinny zostać wyświetlone francuskie tłumaczenia z przykładowej bazy danych Adventure Works.

  

W ramach kolejnych czynności możesz użyć programu SQL Server Profiler, aby potwierdzić ustawienia regionalne. Session Initialize Kliknij zdarzenie, a następnie przyjrzyj się liście właściwości w obszarze tekstowym poniżej, aby znaleźć <localeidentifier>1036</localeidentifier>element .

W programie Management Studio można określić identyfikator ustawień regionalnych na połączeniu serwera.

• W Eksploratorze obiektów | Połączyć | Analysis Services | Opcje, kliknij kartę Dodatkowe parametry połączenia .

• Wprowadź, Locale Identifier=1036 a następnie kliknij przycisk Połącz.

• Wykonaj zapytanie MDX względem bazy danych Adventure Works. Wyniki zapytania powinny być tłumaczeniami francuskimi.

  

Pisanie zapytań MDX w rozwiązaniu zawierającym tłumaczenia

Tłumaczenia zawierają informacje wyświetlane dla nazw obiektów usług SQL Server Analysis Services, ale identyfikatory tych samych obiektów nie są tłumaczone. Jeśli to możliwe, użyj identyfikatorów i kluczy dla obiektów usług SQL Server Analysis Services zamiast przetłumaczonych podpisów i nazw. Na przykład użyj kluczy członkowskich zamiast nazw elementów członkowskich dla instrukcji i skryptów wielowymiarowych wyrażeń (MDX), aby zapewnić przenośność w wielu językach.

Pisanie zapytań MDX zawierających wartości daty i godziny

Poniższe sugestie dotyczące zwiększenia przenośni zapytań MDX opartych na dacie i godzinie w różnych językach:

1. Używanie części liczbowych do porównań i operacji

   W przypadku przeprowadzania porównań i operacji miesiąca i dnia tygodnia użyj części daty i godziny liczbowej zamiast odpowiedników ciągu (na przykład użyj parametru MonthNumberofYear zamiast MonthName). Wartości liczbowe mają najmniejszy wpływ na różnice w tłumaczeniach języków.

2. Używanie odpowiedników ciągów w zestawie wyników

   Podczas tworzenia zestawów wyników widocznych przez użytkowników końcowych rozważ użycie ciągu (takiego jak MonthName), aby odbiorcy wielojęzyczni mogli korzystać z dostarczonych tłumaczeń.

3. Używanie formatów daty ISO dla uniwersalnych informacji o dacie i godzinie

   Jeden ekspert usług Analysis Services ma to zalecenie: "Zawsze używam formatu daty ISO rrrr-mm-dd dla dowolnych ciągów dat przekazywanych do zapytań w języku SQL lub MDX, ponieważ jest to jednoznaczne i będzie działać niezależnie od ustawień regionalnych klienta lub serwera. Zgadzam się, że serwer powinien odroczyć swoje ustawienia regionalne podczas analizowania niejednoznacznego formatu daty, ale myślę również, że jeśli masz opcję, która nie jest otwarta na interpretację, że lepiej wybrać to mimo to".

4. Użyj funkcji Format, aby wymusić określony format, niezależnie od ustawień języka regionalnego

   Poniższe zapytanie MDX, pożyczone z wpisu na forum, ilustruje, jak używać formatu do zwracania dat w określonym formacie, niezależnie od podstawowych ustawień regionalnych.

   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]  
   
   

Zobacz także

Scenariusze globalizacji dla usług Analysis Services
Pisanie międzynarodowych instrukcji Transact-SQL