グローバリゼーションのヒントとベスト プラクティス (Analysis Services)

適用対象 多次元のみ

このトピックで紹介するヒントとガイドラインは、ビジネス インテリジェンス ソリューションの移植性を向上し、言語および照合順序の設定に直接関連するエラーを回避するために役立ちます。

• スタック全体で同様の照合順序を使用する

• 照合順序に関する一般的な推奨事項

• オブジェクト識別子の大文字と小文字の区別

• Excel と SQL Server Profiler を使用したロケールのテスト

• 翻訳が含まれるソリューションで MDX クエリを作成する

• 日付と時刻の値を含む MDX クエリを作成する

スタック全体で同様の照合順序を使用する

可能であれば、データベース エンジンに使用する Analysis Services で同じ照合順序設定値を使用し、文字幅の区別、大文字と小文字の区別、およびアクセントの区別を一致させるようにしてください。

各サービスには独自の照合順序が設定されます。データベース エンジンの既定の設定は SQL_Latin1_General_CP1_CI_AS、Analysis Services の設定は Latin1_General_AS です。 既定値は、大文字と小文字、文字幅、およびアクセントの区別に関して互換性があります。 いずれかの照合順序の設定を変更すると、照合順序の特性が根本的に異なる場合に、問題が発生することがある点に注意してください。

照合順序の設定が機能的に等価であっても、文字列内のどこかに空白文字がある場合に各サービスによって文字列の解釈が異なるために、特殊なケースとして問題が起こることがあります。

空白文字は、Unicode で 1 バイト文字セット (SBCS) または 2 バイト文字セット (DBCS) として表現できるため、"特殊なケース" に当たります。 リレーショナル エンジンでは、1 つは SBCS の空白、もう 1 つは DBCS の空白で区切られた 2 つの複合文字列は、同一と見なされます。 Analysis Services の処理中には、2 つの複合文字列は内容が同じでも実体としては同一でないため、2 番目のインスタンスが重複としてフラグが付けられます。

さらに詳しい情報と推奨される回避策については、「Unicode 文字列に含まれる空白は照合順序に応じて処理結果が異なる」を参照してください。

照合順序に関する一般的な推奨事項

Analysis Services は、常にすべての使用可能な言語および照合順序の一覧を提示します。ユーザーが選択した言語に基づいて照合順序がフィルター処理されることはありません。 必ず、実行可能な組み合わせを選択してください。

一般的に使用される照合順序には、次の一覧にあるものが含まれます。

この一覧は、その他の選択肢を除外する明確な推奨事項ではなく、詳しい調査の開始点と見なしてください。 この一覧で特に推奨されていない照合順序が、対象となるデータに最適なものであることもあります。 データ値が適切に並べ替えられ、適切に比較されるかどうか確認する唯一の方法は、徹底的にテストすることです。 照合順序をテストする際には、いつものように、処理とクエリの両方のワークロードを実行してください。

• Latin1_General_100_AS は、ISO 基本ラテン アルファベットの 26 文字を使用するアプリケーションによく使用されます。

• スカンジナビア語の文字 (ø など) 含む北ヨーロッパ言語では、Finnish_Swedish_100 を使用できます。

• ロシア語などの東ヨーロッパ言語では、多くの場合、Cyrillic_General_100 を使用します。

• 中国語の言語および照合順序は地域によって異なりますが、一般に簡体字中国語または繁体字中国語のいずれかです。

  中華人民共和国およびシンガポールでは、Microsoft サポートの観察によると、ピンイン付きの簡体字国語の並べ替え順序がよく使用されています。 推奨される照合順序は、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 以降の場合)。

  その他の地域 (香港やマカオなど) でも、繁体字中国語を使用します。 香港では、照合順序に Chinese_Hong_Kong_Stroke_90 (SQL Server 2005 上) が使用されることも珍しくありません。 マカオでは、かなり多くの場合に、Chinese_Traditional_Stroke_Count_100 (SQL Server 2008 以降) が使用されます。

• 日本語では、最もよく使用される照合順序は Japanese_CI_AS です。 JIS2004 をサポートするシステムでは、Japanese_XJIS_100 が使用されます。 Japanese_BIN2 は、通常、Windows 以外のプラットフォームからのデータ、または SQL Server リレーショナル データベース エンジン以外のデータ ソースからのデータを移行するプロジェクトで使用されるのが一般的です。

  Japanese_Bushu_Kakusu_100 が、Analysis Services のワークロードを実行するサーバーで使用されることはまれです。

• 韓国では、Korean_100 が推奨されます。 Korean_Wansung_Unicode も使用可能なリストにまだ含まれていますが、これは非推奨になりました。

オブジェクト識別子の大文字と小文字の区別

SQL Server 2012 SP2 以降、オブジェクト ID の大文字と小文字の区別が照合順序とは関係なく適用されるようになりました。ただし、動作は言語によって異なります。

大文字小文字の区別がオブジェクト識別子に与える影響

上記の表に記載した大文字小文字の区別に関する動作の影響を受けるのは、オブジェクト識別子だけです。オブジェクト名は影響を受けません。 ソリューションの動作が変わった場合 (比較の前と後で、または SQL Server 2012 SP2 以降をインストールする前と後で)、最も可能性があるのは処理の問題です。 クエリは、オブジェクト識別子の影響を受けません。 DAX と MDX のどちらのクエリ言語でも、式エンジンはオブジェクト名 (識別子ではない) を使用します。

注
大文字小文字の区別に関連するコードの変更は、一部のアプリケーションの互換性に影響を与える変更です。 詳細については、「SQL Server 2012 の Analysis Services 機能における重大な変更」を参照してください。

Excel、SQL Server Profiler、および SQL Server Management Studio を使用するロケールのテスト

翻訳をテストする場合は、接続に翻訳の LCID を指定する必要があります。 「SSAS から Excel に別の言語を取得する」で説明されているとおり、Excel を使用して翻訳をテストすることができます。

そのためには、.odc ファイルを手作業で編集して、ロケール識別子の接続文字列プロパティを組み込みます。 Adventure Works のサンプル多次元データベースで試すことができます。

• 既存の .odc ファイルを検索します。 Adventure Works の多次元データベース用のものを見つけ、ファイルを右クリックして、メモ帳で開きます。

• 接続文字列に Locale Identifier=1036 を追加します。 ファイルを保存して閉じます。

• Excel | [データ] | [既存の接続] を開きます。 一覧をフィルター処理して、このコンピューター上の接続ファイルだけを表示します。 Adventure Works に対する接続を見つけます (名前を注意深く確認してください。2 つ以上見つかることがあります)。 接続を開きます。

  Adventure Works サンプル データベースからフランス語の翻訳が表示されます。

  

確認のために、SQL Server Profiler を使用してロケールを調べることができます。 Session Initialize イベントをクリックし、テキスト領域のプロパティ一覧を参照すると、<localeidentifier>1036</localeidentifier> が見つかります。

Management Studio では、サーバー接続にロケール識別子を指定できます。

• オブジェクト エクスプローラー | [接続] | Analysis Services | [オプション] で、[追加の接続パラメーター] タブをクリックします。

• 「Local Identifier=1036」と入力し、[接続] をクリックします。

• Adventure Works データベースに対する MDX クエリを実行します。 クエリの結果は、フランス語の翻訳になっているはずです。

  

翻訳が含まれるソリューションで MDX クエリを作成する

翻訳では、Analysis Services オブジェクトの名前の表示情報が提供されますが、同じオブジェクトの識別子は翻訳されません。 可能であれば必ず、翻訳されたキャプションと名前ではなく、Analysis Services オブジェクトの識別子とキーを使用してください。 たとえば、多次元式 (MDX) ステートメントおよびスクリプトのメンバー名ではなく、メンバー キーを使用して、複数の言語間での移植性を確保します。

注
表形式オブジェクト名では、照合順序に関係なく、常に大文字と小文字が区別されないことに注意してください。 一方、多次元オブジェクト名は、照合順序の大文字小文字の区別に従います。 多次元オブジェクトの名前のみ大文字と小文字が区別されるため、多次元オブジェクトを参照するすべての MDX クエリでは、大文字と小文字を正しく区別するように注意してください。

日付と時刻の値を含む MDX クエリを作成する

次の推奨事項に従えば、日付と時刻に基づく MDX クエリが、さまざまな言語に移植しやすくなります。

1. 比較と演算には数値のパーツを使用する

   月や曜日の比較および演算を実行する場合は、文字列形式を使用せず、数値形式の日時パーツを使用します (たとえば、MonthName ではなく MonthNumberofYear を使用する)。 数値は、言語の翻訳による違いから影響をいちばん受けにくい形式です。

2. 結果セットには文字列形式を使用する

   エンドユーザーに表示される結果セットを作成する際は、文字列形式 (MonthName など) を使用することを検討してください。用意した翻訳が多言語の対象ユーザーに役立つからです。

3. 汎用の日付および時刻情報には ISO 日付形式を使用する

   1 人の Analysis Services のエキスパートは、次のように推奨しています。「私は、SQL または MDX でクエリに渡す日付文字列で常に ISO 日付形式 yyyy-mm-dd を使用しています。あいまいな点がなく、クライアントまたはサーバーの地域設定に関係なく動作するからです。 あいまいな日付形式を解析するサーバーが地域の設定に従う必要があるのは確かですが、解釈の問題の起きない選択肢があるのなら、いつでもそれを選んでよいと思います」。

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

   次の MDX クエリは、フォーラムの投稿から借用したものです。基になる地域の設定に関係なく、Format を使用して特定の形式で日付を返す方法を示します。

   元の投稿は、「SSAS 2012 generates invalid dates (SSAS 2012 が無効な日付エラーを生成する)」(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]
   

関連項目

概念

Analysis Services 多次元のグローバリゼーションのシナリオ

国際化に対応した Transact-SQL ステートメントの記述