Tipps und Best Practices für die Globalisierung (Analysis Services)

Betrifft: nur mehrdimensional

Diese Tipps und Richtlinien können dazu beitragen, die Portabilität von Business Intelligence-Lösungen zu erhöhen und Fehler zu vermeiden, die direkt mit Sprache und Sortierung in Zusammenhang stehen.

• Verwenden ähnlicher Sortierungen im ganzen Stapel

• Allgemeine Empfehlungen für die Sortierung

• Unterscheidung von Groß-/Kleinschreibung bei Objektbezeichnern

• Gebietsschematests mit Excel und SQL Server Profiler

• Schreiben von MDX-Abfragen in einer Projektmappe mit Übersetzungen

• Schreiben von MDX-Abfragen mit Datums- und Uhrzeitwerten

Verwenden ähnlicher Sortierungen im ganzen Stapel

Versuchen Sie nach Möglichkeit, in Analysis Services dieselben Sortierungseinstellungen zu verwenden wie für das Datenbankmodul, um Übereinstimmung im Hinblick auf Unterscheidung von Breite, Groß-/Kleinschreibung und Akzenten zu erzielen.

Jeder Dienst hat eigene Sortierungseinstellungen, dabei ist der Standardwert für das Datenbankmodul auf SQL_Latin1_General_CP1_CI_AS und Analysis Services auf Latin1_General_AS festgelegt. Die Standardwerte sind hinsichtlich der Unterscheidung von Groß-/Kleinschreibung, Breite und Akzenten kompatibel. Beachten Sie, dass bei Änderungen an den Einstellungen einer Sortierung Probleme auftreten können, wenn die Sortierungseigenschaften grundlegende Unterschiede aufweisen.

Auch wenn Sortierungseinstellungen funktional gleichwertig sind, kann der Sonderfall eintreten, dass ein Leerzeichen an einer beliebigen Stelle in einer Zeichenfolge von jedem Dienst unterschiedlich interpretiert wird.

Das Leerzeichen ist ein „Sonderfall“, da es als Single-Byte-Zeichensatz (SBCS) oder Double-Byte-Zeichensatz (DBCS) im Unicode-Format dargestellt werden kann. Im relationalen Modul werden zwei Verbundzeichenfolgen, die durch ein Leerzeichen getrennt sind – eine im SBCS-, die andere im DBCS-Zeichensatz – als identisch betrachtet. In Analysis Services sind während der Verarbeitung die gleichen zwei Verbundzeichenfolgen nicht identisch, und die zweite Instanz wird als Duplikat gekennzeichnet.

Weitere Informationen und empfohlene Problemumgehungen finden Sie unter Leerzeichen in einer Unicode-Zeichenfolge haben unterschiedliche Verarbeitungsergebnisse basierend auf Sortierung.

Allgemeine Empfehlungen für die Sortierung

Analysis Services stellt immer die vollständige Liste aller verfügbaren Sprachen und Sortierungen bereit; die Sortierungen werden nicht anhand der ausgewählten Sprache gefiltert. Achten Sie darauf, eine praktikable Kombination auswählen.

Einige der häufig verwendeten Sortierungen sind in der folgenden Liste aufgeführt.

Betrachten Sie diese Liste als Ausgangspunkt für weitere Untersuchungen, statt als definitive Empfehlung, die andere Optionen ausschließt. Unter Umständen stellen Sie fest, dass eine nicht ausdrücklich empfohlene Sortierung am besten für Ihre Daten geeignet ist. Gründliche Tests sind die einzige Möglichkeit zu überprüfen, ob Datenwerte richtig sortiert und verglichen werden. Achten Sie wie immer darauf, beim Testen der Sortierung sowohl Verarbeitungs- als auch Abfragearbeitsauslastungen auszuführen.

• Für Anwendungen, die die 26 Zeichen des lateinischen Alphabets verwenden, wird häufig Latin1_General_100_AS verwendet.

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

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

• Die chinesische Sprache und Sortierung variiert je nach Region, ist im Allgemeinen jedoch entweder vereinfachtes Chinesisch oder traditionelles Chinesisch.

  In der Volksrepublik China und Singapur wird vom Microsoft Support vornehmlich vereinfachtes Chinesisch beobachtet, mit Pinyin als bevorzugter 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 traditionelles Chinesisch üblicher, wobei die empfohlene Sortierreihenfolge auf Strichzählung basiert: 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).

  Auch andere Regionen (z. B. Hongkong und Macau) verwenden traditionelles Chinesisch. Für Sortierungen in Hongkong wird häufig Chinese_Hong_Kong_Stroke_90 (in SQL Server 2005) verwendet. In Macau wird Chinese_Traditional_Stroke_Count_100 (in SQL Server 2008 und höher) recht häufig verwendet.

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

  Japanese_Bushu_Kakusu_100 wird selten auf Servern verwendet, die Analysis Services-Arbeitsauslastungen ausführen.

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

Unterscheidung von Groß-/Kleinschreibung bei Objektbezeichnern

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

Sprachskript	Unterscheidung nach Groß-/Kleinschreibung
Standardlateinisches Alphabet	Objektbezeichner, die im Skript „Lateinisch“ (alle 26 englischen Groß- oder Kleinbuchstaben) ausgedrückt werden, werden unabhängig von der Sortierung ohne Unterscheidung von Groß-/Kleinschreibung behandelt. Beispielsweise werden die folgenden Objekt-IDs als identisch betrachtet: 54321Abcdef, 54321ABCDEF, 54321AbCdEf. Intern werden in Analysis Services die Zeichen in der Zeichenfolge behandelt, als wären alle Zeichen Großbuchstaben, anschließend wird ein einfacher Bytevergleich durchgeführt, der unabhängig von der Sprache ist. Beachten Sie, dass nur die 26 Zeichen betroffen sind. Wenn die Sprache Westeuropäisch ist, jedoch skandinavische Zeichen verwendet, wird das zusätzliche Zeichen nicht groß geschrieben.
Kyrillisch, Griechisch, Koptisch, Armenisch	Bei Objektbezeichnern in einem nicht lateinischen „bikameralen“ Skript, wie z. B. Kyrillisch, wird die Groß-/Kleinschreibung immer unterschieden. Beispielsweise werden bei Измерение und измерение als zwei unterschiedliche Werte betrachtet, obwohl der einzige Unterschied der erste Buchstabe ist.

Auswirkungen der Unterscheidung von Groß-/Kleinschreibung für Objektbezeichner

Nur Objektbezeichner, nicht jedoch Objektnamen, unterliegen den in der Tabelle beschriebenen Verhaltensweisen bei der Schreibweise. Wenn Sie eine Änderung in der Funktionsweise der Projektmappe feststellen (ein Vorher-Nachher-Vergleich – nach der Installation von SQL Server 2012 SP2 oder höher), liegt sehr wahrscheinlich ein Verarbeitungsproblem vor. Abfragen werden nicht von Objektbezeichnern beeinflusst. Für beide Abfragesprachen (DAX und MDX) verwendet das Formelmodul den Objektnamen (nicht den Bezeichner).

Hinweis
Codeänderungen, die im Zusammenhang mit der Groß-/Kleinschreibung stehen, bedeuteten eine erhebliche Änderung für einige Anwendungen. Weitere Informationen finden Sie unter Aktuelle Änderungen von Analysis Services-Funktionen in SQL Server 2012.

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

Beim Testen von Übersetzungen muss die Verbindung die LCID der Übersetzung angeben. Gemäß den Erläuterungen in Andere Sprache von SSAS in Excel abrufen können Sie Excel verwenden, um Ihre Übersetzungen zu testen.

Hierzu können Sie die ODC-Datei manuell so bearbeiten, dass sie die Verbindungszeichenfolgen-Eigenschaft des Gebietsschemabezeichners enthält. Probieren Sie dies mit der mehrdimensionalen Adventure Works-Beispieldatenbank aus.

• Suchen Sie nach vorhandenen ODC-Dateien. Wenn Sie die Datei für die mehrdimensionale Adventure Works-Datenbank gefunden haben, klicken Sie mit der rechten Maustaste darauf, um sie im Editor zu öffnen.

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

• Öffnen Sie Excel | Daten | Vorhandene Verbindungen. Filtern Sie die Liste so, dass nur Verbindungsdateien auf diesem Computer aufgeführt werden. Suchen Sie die Verbindung für Adventure Works (sehen Sie sich den Namen genau an, es gibt möglicherweise mehrere). Öffnen Sie die Verbindung.

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

  

Anschließend können Sie SQL Server Profiler verwenden, um das Gebietsschema zu bestätigen. Klicken Sie auf ein Session Initialize-Ereignis, und suchen Sie dann in der Eigenschaftsliste im Textbereich unten nach <localeidentifier>1036</localeidentifier>.

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

• Wählen Sie im Objekt-Explorer | Verbindung | Analysis Services | Optionen, und klicken Sie auf die Registerkarte Zusätzliche Verbindungsparameter.

• Geben Sie Local Identifier=1036 ein, und klicken Sie dann auf Verbinden.

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

  

Schreiben von MDX-Abfragen in einer Projektmappe mit Übersetzungen

Übersetzungen stellen Anzeigeinformationen für die Namen von Analysis Services-Objekten zur Verfügung, wobei die Bezeichner für diese Objekte jedoch nicht übersetzt werden. Verwenden Sie nach Möglichkeit die Bezeichner und Schlüssel für Analysis Services-Objekte, nicht die übersetzten Beschriftungen und Namen. Verwenden Sie z. B. Elementschlüssel anstelle von Elementnamen für MDX-Anweisungen und -Skripts (Multidimensional Expressions, MDX), um sprachübergreifende Portabilität sicherzustellen.

Hinweis

Beachten Sie, dass bei tabellarischen Objektnamen unabhängig von der Sortierung die Groß-/Kleinschreibung nicht unterschieden wird. Mehrdimensionale Objektnamen hingegen folgen der Groß-/Kleinschreibung der Sortierung. Da die Groß-/Kleinschreibung nur bei mehrdimensionalen Objektnamen unterschieden wird, vergewissern Sie sich, dass alle MDX-Abfragen mit Verweisen auf mehrdimensionale Objekte korrekt geschrieben sind.

Schreiben von MDX-Abfragen mit Datums- und Uhrzeitwerten

Die folgenden Vorschläge dienen dazu, die Übertragung von datums- und zeitbasierten MDX-Abfragen in verschiedenen Sprachen leichter zu gestalten:

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

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

2. Verwenden Sie Zeichenfolgenentsprechungen in einem Resultset.

   Erwägen Sie beim Erstellen von Resultsets, die Endbenutzern angezeigt werden, die Verwendung der Zeichenfolge (z. B. MonthName), sodass Ihre mehrsprachige Zielgruppe von den Übersetzungen profitieren kann, die Sie bereitgestellt haben.

3. Verwenden Sie die ISO-Datumsformate für universelle Datums- und Uhrzeitangaben.

   Ein Analysis Services-Experte hat folgende Empfehlung: „Ich verwende immer das ISO-Datumsformat jjjj-mm-tt für Datumszeichenfolgen, die ich an SQL- oder MDX-Abfragen übergebe, da es eindeutig ist und unabhängig von den Ländereinstellungen des Clients oder Servers funktioniert. Ich stimme zu, dass der Server beim Analysieren eines mehrdeutigen Datumsformats auf seine Ländereinstellungen zurückgreifen sollte, ich denke jedoch auch, dass bei einer Option, die keine Interpretationsspielraum zulässt, besser diese Option gewählt werden sollte.“

4. Use the Format function to enforce a specific format, regardless of regional language settings

   Die folgende MDX-Abfrage aus einem Forumsbeitrag veranschaulicht, wie das Format zum Zurückgeben von Datumsangaben in einem bestimmten Format verwendet wird, unabhängig von den zugrunde liegenden Ländereinstellungen.

   Den ursprünglichen Beitrag finden Sie unter SSAS 2012 generiert ungültige Datumsangaben (Forumsbeitrag auf Network Steve).

   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

Konzepte

Globalisierungsszenarien für mehrdimensionale Analysis Services

Schreiben internationaler Transact-SQL-Anweisungen