Tipps und bewährte Methoden für die Globalisierung (Analysis Services)

gilt für: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Wichtig: Informationen in diesem Artikel gelten nur für mehrdimensionale Modelllösungen.

Diese Tipps und Richtlinien können dazu beitragen, die Portabilität Ihrer mehrdimensionalen Business Intelligence-Lösungen zu erhöhen und Fehler zu vermeiden, die sich direkt auf Sprach- und Sortierungseinstellungen beziehen.

Verwenden ähnlicher Sortierungen im gesamten Stapel

Wenn möglich, versuchen Sie, die gleichen Sortiereinstellungen in SQL Server Analysis Services zu verwenden, die Sie für das Datenbankmodul verwenden, die Übereinstimmung in Breite-Vertraulichkeit und Groß-/Kleinschreibung und Zugriffsempfindlichkeit anstreben.

Jeder Dienst verfügt über eigene Sortiereinstellungen, wobei das Datenbankmodul standardmäßig auf SQL_Latin1_General_CP1_CI_AS und Analysis Services auf Latin1_General_AS festgelegt ist. Die Standardwerte sind im Begriff der Groß-/Kleinschreibung, Breite und Akzentempfindlichkeit kompatibel. Achten Sie darauf, dass bei unterschiedlichen Einstellungen einer Sortierung Probleme auftreten können, wenn die Sortierungseigenschaften grundsätzlich voneinander abweichen.

Selbst wenn Die Sortierungseinstellungen funktionell gleichwertig sind, können Sie in einem Sonderfall ausgeführt werden, in dem ein leerer Leerraum an einer beliebigen Stelle innerhalb einer Zeichenfolge von jedem Dienst unterschiedlich interpretiert wird.

Das Leerzeichen ist ein Sonderfall, da es in Unicode als Single-Byte-Zeichensatz (Single-Byte, SBCS) oder DBCS (Double-Byte Character Set) dargestellt werden kann. Im relationalen Modul werden zwei zusammengesetzte Zeichenfolgen, die durch ein Leerzeichen getrennt sind – eine, die SBCS verwendet, die andere in DBCS – als identisch betrachtet. In Analysis Services sind bei der Verarbeitung dieselben zwei zusammengesetzten Zeichenfolgen nicht identisch, und die zweite Instanz wird als Duplikat gekennzeichnet.

Weitere Details und vorgeschlagene Problemumgehungen finden Sie unter Leerzeichen in einer Unicode-Zeichenfolge, die auf der Sortierung basieren, unterschiedliche Verarbeitungsergebnisse.

Häufige Sortierempfehlungen

Analysis Services stellt immer die vollständige Liste aller verfügbaren Sprachen und Sortierungen dar; die Sortierungen werden nicht basierend auf der ausgewählten Sprache gefiltert. Stellen Sie sicher, dass Sie eine arbeitsfähige Kombination auswählen.

Einige der häufiger verwendeten Sortierungen sind in der folgenden Liste enthalten.

Sie sollten diese Liste als Ausgangspunkt für eine weitere Untersuchung betrachten, anstatt eine endgültige Empfehlung, die andere Optionen ausschließt. Möglicherweise stellen Sie fest, dass eine Sortierung, die nicht speziell empfohlen wird, die für Ihre Daten am besten geeignet ist. Gründliche Tests sind die einzige Möglichkeit, zu überprüfen, ob Datenwerte sortiert und entsprechend verglichen werden. Achten Sie wie immer darauf, beim Testen der Sortierung sowohl Verarbeitungs- als auch Abfrageworkloads auszuführen.

• Latin1_General_100_AS wird häufig für Anwendungen verwendet, die die 26 Zeichen des iso-grundlegenden lateinischen Alphabets verwenden.

• Nordeuropäische Sprachen, die skandinavische Buchstaben (z. B. ø) enthalten, können Finnish_Swedish_100 verwenden.

• Osteuropäische Sprachen wie Russisch verwenden häufig Cyrillic_General_100.

• Chinesische Sprache und Sortierungen variieren je nach Region, sind jedoch im Allgemeinen chinesisch (vereinfacht) oder chinesisch (traditionell).

  In PRC und Singapur sieht der Microsoft-Support tendenziell vereinfachtes Chinesisch mit Pinyin als bevorzugte Sortierreihenfolge. Die empfohlenen Sortierungen sind Chinese_PRC (für SQL Server 2000), Chinese_PRC_90 (für SQL Server 2005) oder Chinese_Simplified_Pinyin_100 (für SQL Server 2008 und höher).

  In Taiwan ist es üblicher, traditionelles Chinesisch mit der empfohlenen Sortierreihenfolge auf der Strichanzahl zu sehen: Chinese_Taiwan_Stroke (für SQL Server 2000), Chinese_Taiwan_Stroke_90 (für SQL Server 2005) oder Chinese_Traditional_Stroke_Count_100 (für SQL Server 2008 und höher).

  Andere Regionen (z. B. die Sonderverwaltungsregion Hongkong und die Sonderverwaltungsregion Macao) verwenden auch traditionelles Chinesisch. Für Sortierungen in Hongkong IST es nicht ungewöhnlich, Chinese_Hong_Kong_Stroke_90 (auf SQL Server 2005) zu sehen. In Macau SAR wird Chinese_Traditional_Stroke_Count_100 (auf SQL Server 2008 und höher) häufig verwendet.

• Für Japanisch ist die am häufigsten verwendete Sortierung Japanese_CI_AS. Japanese_XJIS_100 wird in Installationen verwendet, die JIS2004 unterstützen. Japanese_BIN2 werden in der Regel in Datenmigrationsprojekten mit Daten aus Nicht-Windows-Plattformen oder aus anderen Datenquellen als dem relationalen SQL Server-Datenbankmodul angezeigt.

  Japanese_Bushu_Kakusu_100 wird selten auf Servern angezeigt, auf denen Analysis Services-Workloads ausgeführt werden.

• Korean_100 wird für Koreanisch empfohlen. Obwohl Korean_Wansung_Unicode in der Liste noch verfügbar ist, ist sie veraltet.

Groß-/Kleinschreibung von Objektbezeichnern

Ab SQL Server 2012 SP2 wird die Groß-/Kleinschreibung von Objekt-IDs unabhängig von der Sortierung erzwungen, das Verhalten variiert jedoch je nach Sprache:

Auswirkungen der Groß-/Kleinschreibung für Objektbezeichner

Nur Objektbezeichner und keine Objektnamen unterliegen den in der Tabelle beschriebenen Groß-/Kleinschreibungsverhalten. Wenn eine Änderung der Funktionsweise Ihrer Lösung (ein Vor- und Nachher-Vergleich - nach der Installation von SQL Server 2012 SP2 oder höher) angezeigt wird, ist es wahrscheinlich ein Verarbeitungsproblem. Abfragen werden von Objektbezeichnern nicht beeinflusst. Für beide Abfragesprachen (DAX und MDX) verwendet das Formelmodul den Objektnamen (nicht den Bezeichner).

Gebietsschematests mit Excel, SQL Server Profiler und SQL Server Management Studio

Beim Testen von Übersetzungen muss die Verbindung die LCID der Übersetzung angeben.

Dazu können Sie die ODC-Datei manuell bearbeiten, um die Eigenschaft für die Gebietsschema-ID-Verbindungszeichenfolge einzuschließen. Probieren Sie dies mit der multidimensionalen Adventure Works-Beispieldatenbank aus.

• Suchen Sie nach vorhandenen ODC-Dateien. Wenn Sie die Datei für Adventure Works multidimensional finden, klicken Sie mit der rechten Maustaste auf die Datei, um sie im Editor zu öffnen.

• Fügen Sie der Verbindungszeichenfolge hinzu Locale Identifier=1036 . Speichern und schließen Sie die Datei.

• Excel öffnen | Daten | Vorhandene Verbindungen. Filtern Sie die Liste nach nur Verbindungsdateien auf diesem Computer. Suchen Sie die Verbindung für Adventure Works (sehen Sie sich den Namen sorgfältig an; möglicherweise haben Sie mehrere). Öffnen Sie die Verbindung.

  Die französischen Übersetzungen aus der Adventure Works-Beispieldatenbank sollten angezeigt werden.

  

Als Nachverfolgung können Sie sql Server Profiler verwenden, um das Gebietsschema zu bestätigen. Klicken Sie auf ein Session Initialize Ereignis, und sehen Sie sich dann die Eigenschaftenliste im folgenden Textbereich an, um zu suchen <localeidentifier>1036</localeidentifier>.

In Management Studio können Sie den Gebietsschemabezeichner für eine Serververbindung angeben.

• Im Objekt-Explorer | Verbinden | Analysis Services | Klicken Sie auf die Registerkarte "Zusätzliche Verbindungsparameter ".

• Geben Sie die Eingabetaste Locale Identifier=1036 ein, und klicken Sie dann auf "Verbinden".

• Führen Sie eine MDX-Abfrage für die Adventure Works-Datenbank aus. Die Abfrageergebnisse sollten die französischen Übersetzungen sein.

  

Schreiben von MDX-Abfragen in einer Lösung mit Übersetzungen

Übersetzungen stellen Anzeigeinformationen für die Namen von SQL Server Analysis Services-Objekten bereit, die Bezeichner für dieselben Objekte werden jedoch nicht übersetzt. Verwenden Sie nach Möglichkeit die Bezeichner und Schlüssel für SQL Server Analysis Services-Objekte anstelle der übersetzten Beschriftungen und Namen. Verwenden Sie beispielsweise Memberschlüssel anstelle von Membernamen für MDX-Anweisungen (Multidimensional Expressions) und Skripts, um die Portabilität über mehrere Sprachen hinweg sicherzustellen.

Schreiben von MDX-Abfragen mit Datums- und Uhrzeitwerten

Die folgenden Vorschläge, um Ihre datums- und zeitbasierten MDX-Abfragen in verschiedenen Sprachen portierbarer zu machen:

1. Verwenden numerischer Teile für Vergleiche und Vorgänge

   Wenn Sie Monats- und Wochenvergleiche und -vorgänge ausführen, verwenden Sie die numerischen Datums- und Uhrzeitteile anstelle der Zeichenfolgenentsprechungen (z. B. "MonthNumberofYear" anstelle von "MonthName"). Numerische Werte sind am wenigsten von Unterschieden bei Sprachübersetzungen betroffen.

2. Verwenden von Zeichenfolgenäquivalenten in einem Resultset

   Beim Erstellen von Resultsets, die von Endbenutzern gesehen werden, sollten Sie die Zeichenfolge (z. B. MonthName) verwenden, damit Ihre mehrsprachige Zielgruppe von den von Ihnen bereitgestellten Übersetzungen profitieren kann.

3. Verwenden von ISO-Datumsformaten für universelle Datums- und Uhrzeitinformationen

   Ein Analysis Services-Experte hat diese Empfehlung: "Ich verwende immer das ISO-Datumsformat yyyy-mm-dd für alle Datumszeichenfolgen, die ich an Abfragen in SQL oder MDX übergibt, da es eindeutig ist und unabhängig von den regionalen Einstellungen des Clients oder Servers funktioniert. Ich stimme zu, dass der Server bei der Analyse eines mehrdeutigen Datumsformats seine regionalen Einstellungen zurückstellen sollte, aber ich denke auch, dass, wenn Sie eine Option haben, die nicht offen für die Interpretation ist, dass Sie das trotzdem besser auswählen".

4. Verwenden der Formatfunktion, um ein bestimmtes Format zu erzwingen, unabhängig von den Regionsspracheneinstellungen

   Die folgende MDX-Abfrage, die aus einem Forumbeitrag geliehen wurde, veranschaulicht, wie Format verwendet wird, um Datumsangaben in einem bestimmten Format zurückzugeben, unabhängig von den zugrunde liegenden regionalen Einstellungen.

   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]  
   
   

Siehe auch

Globalisierungsszenarien für Analysis Services
Schreiben von internationalen Transact-SQL-Anweisungen