Microsoft SQL Server 2005 のインターナショナル機能

SQL Server User Education
Microsoft Corporation

2007 年 2 月

適用対象:
   Microsoft SQL Server 2005
   Unicode

    概要 : このホワイト ペーパーでは、Microsoft SQL Server の開発者を対象に、SQL Server 2005 のインターナショナル機能について説明します。取り上げているトピックは、Unicode の説明、SQL Server 2005 の補助文字の追加サポート、さまざまなバージョンの SQL Server における照合の変更、データ型の変更、パフォーマンス、データ プロバイダの更新、SQL Server 2005 Analysis Services および Integration Services の新しいインターナショナル サポート機能などです。

IntlFeaturesSQL2005.doc

目次

概要
SQL Server 2005 の Unicode サポート
SQL Server 2005 のデータ型
パフォーマンスと記憶域
システム テーブルのメタデータ情報の移行
照合順序
サーバーとクライアント間の通信 (データ アクセス テクノロジ)
ユーザー インターフェイスの多言語データ
多言語の Transact-SQL
SQL Server 2005 でのロケールのサポート
SQL Server 2005 Integration Services
コマンド ライン ユーティリティを使用した多言語データの操作
SQL Server Analysis Services のインターナショナル機能
SQL Server 2005 での XML のサポート
フルテキスト検索の機能強化
他のデータベース製品とのやり取り
結論
謝辞
付録 A 照合順序サフィックス
付録 B Windows でサポートされているロケール
付録 C SQL 固有の並べ替え順序
付録 D SQL Server 2005 でサポートされている言語
付録 E SQL Server 2005 で追加されたフルテキスト言語
付録 F SQL Server 2005 で更新された照合順序

概要

Microsoft® SQL Server™ 2005 は、SQL Server 2000 で導入された Unicode および XML サポートに基づいています。また、SQL Server Management Studio および Business Intelligence Development Studio を含む、新しい強力な開発およびクエリ ツール セットが追加されています。SQL Server 2005 は、堅牢な多言語機能により、インターナショナルな運用および環境をサポートするための非常に強力なデータベース製品かつアプリケーション プラットフォームとなっています。

このホワイト ペーパーでは、グローバルな状況におけるこれらの機能の概要を示します。インターナショナルおよび多言語の要件に関係する機能を示し、デザインの決定がプロジェクトのさまざまな側面にどのように影響するかを説明します。

注 **:   **このホワイト ペーパーでは、国際文字の例を示すのに国際フォント (Arial Unicode MS、Latha、Mangal、PmingLiu、Gulim、SimSun、MS 明朝) を使用しています。これらのフォントがインストールされていなくても、このホワイト ペーパーの利用に重要な影響を及ぼすことはありません。

SQL Server 2005 の Unicode サポート

Unicode サポートは、SQL Server 2005 の多言語サポートの基礎となるものです。

Unicode は、Unicode コンソーシアム (すべての言語に対して単一の文字セットを推進する組織) によって作成された規格です。SQL Server 2005 では Unicode 規格バージョン 3.2 をサポートしています。Unicode 規格バージョン 3.01 は、Unicode のすべてのコード ポイントと一致する国際規格である ISO-10646 と同一です。

Unicode は、プラットフォーム、プログラム、言語に関係なく、すべての文字に一意のコード ポイントを割り当てることによって機能します。Unicode をサポートするプログラムは、どのような言語のデータでも処理できます。Unicode は世界中のすべての言語のすべての文字を処理できるようにデザインされているので、異なる文字のセットを扱うために他のコード ページを必要とすることがありません。

Unicode システムは一貫して同じビット パターンを使用してすべての文字を表すため、システム間を移動したときに文字が誤って変換されるという問題は起こりません。

国際的なデータベースの文字データを管理する最も簡単な方法は、char、varchar、text などの非 Unicode データ型を使用するのではなく、常に nchar、nvarchar、nvarchar(max) などの Unicode データ型を使用することです。それによって、クライアントには、他のすべてのクライアントと同じ文字でデータが表示されます。国際的なデータベースを使用するすべてのアプリケーションで、非 Unicode データ型の変数の代わりに Unicode データ型の変数を使用すれば、システム内で文字の変換を行う必要がなくなります。

**  注** :   ntext データ型は、将来のバージョンの Microsoft SQL Server では削除される予定です。

ポイントとそれが表す文字は、視覚表現に使用される "グリフ" とは別のものです。ISO 規格 (ISO/IEC 9541-1) では、グリフは "特定のデザインに依存しない認識可能な抽象的グラフィック シンボル" と定義されています。したがって、文字は必ずしも常に同じグリフあるいは一意のグリフで表現されるとは限りません。選択した書体によって、特定の 1 つのコード ポイントまたは一連のコード ポイントを表現するのに使用されるグリフが決まります。
詳細については、Unicode コンソーシアムの Web サイトを参照してください。

エンコード

Unicode は、文字にコード ポイントを割り当てますが、メモリ、データベース、Web ページでのデータの表現方法を実際に指定するわけではありません。ここで、Unicode データのエンコードが効力を発揮します。Unicode のエンコードにはさまざまなものがあります。ほとんどの場合は Unicode データ型を選択するだけでよく、その詳細を気にする必要はありません。ただし、次のような場合にはエンコードを理解することが重要になります。

• Unicode を別の方法でエンコードする可能性があるアプリケーションを扱う場合

• 他のプラットフォーム (Microsoft Windows® 以外) または Web サーバーにデータを送信する場合

• 他のエンコードに対してデータのインポートやエクスポートを行う場合

Unicode 規格では、UTF-7、UTF-8、UTF-16、UTF-32 など、単一の文字セットの複数のエンコードを定義しています。ここでは、次の一般的なエンコードについて説明します。

• UCS-2

• UTF-16

• UTF-8

通常、SQL Server では、UCS-2 エンコード体系で Unicode が格納されます。ただし、多くのクライアントでは、UTF-8 などの他のエンコード体系で Unicode が処理されます。Web ベース アプリケーションでは、このシナリオが頻繁に発生します。Microsoft Visual Basic® アプリケーションでは、文字列は UCS-2 エンコード体系で処理されます。したがって、Visual Basic アプリケーションと SQL Server のインスタンスとの間では、エンコード体系の変換を明示的に指定する必要はありません。

SQL Server 2005 は、Unicode (UTF-16) を使用して XML データをエンコードします。xml 型の列のデータは、ドキュメントの順序や再帰構造などの XML モデルの特性をサポートするために、バイナリ ラージ オブジェクト (BLOB) として内部形式で格納されます。したがって、サーバーから取得される XML データは UTF-16 で取り出されます。データ取得のために異なるエンコードが必要な場合、アプリケーションは、取得された UTF-16 データに対して変換を行う必要があります。SQL Server Books Online の「XML の推奨事項」には、varchar(max) 列から取得された XML データのエンコードを明示的に宣言する方法の例が示されています。

UTF-16 エンコードが使用される理由は、UTF-16 エンコードが 2 バイトまたは 4 バイト文字を処理することが可能であり、バイト指向のプロトコルに従って処理されるためです。これらの特性により、UTF-16 は、使用しているエンコードおよびバイト記述体系が異なるコンピュータ間での通信に適しています。一般的に XML データはネットワーク間で広く共有されるので、XML データをクライアントにエクスポートする場合はデータを既定の UTF-16 のままでデータベースに保存するのが適切です。

UCS-2

UCS-2 は UTF-16 の前身です。UCS-2 と UTF-16 の相違点は、UCS-2 はすべての文字を 16 ビット値 (2 バイト) で表現する固定長のエンコードであるため補助文字をサポートしないという点です。UCS-2 は UTF-16 としばしば混同されます。UTF-16 は、Microsoft Windows オペレーティング システム (Windows NT™、Windows 2000、Windows XP、Windows CE) で内部的にテキストを表現するのに使用されますが、UCS-2 は、UTF-16 よりも多くの制限があります。

**  注** **:   **Windows オペレーティング システムでの Unicode の使用に関する最新情報については、Microsoft Developer Network (MSDN) ライブラリの「Unicode」を参照してください。Windows アプリケーションでは内部的に UTF-16 を使用し、他の形式を使用する必要がある場合にのみインターフェイス上の "シン レイヤ" の一部として変換を行うことをお勧めします。

Microsoft SQL Server 2000 および Microsoft SQL Server 2005 において Unicode で格納される情報には、UCS-2 エンコードが使用されます。UCS-2 エンコードは、使用される文字に関係なく、すべての文字を 2 バイトで格納します。したがって、ラテン文字の "A" は、キリル文字の Sha (Ш)、ヘブライ文字の Lamed (ל)、タミール文字の Rra (ற)、日本語のひらがなの E (え) と同じように扱われます。そして、それぞれが一意のコード ポイントを持ちます (これらの文字の場合、コード ポイントはそれぞれ U+0041、U+0248、U+05DC、U+0BB1、U+3048 です。4 桁の各 16 進数は、UCS-2 で使用される 2 バイトを表します)。

UCS-2 は、65,536 のコード ポイントのエンコードしか行えないため、補助文字はネイティブに処理されません。その代わりに、補助文字は未定義の Unicode サロゲート文字のペアとして処理され、これらのサロゲート文字がペアになったときに補助文字が定義されます。ただし、SQL Server では、損失や破損の危険性なく補助文字を格納できます。カスタム CLR 関数を作成すれば、サロゲート ペアを使用できるように SQL Server の機能を拡張できます。サロゲート ペアおよび補助文字の使用の詳細については、このホワイト ペーパーの「補助文字とサロゲートペア」を参照してください。

注 **:   **補助文字は、"補助コード ポイントを持つ Unicode でエンコードされた文字 " と定義されています。補助コード ポイントの範囲は U+10000 ～ U+10FFFF です。

UTF-8

UTF-8 は、コンピュータ上のバイト順に依存しない方法で Unicode データを扱うように設計されたエンコード体系です。UTF-8 は、ASCII や、8 ビット エンコードを必要とする他のバイト指向のシステム (さまざまなエンコード、バイト順、言語が使用される膨大な数のコンピュータを受け持つ必要があるメール サーバーなど) を使用する場合に便利です。SQL Server 2005 は、UTF-8 形式ではデータを格納しませんが、XML (Extensible Markup Language) データを処理するために UTF-8 をサポートしています。詳細については、このホワイト ペーパーの「SQL Server 2005 での XML サポート」を参照してください。

Oracle や Sybase SQL Server などの他のデータベース システムは、UTF-8 形式での Unicode の格納をサポートしています。サーバーの実装にもよりますが、この方がデータベース エンジンを技術的により簡単に実装できます。その理由は、1 バイトずつデータを処理するためにサーバー上の既存のテキスト管理コードを大幅に変更する必要がないためです。ただし、Windows 環境の場合、UTF-8 形式での格納には次のようないくつかの短所があります。

注 **:   **古いバージョンの Oracle および Java も UCS-2 を使用しており、サロゲートを認識できません。Oracle Corporation は、Oracle 7 でデータベース文字セットとして Unicode のサポートを開始しました。Oracle は、現在、次の 2 つの Unicode データ格納方法をサポートしています : (1) CHAR および VARCHAR2 文字データ型、そしてすべての SQL 名およびリテラルのエンコードに UTF-8。(2) NCHAR、NVARCHAR、NCLOB Unicode データ型の格納には UTF-16。Oracle では、この 2 つの方法を同時に使用できます。

• コンポーネント オブジェクト モデル (COM) の API およびインターフェイスでは、UTF-16/UCS-2 のみサポートされています。したがって、データが UTF-8 形式で格納されている場合は、定数の変換が必要になります。この問題は COM を使用する場合にのみ該当します。通常、SQL Server データベース エンジンが COM インターフェイスを呼び出すことはありません。

• Windows XP と Windows Server™ 2003 カーネルはどちらも Unicode です。UTF-16 は、Windows 2000、Windows XP、および Windows Server 2003 の標準エンコードです。ただし、Windows 2000、Windows XP、および Windows Server 2003 は UTF-8 に対応しています。したがって、データベースで UTF-8 格納形式を使用すると、多くの追加の変換が必要になります。通常、変換に必要な追加のリソースは、SQL Server データベース エンジンには影響しませんが、クライアント側の多くの操作に影響する場合があります。

• UTF-8 は、文字列操作の多くで時間がかかる場合があります。文字が固定幅ではないため、並べ替え、比較、および事実上すべての文字列操作が低速になる可能性があります。

• UTF-8 は、ほとんどの場合に 2 バイトより多くのバイト数が必要となり、サイズの増加によりディスクおよびメモリの使用量が大きくなります。

このような短所はあるものの、インターネット経由での通信において XML が重要な規格となっていることから、UTF-8 を既定で使用することも必要に応じて検討してください。

UTF-16

UTF-16 は Microsoft および Windows オペレーティング システムのエンコード標準です。UTF-16 は、追加の 1,048,576 文字を処理するために考えられた拡張機能です。サロゲート範囲の必要性は、Unicode 2.0 がリリースされる前から認識されていました。なぜなら、すべての言語のすべての文字に単一のコード ポイントを持たせるという Unicode の目標は、たった 65,536 文字では実現できないことがはっきりしていたからです。たとえば、中国語などの一部の言語では、使用がまれであっても出版や学問上は重要な歴史的、文学的な表意文字などの文字のエンコードには、少なくとも同程度の数の文字が必要となります。次のセクションでは、サロゲート範囲について詳しく説明します。

UCS-2 と同様、UTF-16 も "リトル エンディアン" バイト順を使用します (Windows ではすべてがこのバイト順を使用します)。"ビッグ エンディアン" とは対照的に、リトル エンディアンでは、メモリの最下位アドレスに下位バイトが格納されます。バイトの順序は、オペレーティング システムのレベルで重要になります。SQL Server では、Windows プラットフォームで動作する他のアプリケーションと同じく、リトル エンディアンのバイト順が使用されます。したがって、0x1234 のような 16 進法の語は、0x34 0x12 としてメモリに格納されます。場合によっては、文字のエンコードを正しく読み取るため、バイト順を明示的に逆にしなければならないこともあります。SQL Server Integration Services には、Unicode テキストのバイト順を変換する機能が用意されています。詳細については、このホワイト ペーパーの「SQL Server 2005 Integration Services」を参照してください。

補助文字とサロゲート ペア

、少なくともデータを失うことなく格納できることを意味しています。Microsoft Windows では、通常、UTF-16 を使用して文字データが表現されます。16 ビットの使用により、65,536 の一意の文字表現が可能になります。しかし、人間の言語で使用されている記号をすべてカバーするには、これでも十分ではありません。UTF-16 では、一部のコード ポイントは、最初の 2 バイトのすぐ後に別のコード ポイントを追加して、サロゲート範囲の一部として文字を定義します。

Unicode 規格には、1,114,112 もの文字を定義できる文字の "面" が 16 あります。0 面、つまり基本多言語面 (BMP) は、世界で使用されている文字の大部分、出版で使用される文字、数学記号および技術記号、幾何学模様、レベル 100 の Zapf Dingbats すべて、および句読記号を表現できます。

BMP を除き、大部分の面の文字はまだ定義されていませんが、補助文字を表現するために使用されます。補助文字は、主に歴史的文書および古典文学に使用され、中国語、韓国語、および日本語の豊富な文学的遺産のエンコードを支援します。また、補助文字には、ルーン文字やそれ以外の歴史的な文字、音楽記号なども含まれます。

UTF-16 では、サロゲート ペアと呼ばれるコード ポイントのペアは、主要な文字セット (BMP) 以外の文字を表現するのに使用されます。サロゲート領域は、Unicode の U+D800 ～ U+DFFF の領域であり、1,024 の下位サロゲート値と 1,024 の上位サロゲート値が含まれます。上位サロゲート (U+D800 ～ U+DBFF) と下位サロゲート (U+DC00 ～ U+DFFF) は結合され、100 万を超える数の文字の表現が可能になります。

サロゲート ペアの片方だけでは有効と見なされません。有効なものにするには、常に上位サロゲートの後に下位サロゲートがなければなりません。このため、サロゲートの検査は範囲の検査の問題となります。この検査は、DBCS (2 バイト文字システム) 文字の検出に必要となる複雑な規則よりは簡単です。

UCS-2 がサロゲートに対応していなくても、SQL Server 2000 および SQL Server 2005 はどちらもサロゲート ペアを格納できます。SQL Server は、1 つの文字ではなく 2 つの未定義の Unicode 文字としてサロゲート ペアを扱います。通常、このようなアプリケーションは "サロゲート ニュートラル" または "サロゲート セーフ" と呼ばれます。これは、データとやり取りする固有の機能を持ってはいないものの

これに対して、"サロゲート対応" アプリケーションは、サロゲート ペアを考慮できるだけでなく、結合文字や、特殊な処理が必要なそれ以外の文字を扱うこともできます。適切なアプリケーションは、わずかなサブルーチンだけで、分離されたサロゲートを検出して再結合することができます。サロゲート対応アプリケーションには、Microsoft Word や Internet Explorer 5 以降などがあります。

SQL Server で補助文字を使用する場合は、次の点に注意してください。

• サロゲート ペアは、2 つの分離された Unicode コード ポイントと見なされるため、補助文字を 1 つ保持するには nvarchar(n) のサイズを 2 にする必要があります (つまり、サロゲート ペア用の領域)。

• 補助文字は、データベース オブジェクトの名前など、メタデータ内で使用することはできません。一般に、メタデータで使用するテキストは、識別子の規則に従う必要があります。詳細については、SQL Server Books Online の「識別子」を参照してください。

• 標準的な文字列操作は補助文字に対応していません。SUBSTRING(nvarchar(2),1,1) などの操作は、補助文字のサロゲート ペアの上位サロゲートのみを返します。LEN 関数は、検出された各補助文字を 2 文字として計算した合計を返します (上位サロゲートの 1 文字と下位サロゲートの 1 文字)。ただし、補助文字に対応したカスタム関数を作成することもできます。SQL Server Books Online の「補助文字対応文字列操作」の StringManipulate サンプルでは、このような関数の作成方法について説明しています。

• 補助文字の並べ替えおよび検索の動作は、照合順序によって変わることがあります。新しい 90_ および BIN2 照合順序では、補助文字は正しく比較されます。これに対して古い照合順序および標準 Windows 照合順序では、すべての補助文字は他のすべての補助文字と等しいと見なされます。たとえば、日本語および韓国語の既定の照合順序では補助文字が処理されませんが、Japanese_90 および Korean_90 では処理されます。

Unicode コード ポイント、サロゲート対応アプリケーション設計のベスト プラクティス、Unicode データの使用に関する詳細については、「グローバリゼーションのステップ バイ ステップ : ユニコードへの対応」を参照してください。Unicode 規格でサポートされている文字範囲の詳細については、「Unicode Technical Standard #18」の「Unicode Regular Expressions」を参照してください。

結合文字

"結合文字" とは、外観または意味を変えるために他の文字と共に使用する文字のことです。結合された文字は 1 つのグリフになります。たとえば、ヨーロッパ言語で使用される分音文字は、分音文字が付加された文字として、または合成済み文字として表示される結合文字です。

.NET Framework では、結合文字のシーケンスは 1 つのテキスト要素 (つまり、1 つの文字として表示される 1 つのテキスト単位) として扱われます。テキスト要素は並べ替え要素とは異なります。たとえば、一部の照合順序では、"CH" という文字は結合文字ではありません。これらは 2 つの別々のテキスト要素ですが、1 つの並べ替え要素として扱うことができます。

注 **:   **一方、SQL 関数では一般に、結合文字は補助文字と同様に扱われます。SQL 関数は、結合文字を 2 つの別々の Unicode コード ポイントとして処理します。補助文字を正確にカウントして比較するカスタム関数の作成方法の例については、StringManipulate サンプルを参照してください。

結合文字が並べ替え要素にマップされる方法は、Unicode 規格および照合順序によって異なります。一部の結合された文字は、異なるコード ポイントがいくつ含まれているかにかかわらず、常にその派生形と同じものと見なされます (たとえば、分音文字が付加されたラテン文字は、分音文字が含まれる合成済み文字と同じものとして扱われます)。これに対し、ある照合順序では、分音文字の存在によって結果が異なるように、文字列の並べ替えまたは比較を行うことができます。

結合文字は、もともと Unicode 2.0 で定義されていました。詳細については、Unicode 4.0.1 仕様の「Special Areas and Format Characters」を参照してください。また、Unicode コンソーシアムでは、特に結合文字とその処理に関する FAQ を公開しています。.NET Framework での結合文字の処理方法に関する詳細については、『.NET Framework 開発者ガイド』の「正規化」を参照してください。

GB18030 のサポート

GB18030 (GB18030-2000) は中華人民共和国 (PRC) が単独で中国語の文字のエンコードについて義務付けている標準規格です。拡張コード ページ、および Unicode へのマッピング テーブルの両方が指定されています。2006 年 8 月 1 日現在、中国で販売されるすべてのソフトウェア製品には、この文字セットのサポートが公式に義務付けられています。GB18030 の準拠には、以前はサポートされていなかったいくつかの言語 (チベット語、モンゴル語、イ語、ウイグル語など) をサポートするための要件が含まれます。

GB18030 では、文字は 1 バイト、2 バイト、または 4 バイトです。また、Unicode への GB18030 4 バイト シーケンスのマップを可能にするために、サロゲート ペアが使用されます。

SQL Server 2005 では、GB18030 でエンコードされた文字は、この文字がクライアント側のアプリケーションからサーバーに入力されたときにこの文字を認識することによってサポートします。SQL Server 2005 は、この文字を変換し、ネイティブで Unicode として格納します。サーバーに格納された GB18030 文字は、それ以降の操作では Unicode 文字として処理されます。GB18030 にはシステム ロケールがありません。Unicode との変換を可能にするのは、コード ページ識別子だけです。GB18030-2000 の Microsoft コード ページ識別子は 54936 です。

GB18030 文字は並べ替え操作と比較操作で使用できますが、SQL Server 90 よりも前の照合順序では言語的な意味ではなく、コード ポイントのみを基に比較が行われます。GB18030 文字を使用する際には、その点に留意してください。ORDER BY、GROUP BY、および DISTINCT などの操作で GB18030 文字を使用する場合は注意してください。GB18030 文字と GB18030 以外の文字が同じ操作で使用される場合は、特に注意が必要です。GB18030 文字で意味のある文字列比較を行えるようにするには、照合順序名に 90 というサフィックスが付いた、SQL Server 90 の新しい照合順序バージョンを使用します。たとえば、Chinese_PRC 照合順序の代わりに、Chinese_PRC_90 を使用します。

GB18030 標準のサポートを有効にするには、GB18030 と Unicode の変換をサポートするフォント ファイルとライブラリが含まれるサポート パッケージ (「マイクロソフト サポート オンライン」ポータルから入手可能) をインストールします。このサポート パッケージは、Windows XP および Windows 2000 上で動作する単一のワールドワイドなバイナリです。ただし、システムには、オプションの東アジア言語サポートをインストールする必要があります。Windows Vista™ には、中国の少数民族の言語 (チベット語、モンゴル語、イ語、ウイグル語など) のフォントおよびキーボード レイアウトを含む、GB18030 標準のサポートが含まれています。これらの言語は中国語 (PRC) のロケールを使用します。

注 **:   **GB18030 のバイトを Unicode 文字に変換する一部の関数 (BytesToUnicode など) は、Vista ではサポートされていません。Vista で GB18030 のバイトを Unicode 文字に変換する場合は、MultiByteToWideChar 関数を使用してください。

Microsoft 製品の GB18030 標準のサポートに関する詳細については、「マイクロソフトのグローバルな開発とコンピューティング」ポータルを参照してください。

SQL Server 2005 のデータ型

ここでは、SQL Server 2005 の新しいデータ型について取り上げ、SQL Server 2005 のデータ型を使用した各種言語データの格納に関する問題について説明します。

非 Unicode テキスト型 : char、varchar、text、varchar(max)

char、varchar、varchar(max)、text の各データ型で格納されたテキスト データを扱う場合に考慮すべき最も重要な制約は、システムは単一のコード ページの情報しか検証できないという点です (複数のコード ページのデータを格納することもできますが、これはお勧めできません)。

データの検証および格納に使用される正確なコード ページは、列の照合順序によって異なります。列レベルの照合順序が定義されていない場合は、データベースの照合順序が使用されます。特定の列に使用されているコード ページを調べるには、次のコード例に示すように COLLATIONPROPERTY 関数を使用します。

SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage') 936
SELECT COLLATIONPROPERTY('Latin1_General_CI_AI', 'CodePage')
1252
SELECT COLLATIONPROPERTY('Hindi_CI_AI_WS', 'CodePage')
 0 

最後の例では、ヒンディー語のコード ページとして 0 (Unicode) が返されています。この例から、グルジア語やヒンディー語などの多くのロケールは、Unicode のみの照合順序であるため、コード ページを持たないことがわかります。Unicode のみの照合順序は、char、varchar、text のデータ型が使用される列には不適切です。また、一部の照合順序は非推奨となっています。使用可能な照合順序、および Unicode のみの照合順序を示したリストについては、SQL Server Books Online の「セットアップでの照合順序の設定」を参照してください。

    重要 **:   **SQL Server 2005 では、text データ型ではなく varchar(max) データ型を使用してください。text データ型は、将来のバージョンの Microsoft SQL Server では削除される予定です。詳細については、SQL Server Books Online の「大きな値のデータ型の使用」を参照してください。

Unicode データを Unicode 以外の列に挿入する必要がある場合は、WideCharToMultiByte API、および照合順序に関連付けられたコード ページによって、列が内部的に Unicode から変換されます。ある特定のコード ページの文字が表現できない場合、その文字は疑問符 (?) で置き換えられます。したがって、データ内に疑問符がランダムに出現していたら、それは変換後の文字が特定できないことによりデータが破損していることを意味します。また、Unicode データ型への移行によってアプリケーションに利益がもたらされる可能性があることも意味します。

照合順序でサポートされていない Unicode 以外の型の文字列リテラルを使用すると、その文字列はまず、データベースの既定の照合順序から派生したデータベースの既定のコード ページを使用して変換されます。

発生する可能性があるもう 1 つの問題は、サポート対象の文字のすべてがコード ページに含まれていない場合、データを格納できないことです。多くの場合、Windows は特定のコード ページを "最適な" コード ページと見なします。したがって、そのコード ページを使用してすべてのテキストを処理できるという保証はありません。これは単に使用できる最適なコード ページにすぎません。例としてアラビア文字が挙げられます。これは、バルーチー語、ベルベル語、ペルシア語、カシミール語、カザフ語、キルギス語、クルド語、パシュトー語、シンド語、ウイグル語、ウルドゥー語など、さまざまな言語で使用されています。しかし、これらのすべての言語には、Windows コード ページ 1256 で定義されているアラビア語以外の文字があります。アラビア語の照合順序を持つ非 Unicode 列にアラビア語のコード ページに含まれていない文字を格納すると、文字が疑問符に変換されます。

Unicode テキスト型 : nchar、nvarchar、nvarchar(max)、ntext

SQL-92 仕様では、"N" ("国別" データ型の意味) で始まるデータ型が定義されています。ただし、この仕様は、Unicode にこのデータ型を使用することを明確に求めていません。これらのデータ型の実際の定義は、データベースのプラットフォームまたは開発者に委ねられています。SQL Server 2000 および SQL Server 2005 では、これらのデータ型は、Unicode エンコードの UCS-2 と同等であると定義されています。ただし、他のデータベース サーバーを使用する場合、この "N" データ型が特に Unicode を意味しているわけではないことを知っている必要があります。"N" データ型を Unicode として定義するのは Microsoft SQL Server の場合のみです。

SQL Server 2005 の新しいデータ型である nvarchar(max) は、最大 2 ギガバイト (GB) のデータを保持し、ntext データ型に代わって使用することが推奨されます。

    重要 **:   **SQL Server 2005 では、ntext データ型ではなく nvarchar(max) データ型を使用してください。ntext データ型は、将来のバージョンの Microsoft SQL Server では削除される予定です。詳細については、SQL Server Books Online の「大きな値のデータ型の使用」を参照してください。

ヒンディー語やタミール語などの複雑な文字体系の格納については、データが適切な順序になっていることを確認してください。タミール語などの多くの言語では、テキストを表示するときは特定の文字を並べ替えるように指定されています。したがって、メモリに格納されているテキストの論理順序は、ユーザー インターフェイスに表示される順序と異なる場合があります。インド語派のすべての言語、アラビア語、ペルシア語、ヘブライ語、それ以外の多くの言語のような複雑な文字体系の言語であっても、データは常に適切な論理順序で格納する必要があります。このようなデータの実際の表示は、また別の問題になります (このホワイト ペーパーの「ユーザー インターフェイスの多言語データ」を参照)。

"N" 列は、任意の 1 つの言語または複数の言語のデータをサポートできますが、データを並べ替える際には、1 つの照合順序しか選択できません。照合順序の選択方法の詳細については、このホワイト ペーパーの「照合順序」を参照してください。このホワイト ペーパーでこれまでに説明したコード ページ制約は、Unicode 列に適用されません。

SQL Server 2005 では、追加の関数を作成して、補助文字を伴う文字列操作および照合順序動作を強化することができます。たとえば、Microsoft SQL Server 2005 の「StringManipulate サンプル」では、補助文字に対応した文字列処理について説明しています。このサンプルでは、組み込まれているものと同じ文字列操作関数を提供する、5 つの Transact-SQL 文字列関数の実装方法を示します。ただし、この文字列操作関数では、補助文字を認識する機能が追加されているため、Unicode と補助文字の両方の文字列を処理できます。

CLR データ型

Microsoft SQL Server では、SQL Server プログラミングで使用するカスタム データ型を定義することによって、SQL 型システムを拡張できます。このようなユーザー定義型は、カスタムの日付型、時刻型、通貨型、および拡張数値型の作成、あるいはエンコードされたデータまたは暗号化されたデータに適しています。

ユーザー定義型 (UDT) は、テーブル内の列の型、または Transact-SQL 言語の変数やルーチン パラメータの定義に使用できます。ユーザー定義型のインスタンスは、テーブル内の列、バッチ内の変数、関数やストアド プロシージャ、または関数やストアド プロシージャの引数になります。ユーザー定義型は、いずれかの CLR 言語のマネージ クラスとして実装してから、SQL Server に登録します。Visual Basic または Microsoft Visual C#® を使用したユーザー定義型の実装方法の詳細については、SQL Server Books Online の「ユーザー定義型のコーディング」を参照してください。

ユーザー定義型を使用してサーバーのスカラ型システムを拡張し、SQL Server データベースに CLR オブジェクトを格納することができます。UDT には、複数の要素や、ユーザーが定義した特別な動作を含めることができます。この点が、1 つの SQL Server システム データ型で構成される従来の別名データ型とは異なります。たとえば、SQL Server Books Online で提供されている Currency UDT サンプルでは、特定のカルチャの通貨システムでの金額の処理がサポートされます。定義するフィールドは 2 つあります。string 型の CultureInfo フィールドでは、通貨の発行元 (en-us など) を指定します。decimal 型の CurrencyValue フィールドでは金額を指定します。

UDT はシステム全体からアクセスされるため、複雑なデータ型に使用すると、パフォーマンスが低下することがあります。通常、複雑なデータは従来の行やテーブルを使用する場合に最適になるようにモデル化されています。SQL Server Books Online には、カスタム ユーザー定義型の作成および使用方法を示すいくつかのサンプルが用意されています。SQL Server 2005 の UTF8String サンプルは、データベースの型システムを拡張して UTF-8 でエンコードされた値のストレージを提供するユーザー定義データ型の実装方法を示します。この新しいデータ型では、Unicode 文字列と UTF-8 との変換を行うコードも実装されます。詳細については、SQL Server Books Online の「UTF-8 文字列ユーザー定義データ型 (UDT)」を参照してください。

その他の例については、SQL Server Books Online の「CLR プログラミング サンプル」を参照してください。

XML データ型

XML データ型によって、XML のフラグメントやドキュメントを SQL Server データベースに格納できます。XML データ型のインスタンスは、テーブル内の列、関数またはストアド プロシージャ引数、関数またはストアド プロシージャ内の変数に使用できます。また、XML データ型は、XML インスタンス データの検証制約と型情報の両方を提供する関連 XML スキーマを指定することによって特殊化できます。

XML データ型インスタンスでの操作は、組み込み型 XML クエリ メソッドを使用して実行されます。これらのメソッドは、XML データに適したクエリおよびデータ操作ステートメントを受け入れます。ユーザーは、XML データ型変数または列に保管された XML に対してクエリ (XQuery) を指定し、XML インスタンスに更新 (挿入/更新/削除) を適用できます。また、XSD を使用して XML 列のインデックスを作成し、クエリ パフォーマンスを向上することもできます。

xml データ型、および、XML データの処理をサポートする SQL Server 2005 の機能の詳細については、このホワイト ペーパーの「SQL Server 2005 での XML のサポート」を参照してください。

日付/時刻型 : datetime、smalldatetime

SQL Server 2000 および SQL Server 2005 で使用される日付と時刻のデータ型の定義は次のとおりです。

datetime
グレゴリオ暦の 1753 年 1 月 1 日～ 9999 年 12 月 31 日の日付と時刻を 1/300 秒の精度 (3.33 ミリ秒または 0.00333 秒) で表します。

smalldatetime
グレゴリオ暦の 1900 年 1 月 1 日～ 2079 年 6 月 6 日の日付と時刻を分単位の精度で表します。29.998 秒以下の smalldatetime 値は最も近い分単位の値に切り捨てられます。29.999 秒以上の値は最も近い分単位の値に切り上げられます。

Microsoft SQL Server はこの範囲外のデータを拒否します。実際のデータは、日付と時刻を表す 2 つの整数 (datetime は 4 バイトの整数、smalldatetime は 2 バイトの整数) として内部的に格納されます。

格納されたデータは、ローカル時刻も世界時も表さず、タイム ゾーン情報を含みません。日付を世界時に変換する必要がある場合は、UTC 日付関数のいずれかを使用します。現在の UTC 時刻は、Microsoft SQL Server のインスタンスが動作しているコンピュータのオペレーティング システムにおける、現在のローカル時刻とタイム ゾーンの設定により求められます。この値にはロケール固有の書式設定がないため、必要に応じて開発者が変換を定義します。SQL Server は、開発者が作成したカスタム ソリューションに依存するのではなくサーバーで実行できるさまざまなロケール固有の変換をサポートしています。この日付形式には CONVERT 関数を呼び出してアクセスします。この関数にはデータ型、式、省略可能な形式を指定します。次の表を参照してください。

次の例は、CONVERT 関数を使用して、現在の日付を特定の形式で表す方法を示しています。

SELECT CONVERT(char, GETDATE(), 100) AS [100]
戻り値:
Aug 16 2000 11:50 AM

ほとんど同じ方法で、データを文字列から日付値へ変換することもできます。

SELECT CONVERT(datetime, 'Aug 16 2000 11:50AM', 100) AS [100]
 戻り値:
 100
 2000-08-16 11:50:00.000

スタイル 130 (クウェートまたはヒジュラ) の日付を char データ型に変換する場合、コード ページ 1256 を使用するアラビア語の照合順序に基づいて Unicode 変換を行わないと、データが壊れる可能性があります。たとえば、次の図は、char に変換された列と nchar に変換された列を示しています。この例では、クライアント コンピュータは EN-US ロケールを使用しています。そのため、char データ型を使用すると、アラビア文字は疑問符に変換されます。nchar データ型の場合はアラビア文字として表示されます。

図 1 CONVERT 関数による日付 / 時刻データ変換

ただし、クエリ エディタに制約があるため、nchar で表された文字列も正しく書式設定されていません (アラビア語のクライアント コンピュータでは正しく表示できます)。次の図は、ヒジュラの日付文字列が実際にどのように表示されるかを示しています。

図 2 ヒジュラの日付文字列

アラビア語が正しく表示されない理由は、アラビア語などの複雑な文字体系にはデータの表示方法を制御する表記ルールが定められているためです。ヘブライ語などの双方向 (BIDI) 言語では、すべてのデータが逆方向に表示されます。アラビア語の場合、その影響はより顕著になります。これは、文字の実際の表記がその前後の文字によって変わってくるためです。Windows 2000 以降のバージョンの Windows、および、アラビア語に対応した以前のバージョンの Windows ではこの問題が発生しません。

さらに、双方向言語では、返される日付文字列自体が問題となる場合もあります。アプリケーション (Internet Explorer など) が使用する双方向テキストのレイアウト ルールにより、日付が次の図のように表示されてしまいます。

図 3 双方向言語の日付文字列の例

この表示順序 (dd hh:mi:ss yyyy mon :) は明らかに目的とする順序ではありません。この問題は、CONVERT 関数で 130 スタイルを使用した場合の一般的な制約と考えることができます。次のクエリのように、文字列の前に適切な Unicode 制御文字を追加すれば、この問題を回避できます。

SELECT NCHAR(8207) + CONVERT(nchar, GETDATE(), 130)

この NCHAR 関数は、指定した Unicode コード ポイント 8207 (16 進数値 0x200F) に基づいた文字を返します。コード ポイント 8207 は Right-to-Left Marker (RLM : 右から左への表示方向を示すマーカー) を表すので、これによって文字列を正しく表示することができます。

パフォーマンスと記憶域

Unicode データ型のいずれかを使用して列を定義する場合、記憶域と処理速度に関する次の問題が発生する可能性があります。

記憶域の増加

Unicode データ型では、1 文字につき 2 バイト以上使用します。これに対し、非 Unicode データ型では、1 文字につき 1 バイト (DBCS 以外のすべてのテキスト) または 2 バイト (DBCS を使用するアジア言語) を使用します。したがって、データにアジア言語のコード ページが使用されない限り、Unicode への変換時には、データを格納するのに 2 倍の領域を使用することになります。既存のデータベースをアップグレードするときや、新規プロジェクトのデータ型を決定するときは、記憶域の増加を考慮しなければなりません。1 つのコード ページ (アジア言語以外) の列にのみデータを格納する場合は、Unicode を使用しない方がディスク領域やメモリを節約することができます。ただし、一般的には、記憶域に対する影響よりも Unicode 変換の利点の方が勝ります。

注 **:   **アジア言語の DBCS データを格納する場合、SQL Server 2005 で使用される UCS-2 エンコード方式は、他の多くのデータベース プログラムで使用される UTF-8 エンコード方式より効率的な傾向があります。これは、アジア言語の大部分の文字を格納するのに UTF-8 では 3 バイト使用されるのに対し、UCS-2 では 2 バイトしか使用されない (補助文字および結合文字を除く) ためです。一方で、ASCII ベースの文字などの非 DBCS 言語では、UTF-8 は通常 1 文字につき 1 バイトしか使用しませんが、UCS-2 は 2 バイト使用します。

処理速度に関する問題

Unicode データ型の使用がパフォーマンスに与える影響は複雑です。次の点を考慮する必要があります。

• Windows XP、Windows Server 2003、または Windows Vista 上で実行する場合、これらのオペレーティング システムは Unicode データを使用することが想定されています。したがって、データを表示するときやオペレーティング システムのサービスを使用するときなど、さまざまな場面で、Unicode 以外の列の変換処理が必要となります。

• ネイティブ DBCS データ形式を処理する場合、大量のデータを読み込むのに時間がかかることがあります。

• 複数のインスタンスまたはデータベース サーバー製品を使用して作業する場合、あるいは、他のアプリケーションとデータを交換する場合、変換処理の回数がパフォーマンスに影響することがあります。

• アジア言語を処理する場合、その言語の DBCS コード ページを使用するより、Unicode を使用した方が高速に処理できます。これは、DBCS データが固定幅ではなく、2 バイト文字と 1 バイト文字が混在しているためです。

• アジア言語以外の言語を処理する場合、Unicode データの並べ替えは、非 Unicode データの並べ替えより処理速度が低下することがあります。

• 最も速い並べ替え順は [バイナリ] です。この場合、大文字小文字が区別されますが、予想外の並べ替え順になる可能性があります。バイナリ並べ替え順を選択した場合、[大文字小文字を区別する]、[アクセントを区別する]、[かなを区別する]、[文字幅を区別する] の各オプションは使用できなくなります。

    重要 **:   **実際のパフォーマンスを評価するには、Unicode と非 Unicode の両方のシナリオでテストする必要があります。

システム テーブルのメタデータ情報の移行

SQL Server 2005 のシステム テーブルには、オブジェクトの識別子を含むすべてのデータが Unicode として格納されます。これにより、データベースや列によって照合順序が異なっていても、問題の発生を最小限に抑えることができます。

SQL Server 2000 から SQL Server 2005 へ移行する場合、最も重要な違いは、SQL Server 2000 は識別子の有効な文字リストの作成に Unicode 2.0 規格を使用するのに対し、SQL Server 2005 は Unicode 規格バージョン 3.2 をサポートするという点だけです。

SQL Server 2000 Service Pack 3 (SP3) 以降のインスタンス、および SQL Server 7.0 SP4 以降のインスタンスは、直接 SQL Server 2005 にアップグレードできます。ほとんどのアップグレード操作はセットアップによって実行できます。ただし、一部のコンポーネントでは、セットアップの実行後にアプリケーションまたはソリューションを移行する機能がサポートされており、場合によっては移行が必須です。

照合順序

並べ替え順は重要であるにもかかわらず、データベース定義で見過ごされがちです。ユーザーは、自分たちが使用している文字での並べ替えを当然のことと思う傾向があります。しかし、ギリシャ語、ロシア語、タイ語など、異なる文字が使用される言語もあります。日本語などの一部の言語では、複雑な順序規則を持つ複数の文字種が使用されます。ヨーロッパ言語でさえ、それぞれの文字の処理方法には大きな違いがあります。たとえば、スペイン語では、"h" の後に "ch" が続く場合、"ch" を 1 つの文字と見なして並べ替えが行われます。

基本的な並べ替えは、並べ替え順を制御する照合順序を使用して他の動作に混じって行われます。並べ替えは、インデックスを作成することで最適化できます。

並べ替えは、"文字列の正規化" と呼ばれる方法も使用して行われます。ここでいう正規化は、データベース開発者が使用する正規化とは意味合いが異なります。文字列の正規化は、2 つの文字列を比較して並べ替えるための方法を指しています。たとえば、ひらがなとカタカナを同じものとして扱うか、アクセントを無視するかなどを指定できます。

非 Unicode 列の場合、照合にはもう 1 つ重要な意味があります。データのコード ページ、つまり表現可能な文字を指定するのが照合順序です。Unicode 列間では、特別な変換や文字のマップなしにデータを移動できます。しかし、非 Unicode 列間で移動したデータは、文字化けや破損が数多く発生するか、少なくとも表示ができなくなります。

SQL Server 6.5 以前のバージョンの照合順序

SQL Server 6.5 以前のバージョンでは、言語全般のコード ページを指定する場合にも照合順序を使用していました。この方法では、種類の異なる並べ替え順の扱いに多くの制約が生じます。たとえば、Latin-1 を使用した場合は西ヨーロッパ言語しかサポートできませんでした。また、SQL Server の 1 つのインスタンスで表現できるロケールの種類の数が制限されていました。つまり、特定の地域で使用される言語の格納または表示しか行えませんでした。異なる言語を使用するには、別のデータベースまたは別のサーバーをセットアップする必要がありました。

SQL Server の新しいバージョンでも、非 Unicode フィールドの照合順序ではこの問題が生じます。

SQL Server 7.0 の照合順序

SQL Server 7.0 では、サーバーごとに Unicode 照合順序と非 Unicode 照合順序がそれぞれ 1 つずつ使用されました。非 Unicode 照合順序は、コード ページと並べ替え順を組み合わせて定義されました。多くの場合、各コード ページは複数の並べ替えをサポートできます。たとえば、ラテン系言語では通常、大文字と小文字を区別するかどうかを指定できます。簡体字中国語では、画数で並べ替えるか、発音に基づいて並べ替えるかを選択できます。

Unicode 照合順序では、あらゆる言語のすべての文字を同じ列に挿入することが可能です。また、提供されるさまざまな照合順序は、照合順序固有の違いが適切に処理されるように設計されています。つまり、ユーザーが期待するデータの提供に "最適" なものを選択できます。たとえば、汎用 Unicode 照合順序を使用してペルシア語のデータを並べ替えることができます。

Unicode 照合順序は、1 つのロケールと複数の比較スタイルで構成されます。通常、ロケールには対象となる国または文化圏と同じ名前が付けられます。その地域の標準に基づいて文字が並べ替えられます。Unicode 規格のすべての文字の並べ替え順を定めた Unicode 照合順序もありますが、指定されたロケールの方が優先されます。サポートされた一意の Unicode 照合順序がロケールにない場合は、汎用 Unicode 照合順序を使用する必要があります。

汎用 Unicode の並べ替え順は、アフリカーンス語、アルバニア語、アラビア語、バスク語、ベラルーシ語、ブルガリア語、英語、フェロー語、ペルシア語、グルジア語 (トラディショナル)、ギリシャ語、ヘブライ語、ヒンディー語、インドネシア語、マレー語、ロシア語、セルビア語、スワヒリ語、ウルドゥー語のデータだけでなく、その並べ替えも正しく処理します。

SQL Server 7.0 における大きな変更点の 1 つに、オペレーティング システムに依存しない文字列比較モデルの採用があります。これによって、Windows 95 から Windows 2000 まで、すべてのオペレーティング システムで一貫した照合順序を使用できるようになりました。この文字列比較コードは、Windows 2000 が独自の文字列正規化で使用しているコードに基づいており、すべてのコンピュータおよび SQL Server のすべてのバージョンで同じになるようにカプセル化されています。

SQL Server 2000 の照合順序

SQL Server 2000 では、2 種類の照合順序 (Windows 照合順序および SQL Server 照合順序) の不整合を解消するために、照合順序モデルが変更されました。新しい照合順序要件のすべてに対応するには、より柔軟なモデルが必要でした。また、非 Unicode 列のコード ページに対応するためにも、SQL Server 2000 では新しい照合順序が必要でした。

これらのニーズに応えるため、Unicode と非 Unicode 両方の並べ替えが処理されるように一貫した統合モデルが設計されました。各照合順序は、大文字/小文字、アクセント、全角/半角、ひらがな/カタカナの区別を定義するためのサフィックスと組み合わせて使用します。「付録 A」にはサフィックスの一覧表があります。SQL Server 2000 でサポートされている 40 種類の言語と 17 のサフィックスを適宜組み合わせることで、合計 680 種類の Windows 照合順序を使用できるようになります。

照合順序に使用されている言語名は、非 Unicode データで使用する一意の各コード ページ、およびすべてのデータを対象とした並べ替え順に合わせて任意に付けたものです。多くの場合、複数の言語を 1 つのコード ページで完全に表したり、他の言語で使用される並べ替え順と同じもので処理したりできます。そのような重複する言語は表から削除されています。

SQL Server 2005 の照合順序

SQL Server 2005 は、Microsoft Windows オペレーティング システムがサポートしているすべての言語をサポートします。したがって、SQL Server 2005 には、新しい照合順序および Windows Server 2003 と Windows XP から更新された照合順序のサポートが追加されています。

    注 **:   **これらの照合順序は、SQL Server 2005 のセットアップの一部としてインストールされます。セットアップ時に、サーバーおよびデータベースの照合順序の選択を制御します。オペレーティング システムを更新しても、SQL Server で使用される照合順序には影響しません。

新しく追加された照合順序で重要な部分は、補助文字をサポートする東アジア言語の照合順序です。コード ポイントに基づいた、補助文字の文字列比較のサポートも追加されました。また、バイナリ フラグ (BIN2) が導入され、完全なコード ポイント比較が可能になりました。

バイナリ照合順序では、各文字のビット パターンに基づいて SQL Server 内のデータが並べ替えおよび比較されます。SQL Server における各バイナリ照合順序は、特定の言語ロケールおよび ANSI コード ページと対応付けられ、大文字小文字およびアクセントを区別するデータの並べ替えを実行します。バイナリ照合順序は、データの並べ替えが最も高速に行われます。

バイナリ オプション (_BIN) は、各文字に定義されているビット パターンに基づいて、SQL Server テーブル内のデータの並べ替えおよび比較を行います。バイナリ並べ替え順では、大文字と小文字が区別され、アクセントが区別されます。また、バイナリは最速の並べ替え順です。このオプションが選択されていない場合は、SQL Server によって、関連する言語または文字の辞書で定義されている並べ替えおよび比較規則が使用されます。

バイナリコード ポイント (_BIN2) オプションは、Unicode データの Unicode コード ポイントに基づいて、SQL Server テーブル内のデータの並べ替えおよび比較を行います。非 Unicode データの場合、バイナリコード ポイントではバイナリ並べ替えと同一の比較が使用されます。バイナリコード ポイントの並べ替え順を使用すれば、一度並べ替えた SQL Server データをアプリケーションで比較する際、それらのデータを再度並べ替える必要がありません。したがって、アプリケーション開発が容易になり、パフォーマンスも向上します。

「付録 E」には、SQL Server 2005 で更新された照合順序の一覧があります。SQL Server 2000 以前のバージョンとの互換性を維持する必要がなければ、更新された照合順序を使用することをお勧めします。

SQL Server 2005 の照合順序には、Windows 照合順序および SQL 照合順序が含まれます。

Windows 照合順序

Windows 照合順序では、関連する Windows ロケールに基づいて文字データを格納するための規則を定義します (Windows ロケールは SQL Server の Windows 照合順序よりも多数あります)。基本の Windows 照合順序規則は、非 Unicode 文字データの格納に使用されるコード ページだけでなく、辞書順の並べ替えが適用される場合にどの文字または言語が使用されるのかを指定します。SQL Server の Windows 照合順序には、大文字小文字、アクセント、かな、および全角半角を区別する並べ替えおよび比較の規則を詳細に定義するためのサフィックスが付けられています。完全な Windows 照合順序名は、照合順序指定子と比較形式で構成されます。

Windows 照合順序では、非 Unicode データの比較および並べ替えが、Unicode データと同じアルゴリズムを使用して実装されます。これによって、SQL Server 内のデータ型全般にわたる一貫性が保証されると同時に、開発者は、SQL Server で使用されるのと同じ規則を使用して、つまり、Microsoft Win32 API の CompareStringW 関数を呼び出して自分のアプリケーション内で文字列を並べ替えることが可能になります。

バイナリ照合順序

バイナリ照合順序では、ロケールおよびデータ型によって定義されるコード値のシーケンスに基づいてデータを並べ替えます。SQL Server のバイナリ照合順序は、使用する言語ロケールおよび ANSI コード ページを定義し、バイナリ並べ替え順が適用されます。バイナリ照合順序は比較的単純なので、アプリケーションのパフォーマンス向上に役立ちます。非 Unicode データ型の場合、データの比較は ANSI コード ページで定義されているコード ポイントに基づきます。Unicode データ型の場合、データの比較は Unicode コード ポイントに基づきます。Unicode データ型のバイナリ照合順序の場合、ロケールはデータの並べ替えで考慮されません。たとえば、Unicode データに対して Latin_1_General_BIN と Japanese_BIN2 を使用した場合、並べ替え結果はどちらも同じになります。これは、照合順序では Unicode が Unicode として比較され、非 Unicode データがバイナリとして比較されるためです。

SQL Server 2000 のバイナリ照合順序では、Unicode データに対して不完全なコード ポイント間比較を行っていました。最初の文字が WCHAR として比較された後、続いてバイト単位の比較が行われていました。旧バージョンとの互換性を維持するため、既存のバイナリ照合順序セマンティクスは変更されません。

SQL Server 2005 のバイナリ照合順序には、以前の BIN 照合順序、および新しい純粋なコード ポイント比較照合順序セットの両方が含まれています。この新しいバイナリ照合順序へ移行すると、完全なコード ポイント比較を利用でき、新しいアプリケーションの開発時にこの新しいバイナリ照合順序を活用できるようになります。新しいコード ポイント照合順序セマンティクスを実装する照合順序名は、新しい BIN2 サフィックスによって識別されます。さらに、BIN2 に対応する新しい比較フラグが新規バイナリ並べ替え用に追加されます。

SQL Server では、システム ロケールに基づいた既定の照合順序が自動的に推奨されます。Windows の既定の照合順序の設定を変更するのは、インストールした SQL Server を SQL Server の別のインスタンスで使用されている照合順序設定に合わせる必要がある場合、または照合順序設定を別のコンピュータの Windows システム ロケールに合わせる必要がある場合だけです。

補助文字を処理する必要がある場合は、既定の照合順序を、補助文字に対する並べ替え操作と比較操作をサポートしているいずれかの新しい照合順序に変更します。これらの比較は、コード ポイントのみに基づいており、他の言語的に有意な方法には基づいていません。これらの操作をサポートしているのは、照合順序名に 90 というサフィックスが付いた 90 照合順序バージョンのみです。たとえば、Japanese 照合順序の代わりに、Japanese_90 を使用します。補助文字対応照合順序を使用しない場合、ORDER BY、GROUP BY、および DISTINCT などの操作で補助文字を使用する際には注意してください。補助文字と補助文字以外の文字が同じ操作で使用されるときには、特に注意が必要です。

SQL Server 照合順序

SQL Server 照合順序では、以前のバージョンの SQL Server と互換性のある並べ替え順が使用されます (すべての SQL Server 照合順序の一覧については、SQL Server Books Online の「SQL 照合順序名」を参照してください)。SQL Server で定義される非 Unicode データ (char データ型、varchar データ型など) の場合、SQL Server 照合順序では、従来の SQL Server 並べ替え順に基づいて並べ替えが行われます。非 Unicode データについては、辞書順での並べ替え規則は Windows オペレーティング システムによって提供されるどの並べ替えルーチンとも互換性はありませんが、Unicode データの並べ替えは、特定のバージョンの Windows 並べ替え規則と互換性があります。SQL Server 照合順序では非 Unicode データと Unicode データで別々の比較規則を使用するため、基本となるデータ型によっては、同一データの比較で異なる結果が得られる場合があります。

SQL Server のインスタンスをアップグレードするときに、SQL Server の既存インスタンスとの互換性のために SQL Server 照合順序を指定することができます。SQL Server のインスタンスの既定照合順序がセットアップ時に定義されるため、次のような場合は、照合順序の設定を注意深く指定することが重要です。

• アプリケーション コードが以前の SQL Server 照合順序の動作になんらかの方法で依存している場合。

• SQL Server 6.5 または SQL Server 7.0 の既存のインストールで SQL Server 2005 レプリケーション機能を使用する予定がある場合。

• 複数の言語に対応する文字データを格納する必要がある場合。

データベースに Unicode の列と Unicode 以外の列が混在している場合は、できる限り Windows 照合順序を使用してください。Windows 照合順序を使用すると、Unicode のデータと Unicode 以外のデータの両方に Unicode ベースの並べ替え規則が適用されます。つまり、SQL Server 内部では Unicode 以外のデータを Unicode に変換して比較操作が実行されます。このしくみによって SQL Server のデータ型に一貫性が生まれ、開発者が SQL Server と同一の規則を使用して文字列を並べ替えるアプリケーションを開発できるようになります。

一方、SQL 照合順序は Unicode 以外のデータには Unicode 以外の並べ替え規則を適用し、Unicode データには対応する Windows 照合順序を使用して Unicode の並べ替え規則を適用します。この違いによって、同一文字の比較でも結果の一貫性が失われる場合があります。したがって、データベースに Unicode の列と Unicode 以外の列が混在している場合は、どちらのデータにも同一の並べ替え規則を適用するために、すべての列を Windows 照合順序を使用して定義してください。

照合順序における旧バージョンとの互換性

SQL Server 2000 の BIN バイナリ照合順序では、Unicode データに対して不完全なコード ポイント間比較が行われていました。これらのバイナリ照合順序では、最初の文字が WCHAR として比較された後、続いてバイト単位の比較が行われていました。これにより、Unicode 文字データが予期しない方法で並べ替えられる場合がありました。

旧バージョンとの互換性を維持するため、既存のバイナリ照合順序セマンティクスは変更されません。ただし、機能には新しい照合順序が使用されている可能性があります。SQL Server 2000 または SQL Server 7.0 との互換性のために保持されている照合順序は、付録に記載されています。

データベースの照合順序に関する情報を取得するには、次のシステム ビューを使用できます。

SELECT * FROM ::fn_helpcollations()
SQL Server 2005 では、このクエリが 1,011 の照合順序を返します (SQL Server 2000 では 753 の照合順序を返します)。

SELECT CONVERT(char, SERVERPROPERTY('collation'))

SELECT CONVERT(char, DATABASEPROPERTYEX('pubs', 'collation'))

Service Pack や今後のバージョンに追加されない限り、照合順序の追加はできません。

照合順序とデータの並べ替え

一般的なルールとして、Unicode の列に定義されている SQL Server の各照合順序は、定義されているすべての Unicode 文字を並べ替えます。ただし、データの並べ替えにはさまざまな方法があるため、照合順序も多岐にわたります。その好例がグルジア語 (モダン) の並べ替えです。グルジア語 (トラディショナル) のテキストはすべての文字が特定の順序で並べ替えられますが、通常、グルジア語 (モダン) では、まれにしか使用されない文字は最後に配置されます。これらの文字は、HE ( )、HEI ( )、WE ( )、および HAR ( ) です。したがって、グルジア語アルファベットには、トラディショナルとモダンの 2 つの並べ替え方法があります。

図 4 グルジア語 ( トラディショナル ) の並べ替え順

図 5 グルジア語 ( モダン ) の並べ替え順

この照合順序が存在していても、他の Unicode データは Latin1_General の照合順序の並べ替え順に基づいて並べ替えられます。実際には、Georgian_Modern_Sort 照合順序だけが例外で、他のすべての照合順序はグルジア語をトラディショナル形式で並べ替えます。つまり、すべての照合順序に同じ一般ルールが適用され、照合順序間で例外が変化するだけです。

照合順序のレベル

SQL Server 2005 は、SQL Server 2005 インスタンスの次のレベルで照合順序の設定をサポートしています。

• サーバー レベル

• データベース レベル

• 列レベル

• 式レベル

ここでは、これらの照合順序のレベルと、複数の照合順序が使用された場合の相互作用について説明します。

サーバー レベルに指定された照合順序

SQL Server インスタンスの既定の照合順序はセットアップ時に設定されます。インスタンスの既定の照合順序は、システム データベースの既定の照合順序にもなります。列またはデータベース以外のオブジェクトに照合順序を指定した場合、オブジェクトを削除してから再び作成する以外の方法で照合順序を変更することはできません。SQL Server インスタンスの既定の照合順序を変更する代わりに、新規データベースまたはデータベース列の作成時に照合順序を指定することができます。

以前のバージョンでは、照合順序は常にサーバー レベルに設定され、多くの場合、設定が必要な唯一の照合順序でした。サーバーに新規データベースを作成する場合にデータベース レベルの照合順序を明示的に設定しない限り、サーバー照合順序が既定の照合順序になります。ただし、各データベースは独自の照合順序があるため、サーバー レベルの照合順序が参照されるのは、データベースが最初に作成されるときだけです。

SQL Server 2000 では、Program Files\Microsoft SQL Server\80\Tools\BINN ディレクトリに格納されている Master 再構築ユーティリティ (RebuildM.exe) を使用すると、セットアップを再実行しなくてもサーバーの既定の照合順序を変更できました。詳細については、SQL Server 2000 Books Online の「master データベースを再構築する方法 (Master 再構築ユーティリティ)」を参照してください。SQL Server 2005 では、このユーティリティはサポートされません。代わりに Setup.exe の REBUILDDATABASE オプションを使用します。ただし、サーバー照合順序は頻繁に使用されるわけではないため、SQL Server 2005 のインスタンスの既定の照合順序を変更する代わりに、新しく作成するデータベースごとに既定の照合順序を指定することができます。

SQL Server 2005 のインスタンスの既定の照合順序を変更する必要がある場合は、データベースをスクリプト化またはバックアップし、すべてのユーザー データベースを削除してから、次のようにセットアップ コマンドの SQLCOLLATION プロパティで新しい照合順序を指定して、master データベースを再構築します。

start /wait setup.exe /qb INSTANCENAME=MSSQLSERVER
 REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=test 
 SQLCOLLATION=SQL_Latin1_General_CP1_CI_AI

データベース レベルの照合順序

データベースの作成時には、CREATE DATABASE ステートメントの COLLATE 句を使用して、データベースの既定照合順序を指定することができます。データベースの作成時に照合順序を指定しない場合、そのデータベースには、model データベースの既定の照合順序が設定されます。model データベースの既定の照合順序は、SQL Server インスタンスの既定の照合順序と同じです。

データベース レベルに設定されている並べ替え順によって、データベースごとに一意の照合順序を設定できます。次の図は、SQL Server Management Studio を使用した照合順序の設定方法を示しています。

図 6 [ データベースのプロパティ ] ウィンドウの [ オプション ] タブを使用したデータベース照合順序の設定

Transact-SQL を使用して照合順序を設定することもできます。たとえば、チェコ語の並べ替え順を使用し、大文字と小文字、およびアクセントを区別する新しいデータベースを作成するには、次のようなステートメントを使用します。

USE master
 GO
 CREATE DATABASE Products
 ON
 ( NAME = products_dat,
 FILENAME = 'c:\program files\microsoft sql server\mssql\data\products.mdf' ) 
COLLATE Czech_CS_AS
 GO

SQL Server 2005 では、SQL Server Management Studio を使用して既存のデータベースの照合順序を変更することもできます。SQL Server 2000 の SQL Server Enterprise Manager では、この機能は使用できませんでした。代わりに、ALTER DATABASE ステートメントを使用する必要がありました。たとえば、次のステートメントは、Products データベースの照合順序を、Czech_CS_AS (大文字と小文字、およびアクセントを区別する) から Czech_CI_AI (大文字と小文字、およびアクセントを区別しない) に変更します。

ALTER DATABASE Products
COLLATE Czech_CI_AI

データベースの照合順序を変更する際の注意点

データが text、varchar、または char フィールドに入力されており、その列に明示的な照合順序が設定されていない場合、データベースの照合順序を変更すると、データのエンコードの解釈方法が変更され、ASCII 範囲以外のすべての文字が破損します。

このため、データベースに非 Unicode テキスト データが含まれている場合、そのデータが明示的な照合順序セットが設定されている列に格納されていない限り、データベースの照合順序を変更しないようにします。

データベースの照合順序を変更するには、次のすべての条件を満たしている必要があります。

• データベースを使用できる状態のユーザーが他にいない。

• データベースの照合順序に依存するスキーマ バインド オブジェクトがない。スキーマ バインド オブジェクトには次のものがあります。

  • SCHEMABINDING を指定して作成されたユーザー定義関数およびビュー

  • 計算列

  • CHECK 制約

  • 既定のデータベース照合順序から継承した照合順序を持つ文字型列がテーブルにある場合に、そのテーブルを返すテーブル値関数

• データベースの照合順序の変更によって、システム名に重複が発生しない。重複が見つかった場合、エラーが発生し、照合順序の変更操作が失敗します。

• 重複が発生する可能性のあるオブジェクトは次のとおりです。

  • オブジェクト名 (プロシージャ、テーブル、トリガ、ビューなど)

  • スキーマ名 (グループ、ロール、ユーザーなど)

  • スカラ データ型の名前 (システム型、ユーザー定義型など)

  • フルテキスト カタログ名

  • オブジェクト内の列名またはパラメータ名

  • テーブル内のインデックス名

たとえば、データベースに Table1 と TABLE1 という名前の 2 つのテーブルが含まれていて、照合順序を French_CS_AS (大文字と小文字、アクセントを区別する) から French_CI_AS (大文字と小文字を区別しない、アクセントを区別する) に変更するとします。最初の照合順序では、2 つのテーブルが存在していても問題ありません。しかし、2 番目の照合順序に変更すると重複が発生します。

列レベルに指定された照合順序

SQL Server 2005 では、特定の列のテキストの照合順序を指定できます。たとえば、パスワード列で大文字と小文字を区別する必要がある場合にこの機能が役立ちます。列レベルの照合順序は、同じテーブル内に複数の言語を含む場合にも役立ちます。たとえば、ギリシャ語を使用する場合、顧客名の列はさまざまな名前に応じて並べ替えができるように、Unicode で Latin1_General 照合順序を使用する必要があります。一方、製品名の列はギリシャ語なので、この列にはギリシャ語の照合順序を使用します。次の図は、テーブル設計時に照合順序を選択し、並べ替え順オプションを設定する方法を示しています。

図 7

照合順序の指定列に対して事前に照合順序を設定していない場合、列をクリックすると、その列の Collation プロパティの <database default> がダイアログ ボックスに表示されます。照合順序を変更するには、参照ボタン ([...]) をクリックします。[照合順序] ダイアログ ボックスが開きます。ここで Windows 照合順序または SQL Server 照合順序のいずれかを選択し、並べ替えオプションを設定します。

Windows 照合順序を選択した場合、大文字と小文字、アクセント、ひらがなとカタカナ、および全角と半角を区別するかどうかを指定できます。

Transact-SQL を使用して列レベルの照合順序を設定することもできます。それには CREATE TABLE ステートメントの列定義に COLLATE 句を追加します。

次の例は、Transact-SQL を使用して、ジョブの説明の列に Arabic 照合順序 (大文字と小文字を区別しない、アクセントを区別しない、ひらがなとカタカナを区別しない) を指定する方法を示しています。

CREATE TABLE jobs
 ( 
job_id smallint
 IDENTITY(1,1)
 PRIMARY KEY CLUSTERED,
 job_desc varchar(50)
 COLLATE Arabic_CI_AI_KS
 NOT NULL
 DEFAULT '新しい位置 - タイトルは設定されていません',
 ) 

ALTER TABLE ステートメントを使用して、照合順序を列レベル (ntext 列または text 列を除く) で変更することもできます。COLLATE 句を指定しないで列のデータ型を変更すると、列の照合順序がデータベースの既定値とは異なってしまう場合があります。

SQL Server 2005 では、SQL 管理オブジェクト (SMO) の column.collation プロパティを使用して、照合順序をプログラムによって変更することもできます。

COLLATE 句を使用して照合順序を変更できるのは、char 型、varchar 型、nchar 型、および nvarchar 型の列だけです。ユーザー定義の別名データ型列の照合順序を変更するには、別の ALTER TABLE ステートメントを実行して列を SQL Server システム データ型に変更し、その照合順序を変更した後、その列を別名データ型に戻します。

次の条件の 1 つ以上に該当する場合、ALTER COLUMN で照合順序を変更することはできません。

• CHECK 制約、FOREIGN KEY 制約、またはその列を参照する計算列が変更された場合。

• 列にインデックス、統計、またはフルテキスト インデックスが作成された場合。変更する列に対して自動的に作成された統計は、列の照合順序を変更すると削除されます。

• スキーマ バインド ビューまたは関数で列が参照されている場合。

データベースの既定の照合順序のコード ページと異なる照合順序が設定された text 列では、値の挿入と更新が可能です。SQL Server により、値がこの列の照合順序に暗黙的に変換されます。

式内で指定された照合順序

式レベルの照合順序は、ステートメントの実行時に設定され、結果セットが返される方法に影響を及ぼします。この照合順序では、ORDER BY 句が言語固有のものとなるような結果の並べ替えが可能になっています。

SQL Server をセットアップする際、Windows 照合順序かバイナリ照合順序のいずれかを選択するよう求められます。照合順序の選択は、Microsoft SQL Server インスタンスにおけるデータ比較や並べ替え順の動作に影響します。

さまざまな国のユーザーに、その地域に適した並べ替えでデータを表示しなければならないことはよくあります。SQL Server 2000 および SQL Server 2005 のどちらでも、式の中で照合順序を指定できます。この優れた機能を使用すると、言語固有の ORDER BY 句を指定して、特定の方法で並べ替えがでます。

たとえば、AdventureWorks データベースを対象とした次のクエリは、Person.Address テーブルを住所の中の市区町村で並べ替えます。文字 "Y" の並べ替えのルールが特殊で、照合順序の違いを示す好例であるため、並べ替え順にリトアニア語を使用しています。

SELECT *
 FROM Person.Address
 ORDER BY City COLLATE Lithuanian_CI_AI 

次の例は、Table1 に列レベルの照合順序が明示的に設定されていないことを前提としています。この場合、両方の列はトルコ語の並べ替え順を使用して比較されます。

SELECT *
FROM Table1
WHERE Field1 = Field2 COLLATE Turkish_ci_ai

比較で照合順序が使用される方法の詳細については、後述の「照合順序の優先順位のルール」を参照してください。

COLLATE キーワード

照合順序は、データベース レベル、列レベル、または式内で定義できます。データベース、列、または文字式の照合順序を指定するには、次の構文を使用します。

COLLATE [<Windows_Collation_name>|<SQL_Collation_Name>]

列が Unicode データ型 (ntext、nvarchar、nvarchar(max)、nchar) を使用して定義されていない場合、照合順序はコード ページに変換されます。

COLLATE キーワードには、次の 2 種類の照合順序を使用するためのオプションがあります。

Windows 照合順序
Windows で定義されています。大文字と小文字、アクセント、ひらがなとカタカナ、および全角と半角を区別するかどうかを指定するオプションを変更できます。また、バイナリ並べ替え順も選択できます。

SQL 照合順序
この照合順序は、旧バージョンとの互換性を維持するために用意されています。並べ替え順は設定できません。

通常は、できるだけ Windows 照合順序を使用するようにしてください。次の例は、国のコードと名前の一覧で、照合順序によって並べ替え動作がどのように変化するかを示しています。クエリ ウィンドウの上部の一覧は、既定の照合順序によって並べ替えられています。下部は、同じデータがリトアニア語の照合順序によって並べ替えられています。

最初に示されている既定の照合順序では、Y が X と Z の間にあります。2 番目に示されているリトアニア語の照合順序では、Y が I と J の間にあります。

図 8 並べ替えに対するリトアニア語の照合順序の影響

照合順序の優先順位のルール

照合順序は、サーバー レベル、データベース レベル、列レベル、および式内で指定できます。そのため、照合順序がどのように作用するか理解することが重要です。照合順序の優先順位は、文字列として評価される式の照合順序の方法、および LIKE や IN など、入力に文字列を使用するが文字列を返さない演算子によって使用される照合順序を決定します。

SQL Server 2005 の照合順序の優先順位のルールは、char、varchar、text、nchar、nvarchar、および ntext の各文字列データ型に対してのみ適用されます。他のデータ型のオブジェクトは、照合順序の評価の対象にはなりません。

比較演算子、および MAX、MIN、BETWEEN、LIKE、IN の各演算子は、照合順序依存です。これらの演算子で使用される文字列には、優先順位の高い方のオペランドの照合順序ラベルが割り当てられます。また、UNION 演算子も照合順序依存で、すべての文字列オペランドおよび最終結果には、最高の優先順位を持つオペランドの照合順序が割り当てられます。UNION オペランドと結果の照合順序の優先順位は、列ごとに評価されます。

代入演算子は照合順序非依存で、右側の式が左側の照合順序にキャストされます。

文字列連結演算子は照合順序非依存です。2 つの文字列オペランドとその結果には、最高の優先順位を持つオペランドの照合順序ラベルが割り当てられます。UNION ALL および CASE 演算子は照合順序非依存で、すべての文字列オペランドとその最終結果には、最高の優先順位を持つオペランドの照合順序ラベルが割り当てられます。UNION ALL オペランドと結果の照合順序の優先順位は、列ごとに評価されます。

オブジェクトにはさまざまなレベルで異なる照合順序を指定できます。そのため SQL Server 2005 では、照合順序の複雑な作用の管理に役立つ "照合順序ラベル" を導入しています。照合順序を使用するオブジェクトのカテゴリを照合順序ラベルと呼びます。照合順序のルールは、照合順序ラベル間の関係という観点で表現されます。

文字列オブジェクトを 1 つだけ参照する式の場合、参照先オブジェクトの照合順序ラベルが使用されます。同じ照合順序ラベルを持つ 2 つのオペランド式を参照する式の場合、オペランド式の照合順序ラベルが使用されます。

異なる照合順序を持つ 2 つのオペランド式を参照する複雑な式の場合、最終的な結果の照合順序ラベルは、照合順序の優先順位の一連のルールを使用して決定されます。詳細については、SQL Server Books Online の「照合順序の優先順位 (Transact-SQL)」を参照してください。

照合順序ラベルの種類は次のとおりです。一覧の後の表に、相互作用する可能性がある照合順序ラベルをまとめています。

明示的
特定の式に対して明示的に定義される、つまり式の中で COLLATE 句を使用して特定の照合順序 (X) に明示的にキャストされる照合順序です。

暗黙
列参照です。CREATE TABLE または CREATE VIEW ステートメントの COLLATE 句を使用して列に明示的に照合順序を割り当てても、その列参照は "暗黙" として分類されます。

強制可能な既定照合順序
データベース レベルの照合順序が、任意の Transact-SQL 文字列変数、パラメータ、リテラル、カタログの組み込み関数の出力、または入力に文字列を使用しないが文字列を出力する組み込み関数の出力に対して使用されます。

このオブジェクトが、ユーザー定義関数、ストアド プロシージャ、またはトリガ内で宣言されている場合、そのオブジェクトには、関数、ストアド プロシージャ、またはトリガが作成されているデータベースの既定の照合順序が割り当てられます。オブジェクトがバッチ内で宣言されている場合は、その接続に対する現在のデータベースの既定の照合順序が割り当てられます。

照合順序なし
式の値が、2 つの文字列の照合順序ラベルが "暗黙" で、それぞれの照合順序が競合する場合のその文字列間の操作の結果である場合、式の結果は照合順序なしとして定義されます。

この表では、SQL Server が式を処理できないのは、2 種類の競合する照合順序を明示的に定義した場合と、比較する 2 つの項目に共通点がない場合だけであることを示しています。

たとえば、次の Transact-SQL ステートメントを使用してテーブルを作成します。

CREATE TABLE TestTab (
 id int,
 GreekCol nvarchar(10) COLLATE greek_ci_as,
 LatinCol nvarchar(10) COLLATE latin1_general_cs_as
 ) 
INSERT TestTab VALUES (1, N'A', N'a')
 GO

このステートメントは、ギリシャ語の照合順序 (大文字と小文字を区別しない、アクセントを区別する) を使用する列と、汎用ラテン 1 の照合順序 (大文字と小文字を区別する、アクセントを区別する) を使用する列を含むテーブルを作成します。

この 2 つを明示的に比較するクエリを使用したとします。

SELECT *
 FROM TestTab
 WHERE GreekCol = LatinCol

ただし、クエリは次のエラーを返します。

メッセージ 468、レベル 16、状態 9、行 1
 等しい操作の "Latin1_General_CS_AS" と "Greek_CI_AS" 間での照合順序の競合を解決できません。

このエラーは、テキストの 2 つのセグメントに異なる照合順序が設定されており、サーバーがそれらを比較できないため発生します。ただし、次の例に示すように、COLLATE キーワードを明示的に使用して互換性のある式を作成すると、クエリは動作します。

SELECT *
 FROM TestTab
 WHERE GreekCol = LatinCol COLLATE greek_ci_as

通常 LatinCol の照合順序では大文字と小文字が区別されますが、この式では大文字と小文字を区別しない照合順序が優先されているので、大文字の "A" と小文字の "a" は同じものと見なされます。

関数が照合順序依存かどうかは、入力のデータ型に依存します。CAST、CONVERT、および COLLATE の各関数は、char 型、varchar 型、および text 型に関して照合順序依存です。CAST 関数および CONVERT 関数の入出力が文字列である場合、出力文字列は、入力文字列の照合順序ラベルを持ちます。入力が文字列ではない場合、出力文字列は強制可能な既定照合順序となります。この場合、その接続の現在のデータベースの照合順序、あるいは CAST または CONVERT を参照しているユーザー定義関数、ストアド プロシージャ、またはトリガを含むデータベースの照合順序が割り当てられます。

入力が文字列ではなく文字列を返す組み込み関数の場合、その結果文字列は強制可能な既定照合順序となり、現在のデータベースの照合順序、あるいはその関数を参照しているユーザー定義関数、ストアド プロシージャ、またはトリガを含むデータベースの照合順序が割り当てられます。

COLLATE キーワードの制限事項

COLLATE キーワードとその関連機能は優れており、各国のデータベース開発者は非常に柔軟に使用できますが、いくつかの制限事項があります。ここでは、これらの制限事項とそれぞれの解決方法を示します。

返される照合順序の一覧について

fn_helpcollations 関数は、SQL Server で提供されるすべての照合順序の一覧を返します。例外的な照合順序が 3 つあります。それらは非推奨で、::fn_helpcollations() では返されません。SQL Server 2005 では Windows 2000 Beta 2 の並べ替えテーブルが使用されるため、ヒンディー語の照合順序は、このリリースの SQL Server では非推奨となります。この照合順序はまだサーバー内に存在しますが、今後の SQL Server のリリースではサポートからはずされる予定です。ヒンディー語および Lithuanian_Classic の照合順序は、SQL Server 2005 では非推奨となります。これらの照合順序はまだサーバー内に存在しますが、今後の SQL Server のリリースではサポートからはずされる予定です。

照合順序をプログラムで操作する場合、この機能向けのユーザー インターフェイスはユーザー自身が用意する必要があります。

暗黙的な変換

照合順序間の非 Unicode 文字データの暗黙的な変換は非決定的です。照合順序間の非 Unicode 文字データの暗黙的な変換についても、互換性レベルを 80 以下に設定しない限り、非決定的であると判断されます。

以前のバージョンの SQL Server では、システム オブジェクト名とシステム型名が、master データベースの照合順序と照合されていました。SQL Server 2005 では、システム オブジェクト名とシステム型名が現在のデータベースの照合順序に自動的にキャストされます。これらのオブジェクトへの参照がカタログの表示と異なり、現在のデータベースの照合順序によって不一致が発生すると、スクリプトやアプリケーションが失敗する可能性があります。たとえば、現在のデータベースが大文字と小文字を区別する照合順序の場合、ステートメント EXEC SP_heLP は失敗します。

列レベルの照合順序の定義に関する問題

データベースと個々の列に異なる並べ替え順 (たとえば Latin1_General と Greek) が必要な場合があります。また、データベースに多言語データが含まれており、複数の照合順序に基づいて並べ替える必要があると、単一の照合順序を定義できません。どちらの場合も、それぞれにインデックス付きの複数の照合順序を定義すれば、正しい照合順序を指定することにより、対象の言語のデータにアクセスできます。たとえば、ギリシャ語の照合順序を指定することによって、ギリシャ語のデータを容易に表示できます。

さらに、別の照合順序を指定することにより、このデータに対してクエリをインデックス付き検索として使用できます。検索向けに列にインデックスを付ける機能は、重要な要件です。前の段落の例では、クエリの ORDER BY 句で COLLATE 式を使用することにより、データの並べ替えに必要なこの機能を実行しました。ただし、これはインデックス付きの並べ替えではないので、大きなデータセットではクエリ結果が返されるまでに時間がかかります。このため、列レベルの照合順序が効果的なのは、列に格納されているのが単一言語データでない場合、または、異なる言語を複数の列に格納するためにデータベースを非正規化する場合だけです。

照合順序と tempdb

tempdb データベースは、SQL Server が起動されるたびに作成されます。tempdb には常に model データベースと同じ既定の照合順序が設定されます。通常、これは、インスタンスの既定の照合順序と同じになります。ユーザー データベースを作成して、model と異なる既定の照合順序を指定すると、そのユーザー データベースでは tempdb と異なる既定の照合順序が使用されます。一時ストアド プロシージャや一時テーブルは、すべて tempdb 内に作成および格納されます。その結果、一時テーブル内のすべての暗黙の列、および一時ストアド プロシージャ内で強制的に適用されるすべての既定の定数、変数、パラメータでは、パーマネント テーブルやストアド プロシージャで作成される同等のオブジェクトとは異なる照合順序が指定されます。

このため、ユーザー定義データベースとシステム データベース オブジェクトの照合順序の不一致による問題が発生する可能性があります。たとえば、SQL Server 2005 のインスタンスでは照合順序として Latin1_General_CS_AS が使用されていて、次のステートメントを実行するとします。

CREATE DATABASE TestDB COLLATE Estonian_CS_AS;
 USE TestDB;
 CREATE TABLE TestPermTable (PrimaryKey int PRIMARY KEY, Col1 nchar); 
 INSERT TestPermTable VALUES (1, 'a')

次に、以下のステートメントを使用して、TestPermTab と同じ列の宣言で一時テーブルを作成します。

CREATE TABLE #TestTempTable (PrimaryKey int PRIMARY KEY, Col1 nchar )
 INSERT #TestTempTable
 SELECT * FROM TestPermTable
 GO

このシステムでは、tempdb データベースに SQL_Latin1_General_CP1_CI_AS 照合順序 (コード ページ 1252) が使用され、TestDB と TestPermTable.Col1 に Estonian_CS_AS 照合順序 (コード ページ 1257) が使用されます。

次に、以下のステートメントを使用して、同じ行にクエリを実行します。

SELECT * FROM TestPermTable t1
 JOIN #TestTempTable t2
 ON t1.Col1 = t2.Col1

tempdb では既定のサーバーの照合順序が使用され、TestPermTable.Col1 では異なる照合順序が使用されるため、SQL Server は次のエラーを返します。

"メッセージ 468、レベル 16、状態 9、行 1
 等しい操作の "SQL_Latin1_General_CP1_CI_AS" と "Estonian_CS_AS" 間での照合順序の競合を解決できません。"

このエラーを回避するには、次のいずれかを行います。

• 一時テーブル列で、tempdb ではなく、ユーザー データベースの既定の照合順序を使用するように指定します。この措置によって、システムで必要とされる場合に、一時テーブルを複数のデータベース内で同様の形式が設定されたテーブルと併用できます。

• #TestTempTable 列に正しい照合順序を明示的に指定します。これは列の定義の COLLATE キーワードを使用して行うことができます。

LCID と照合順序

Windows はロケール ID (LCID) を使用して並べ替え順を定義します。LCID がわからない場合は、1024 を指定して既定の LCID を使用できます。または、Microsoft .NET の書式設定関数を使用してデータを書式設定できます。Web ベースの ASP アプリケーションで、Microsoft Visual Basic Scripting Edition (VBScript) の SetLocale 関数を使用して、日付/時刻、数字、および通貨の書式設定を任意のロケールに合わせて変更できます。ただし、LCID と照合順序の間に直接の対応はないので、LCID から正しい照合順序を判断することはできません。

これは、ユーザーにとって最適な並べ替え順をロケール ID に基づいて自動的に割り当てられるようにする場合に不便です。たとえば、さまざまな国のユーザーがアクセスして製品情報を参照する多言語の Web サイトでは、Session.LCID プロパティを使用して日付と通貨の値を書式設定するために、ユーザーのブラウザから提供される HTTP_ACCEPT_LANGUAGE 変数を LCID にマップします。ユーザーのロケールを使用して並べ替えを実行すれば、さらに使いやすくなります。

この問題に対処するには、独自のマッピング関数を構築します。これには、セットアップに用意されている照合順序指定子の一覧を使用できます。照合順序指定子により、特定の照合順序と標準の照合順序間のマッピングを行います。システム ロケールと推奨される既定の照合順序の一覧については、SQL Server Books Online の「セットアップでの照合順序の設定」を参照してください。

次にマッピングで使用する標準の照合順序の例をいくつか示します。

• 英語 (U.S.) 文字セット (コード ページ 1252) の場合は、[Latin1_General] を使用します。

• 英語 (U.S.) と同じ文字セット (コード ページ 1252) を使用するすべての種類のスペイン語では、[Modern_Spanish] を使用します。

• アラビア語文字セット (コード ページ 1256) を使用するすべての種類のアラビア語では、[Arabic] を使用します。

• Unicode 版の日本語では [Japanese_Unicode] を使用します。これは、[Japanese] とコード ページ (932) は同じですが、並べ替え順が異なります。

選択した照合順序指定子と共に使用する並べ替え順を指定することもできます。最も処理が速い並べ替え順序は [バイナリ] で、この並べ替え順序では大文字と小文字が区別されます。バイナリ並べ替え順を選択した場合、[大文字小文字を区別する]、[アクセントを区別する]、[かなを区別する]、[文字幅を区別する] の各オプションは使用できなくなります。

ISO 文字列と照合順序

VBScript では、次のスクリプトを使用して HTTP_ACCEPT_LANGUAGE 変数を取得できます。

Dim stLang
 stLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE")

多くの Web 開発者がロケール情報のためにこの変数を使用するので、VBScript の SetLocale 関数は、LCID 値に加えてこの値を直接受け取るように設計されています。つまり、この値を LCID にマッピングするための処理を実行する必要はありません。"en-us" (英語 - 米国) や "vi" (ベトナム語) などロケールを表す文字列ごとに、Latin1_General 照合順序やベトナム語照合順序など適切な照合順序にマッピングする必要があります。

カスタム照合順序

独自の照合順序を定義したいと考える開発者も多いでしょう。しかし、SQL Server の新しい照合順序はすべて Windows 照合順序から派生するため、新しい照合順序は作成できません。

さらに、照合順序は、Unicode 標準で定義されているすべての文字の並べ替えのメソッドを定義するために設計されているものなので、新しい照合順序を作成するためのユーザー インターフェイスはありません。

照合順序と補助文字

補助文字は、_90 照合順序のいずれかを使用する場合のみ、順序付けと比較ができます。これらの比較は、コード ポイントだけに基づいており、他の言語的に有意義な方法には基づいていません。ORDER BY、GROUP BY、および DISTINCT などの操作で補助文字を使用する場合は注意してください。補助文字と補助文字以外の文字が同じ操作で使用される場合には、特に注意が必要です。

補助文字は 2 つの 2 バイト Unicode 文字のペアとして格納されるため、LEN() 関数は、引数文字列に格納されている各補助文字に対して値 2 を返します。同様に、CHARINDEX 関数および PATINDEX 関数は、誤って文字列内に補助文字が含まれていると解釈します。また、NCHAR 関数は、補助文字のペアの一方だけを表す文字列を返します。binary 型の値または varbinary 型の値を補助文字に変換した場合も、補助文字のペアの一方だけが返されます。

LEFT、RIGHT、SUBSTRING、STUFF、および REVERSE の各関数では、補助文字のペアが分割され、予期しない結果が生じることがあります。

SQL Server 2005 では、CLR ユーザー定義関数を使用して補助文字を使用する場合、SQL Server システム関数の制限事項を無視できます。.NET Framework CLR のマネージ コードを使用して補助文字に対応した関数を作成および使用する方法の詳細については、SQL Server 2005 で提供されるサンプルを参照してください。一例として、「StringManipulate サンプル」では、補助文字に対応した文字処理を示します。また、LEN()、LEFT()、RIGHT()、SUBSTRING()、および REPLACE() 文字関数の実装を示します。この文字列関数では、Unicode 文字列および補助文字文字列の両方を処理することができます。サンプルには、SQL Server でアセンブリを読み込んで関数を作成するための C# または Visual Basic .NET のいずれかのスクリプト、および Transact-SQL スクリプトが含まれています。利用可能なサンプルの詳細については、SQL Server Books Online の「CLR 関数の作成」を参照してください。

サーバーとクライアント間の通信 (データ アクセス テクノロジ)

データベース アプリケーションでは、SQL Server Management Studio などの SQL Server ツールを使用するだけでは十分ではありません。通常、サーバーは 1 つ以上のデータ アクセス標準を使用して、他のサーバーやクライアントとやり取りします。この場合、SQL Server に接続するアプリケーションまたは層を "クライアント" と呼びます。ここでは、クライアントは次の 2 種類です。

• Unicode クライアント：SQL Native Client、OLE DB、ODBC Version 3.7 以降 (MDAC 2.8 以降)

• 非 Unicode クライアント：ODBC Version 3.7 以前、DB-Library (MDAC 2.xx)

ここでは、利用可能なデータ アクセス テクノロジについて説明します。また、クライアント サーバー環境で多言語データを使用する場合に発生し得る問題についても簡潔に説明します。

DB-Library

SQL Server 2005 データベース エンジンでは、DB-Library および Embedded SQL API を使用した既存アプリケーションからの接続が引き続きサポートされますが、これらの API を使用するアプリケーションでのプログラミング作業に必要なファイルやドキュメントは含まれません。SQL Server データベース エンジンの今後のバージョンでは、DB-Library アプリケーションや Embedded SQL アプリケーションからの接続はサポートされなくなります。また、Unicode 版の DB-Library はありません。

したがって、新しいアプリケーションの開発には DB-Library を使用しないでください。また、DB-Library への依存関係は、既存アプリケーションを変更するときに削除してください。これらの API の代わりに、SQLClient 名前空間または OLE DB や ODBC などの API を使用します。

SQL Server 2005 には、これらのアプリケーションの実行に必要な DB-Library DLL が含まれていません。DB-Library アプリケーションまたは Embedded SQL アプリケーションを実行するには、SQL Server version 6.5、SQL Server 7.0、または SQL Server 2000 から DB-Library DLL を入手する必要があります。

SQL-DMO

SQL 分散管理オブジェクト (SQL-DMO) は、SQL Server データベースとレプリケーション管理をカプセル化した COM 層です。SQL-DMO は COM 層なので、ADO や OLE DB と同じルールが適用されます。SQL-DMO には、SQLServer2、Database2、Column2、SystemDateType2、UserDefinedDataType2 の各オブジェクトの Collation プロパティなど、前述した機能に使用できるプロパティもあります。

OLE DB

OLE DB は、Microsoft Data Access Components (MDAC) の中心となるコンポーネントです。OLE DB は COM に基づいているため、すべての文字列は Unicode BSTR です (Windows XP、Windows Server 2003、および Windows 2000 では UTF-16、他のすべてのオペレーティング システムでは UCS-2)。ただし、MDAC 2.8 SP1 より前のバージョンの MDAC は、名前付きインスタンスをサポートしません。アプリケーションで SQL Server 2005 の名前付きインスタンスに接続できない場合があります。SQL Server 2005 の機能を利用するには、MDAC 2.8 SP1 にアップグレードします。

SQL Server の場合、プロバイダは Microsoft OLE DB Provider for SQL Server (SQLOLEDB) です。必要に応じて、実際のデータの照合順序を使用してデータが Unicode に変換されます。

ADO

Microsoft ActiveX® Data Objects は、OLE DB のラッパーとして機能する Visual Basic およびスクリプト対応のインターフェイスです。また、COM コンポーネントでもあるので、Unicode のサポート レベルは同じです。ADO と OLE DB を切り離して両者間でデータを変換できるようにする方法は存在しないため、問題がある場合は、OLE DB 層に問題があることになります。

ODBC

一部のバージョンの ODBC は Unicode をサポートします。非 Unicode データで重要な問題なのは、コード ページ間でデータを変換する方法、または ODBC の使用時に Unicode との間でデータを変換する方法です。ODBC 3.7 以前のバージョンを使用する場合、既定のシステム コード ページを使用して、データが Unicode から ANSI に変換されます。ODBC の最新バージョンをインストールした場合でも、Jet 3.5 は同じ変換を行います。

SQLSetConnectAttr へ送信する場合、SQL_COPT_SS_TRANSLATE 属性には、次の 2 つを設定できます。

• SQL_XL_OFF
  文字データをクライアントとサーバー間で交換する際に、ドライバは、あるコード ページから別のコード ページへ文字を変換しません。

• SQL_XL_ON
  文字データをクライアントとサーバー間で交換する際に、ドライバは、あるコード ページから別のコード ページへ文字を変換します。ドライバはサーバーにインストールされているコード ページとクライアントが使用しているコード ページを特定し、文字変換を自動的に構成します。

既定では、SQL_XL_ON 属性が使用されます。SQLServer オブジェクトの SQL-DMO TranslateChar メソッドを使用して、この属性を設定することもできます。通常、非 Unicode データを処理するときは、どのような場合でも、この既定値 (auto_translate を有効にする) が最適です。

auto-translate を無効にする場合、その結果を理解しておく必要があります。多くの場合、開発者は、この機能によりクライアントとサーバーはコード ページが一致しなくても通信できると想定して、自動変換を無効にします。ところが、このような通信はサポートされていません。さらに、Windows 照合順序で定義された非 Unicode データの並べ替えやスキャンを実行するために、SQL Server は並べ替えの実行前にデータを Unicode に変換します。したがって、自動変換が無効になっている場合、クライアント側で変換済みの Unicode データを取得して非 Unicode コード ページに戻すと、正しく変換されない可能性があります。

Microsoft SQL Native Client

Microsoft SQL Native Client (以前の SQL Native Client) は、OLE DB または ODBC を使用して SQL Server へのネイティブ データ アクセスを容易に実現できるように設計されました。OLE DB テクノロジと ODBC テクノロジを 1 つのライブラリにまとめることで、Microsoft Windows プラットフォームの一部になっている現在の MDAC コンポーネントを変更することなく、新しいデータ アクセス機能の導入や開発を可能にしています。

SQL Server 2005 の新機能を使用する必要がない場合は、SQL Native Client OLE DB プロバイダも使用する必要がありません。現在のデータ アクセス プロバイダ (通常は SQLOLEDB) を引き続き使用できます。既存のアプリケーションを拡張しており、SQL Server 2005 の新機能を使用する必要がある場合に、SQL Native Client OLE DB プロバイダを使用します。

SQL Native Client は MDAC のコンポーネントを使用しますが、MDAC の特定のバージョンに明示的に依存していません。

新しいアプリケーションで、Microsoft Visual C#® .NET や Visual Basic® .NET などのマネージ プログラミング言語を使用しており、SQL Server 2005 の新機能にアクセスする必要がある場合は、.NET Framework for Visual Studio® 2005 に含まれている .NET Framework SQL Server 用データ プロバイダを使用します。これは、SQL Server 2005 を使用するための最も堅牢なデータ アクセス コンポーネントです。

COM ベースのアプリケーションを開発しており、SQL Server 2005 の新機能にアクセスする必要がある場合は、SQL Native Client を使用します。SQL Native Client では、SQL Server 7.0 以降の旧バージョンの SQL Server データベースへのアクセスをサポートしています。

既存の OLE DB や ODBC アプリケーションの場合、主な問題は SQL Server 2005 の新機能にアクセスする必要があるかどうかです。アプリケーションが既に完成していて、SQL Server 2005 の新機能を使用する必要がない場合は、引き続き MDAC を使用できます。ただし、varchar(max)、nvarchar(max)、varbinary(max)、xml、UDT の各データ型、またはその他のラージ オブジェクト型の戻り値を、SQL Server 2005 より前のバージョンのクライアントに返すことはできません。これらの型を戻り値として使用するには、SQL Native Client を使用する必要があります。

MDAC と SQL Native Client は両方とも SQL Server データベースへのネイティブ データ アクセスを提供しますが、SQL Native Client は旧バージョンとの互換性を維持しながら、SQL Server 2005 の新機能を公開することを目的として設計されています。また、MDAC には OLE DB、ODBC、および ActiveX Data Objects (ADO) を使用するためのコンポーネントが含まれていますが、SQL Native Client に実装されているのは OLE DB と ODBC だけです。

SQL Native Client と MDAC の違いの詳細については、SQL Server Books Online の「MDAC から SQL Native Client へのアプリケーションの更新」を参照してください。

ActiveX Data Objects (ADO) を使用する既存のアプリケーションが SQL Server 2005 で導入された新機能を利用するには、データ アクセス プロバイダに SQL Native Client OLE DB プロバイダを使用する必要があります。

Unicode および非 Unicode のサーバーとクライアントの構成

ここでは、Unicode に完全には準拠していない従来のシステムを使用する場合に注意すべきいくつかの問題を示します。

Unicode サーバーと Unicode クライアント

これは理想的な構成です。プロセス全体を通じて Unicode でデータを保持すれば、最高のパフォーマンスが保証され、そのうえ取得したデータは破損しません。ADO と OLE DB、または SQL Server Native Client の場合も同様です。

Unicode サーバーと 1 つ以上の非 Unicode クライアント

この構成の場合、データの格納については問題ありませんが、データをクライアントに送信し、クライアントがそのデータを使用するときに大きな制限事項があります。任意の時点で、クライアントのコード ページを使用して Unicode データを変換する必要があります。

このシナリオの例として、DB-Library を使用しているコンピュータから SQL Server 2005 データベースへの接続があります。DB-Library は、C アプリケーションから SQL Server へのアクセスを可能にするインターフェイスです。DB-Library は、SQL Server 6.5 以降大幅なアップグレードは行われていません。したがって、SQL Server 6.5 と同じ制限事項があります。使用できるのは、1 つのコード ページ (システムの既定の OEM コード ページ) に基づいたデータだけです。クライアント システムのロケール設定に基づいたロケール情報を使用するかどうかも選択できます。SQL Server クライアント ネットワーク ユーティリティには、DB-Library の情報の変換方法を指定するための非排他的な 2 つのオプション、[ANSI から OEM への自動変換] と [国際対応の設定の使用] が用意されています。既定では、両方のオプションが選択されています。

他のコード ページのデータは処理できないため、DB-Library をデータ層で使用すべきなのは、SQL Server のデータのサブセットを処理する従来のシステムだけです。このテクノロジは旧バージョンとの互換性のためだけに提供されていますが、レガシ アプリケーションで多言語データをサポートする必要がある場合に使用できます。

Unicode に対応していない他のクライアントとして、以前のバージョンの Microsoft Access があります。以前のバージョンの Microsoft Access を使用して SQL Server データベースに接続する場合、次の図に示すように、Unicode は疑問符に変換されます。

図 9 疑問符で示された日本語のテーブル名

ODBC 3.7 の既定の動作は、システム コード ページへの自動的な変換でした。しかし、英語 (US) クライアント コンピュータのコード ページ (1252) には日本語の文字がないため、日本語は疑問符に置き換えられます。

さらに、これらのテーブルには接続できません。接続しようとすると、エラー メッセージが表示されます。Jet および ODBC は "dbo.????" という名前のテーブルに接続しようとしますが、そのようなテーブルは存在しないため失敗します。このエラーは、クライアント システムのコード ページに含まれていないすべてのデータで発生します。

データが間違ったコード ページに変換され、疑問符に置き換えられると、元の状態に変換し直す方法はありません。たとえば、非 Unicode クライアントを使用して Unicode の韓国語データが含まれているテーブルに接続すると、次の図のように、韓国語のテキスト文字が疑問符に置き換えられます。

図 10 非 Unicode クライアント   データベースで表示できない文字の例

3 つのレガシ クライアント (DB-Library、ODBC、Jet 3.5) のすべてで Unicode を処理できません。処理できるのは、既定のシステム コード ページに変換できる文字だけです。データが既定のシステム コード ページに含まれていない限り、クライアント側の開発でこれらのコンポーネントを使用しないでください。詳細については、SQL Server Books Online の「Unicode を使用するサーバーと Unicode 以外を使用するクライアント間のデータ変換の管理」を参照してください。

また、Access 内の SQL Server データへのエントリ ポイントは COM が提供するため、データの意味の解釈にはクライアントの地域別設定が使用されます。これは、日付/時刻値、数値、および通貨の値の入力に影響を与えます。この問題の詳細については、後述の「COM のロケール競合の処理」を参照してください。

Microsoft Access を SQL Server へのフロント エンドとして使用する場合、Access フロント エンドをアップグレードして、Microsoft Office 2003 Access または Microsoft Office System 2007 Access でサポートされる新機能と Unicode を使用することをお勧めします。Access のオンライン ヘルプで、既存の Microsoft Access アプリケーションのアップグレード方法のガイダンスが説明されています。Microsoft Access 2000 以降、ADP 形式は廃止されました。

パフォーマンスや更新可能性を向上するために Microsoft Access アプリケーションを最適化する方法の詳細については、「SQL Server にリンクする Microsoft Access アプリケーションの最適化」のホワイト ペーパーを参照してください。

非 Unicode サーバーと Unicode クライアント

多言語データをサーバー上に格納できないため、多言語データの場合は理想的な構成ではありません。SQL Server 2000 および SQL Server 2005 は両方とも Unicode 対応なので、リンク サーバーが SQL Server 6.5 データベースに定義されていない限り、この構成が発生することはありません。SQL Server 6.5 のインスタンスから受け取るデータは有効ですが、サーバーの既定のコード ページに含まれていないデータは挿入されません。

以前のバージョンの SQL Server の多言語データの変換

SQL Server に Unicode の完全サポートが実装される前に作成されたレガシ アプリケーションの一部は、ユーザー定義のエンコード体系を使用して多言語データを処理しています。データを保持するには、変換エラーを回避するために、一括コピー プログラム (bcp ユーティリティ) を使用してデータをバイナリで保存します。次に、コマンド ライン パラメータ -C を使用して適切なコード ページを指定し、一括コピーを使用して再度インポートします。bcp ユーティリティの詳細については、後述の「コマンド ライン ユーティリティを使用した多言語データの操作」を参照してください。

ユーザー インターフェイスの多言語データ

SQL Server の多くの管理ツールが更新され、多言語データのサポートが強化されました。ここでは、SQL Server 2005 のいくつかの変更点について説明します。

全般的な UI の変更

SQL Server の新しいインターフェイスは、柔軟性に富み、さまざまなテキスト エディタやクエリ エディタ、管理ダイアログ ボックス、ウィザード、デザイナ、およびブラウザを同じシェルでホストします。シェル内では、セッション言語を指定し、次の要素の表示をコントロールできます。

• エラーと他のシステム メッセージで使用される言語

• 日付と時刻のデータの形式

• 略記を含む、曜日と月の名前

• 週の最初の曜日

• 通貨記号と通貨書式

SQL Server Management Studio で使用されるフォントを変更するには、[ツール] メニューで [オプション] を選択し、[環境] をポイントします。その後 [フォントおよび色] を選択して、SQL Server Management Studio で出力ペインを持つ個々のツール ウィンドウ向けに、フォント スタイル、フォント サイズ、および色の表示設定をカスタマイズします。テキストを変更しても、変更内容は変更のセッション中には適用されません。ただし、変更の結果は、SQL Server Management Studio のインスタンスをもう 1 つ開くと確認できます。

セッション設定として 34 種類の言語を使用できます。言語の一覧については、SQL Server Books Online の「sys.syslanguages (Transact-SQL)」を参照してください。

Business Intelligence Development Studio を使用して、Integration Services パッケージまたは Analysis Services の多次元オブジェクトおよびデータ マイニング オブジェクトで使用するための、テキストおよび表示オプションを変更することもできます。[オプション] ダイアログ ボックスの [環境] ページを使用して、ユーザー インターフェイスやオンライン ヘルプの環境で使用される言語、フォント、およびキーボード マッピング スキームを含むオプションを構成できます。ユーザーの好みに合わせて開発環境を構成すると、構成内容が *.suo ファイルとしてソリューション フォルダに保存されます。これは再利用できます。

注 **:   **補助文字を表示するには、補助文字拡張をサポートするフォントをインストールする必要があります。詳細については、MSDN ライブラリの「代理文字と補助文字」を参照してください。

フルテキスト インデックス操作やフルテキスト クエリ操作で使用できる言語の一覧を表示するには、sys.fulltext_languages を使用します。言語ごとに 1 行のデータを格納するカタログ ビューです。各行には、Microsoft SQL Server に登録されている使用可能なフルテキスト言語リソースが明確に示されています。これらの名前または LCID は、フルテキスト クエリおよびフルテキスト インデックスの DDL で指定できます。

• セッション言語をサーバー側から設定するには、SET LANGUAGE を使用します。

• セッション言語は、OLE DB、ODBC または ADO.NET を使用して、クライアント側で設定できます。

• OLE DB の場合は、SSPROP_INIT_CURRENTLANGUAGE プロパティを使用します。

• ODBC の場合は、LANGUAGE キーワードを使用します。詳細については、「SQLConfigDataSource」を参照してください。

• ADO.NET の場合は、ConnectionString オブジェクトの Current Language パラメータを使用します。

複雑な文字表記のサポート

SQL Server 2005 は、データベース エンジンとツールの全体にわたって、複雑な文字表記の入力、格納、変更、および表示をサポートします。複雑な文字表記には、アラビア語などの双方向の文字表記、インド諸語、タイ語など位置によって文字が変形する文字表記、およびタイ語など単語間に区切りがないため、単語を識別するための内部辞書を必要とする言語が含まれます。

SQL Server を操作するデータベース アプリケーションは、複雑な文字表記をサポートするコントロールを使用する必要があります。マネージ コードで作成される標準の Windows フォーム コントロールは、複雑な文字表記を使用できます。ただし、複雑な文字表記のサポートに必要なファイルは、地域と言語の設定をとおして、使用するコンピュータにインストールする必要があります。詳細については、SQL Server Books Online の「複雑な文字表記のサポート」を参照してください。

クエリ デザイナの書式

ほとんどの場合、クエリ デザイナでは、グリッド ペインに入力する情報にはコンピュータの既定の地域別設定を適用できます。または、CONVERT 関数を明示的に使用して、文字列を任意の書式で処理できます。

地域別設定を使用する場合、次の設計上の制限事項があります。

• 長いデータ形式はサポートされていません。

• グリッド ペインには通貨記号を入力しないでください。ただし、U.S. ドル記号 ($) は必要に応じて使用できます。いずれの場合も、結果ペインでは、地域別設定から取得された通貨記号が使用されます。

• 地域別設定に関係なく、単項のマイナスはかっこで囲まれず常に左側に表示されます。したがって、[地域と言語のオプション] ダイアログ ボックスで 1- や (1) のように指定しても、-1 は -1 と表示されます。

これらの制限事項は、クエリ デザイナで世界中の言語をサポートするために必要なもので、ロケール固有のデータの使用を妨げるものではありません。

グリッド ペインに入力されたすべての情報は、SQL ペインでロケールに依存しない形式に変換されます。そのため、標準のドイツ語のコンピュータで「03.09.65」と入力すると、{ ts ' 1965-09-03 00:00:00 } と変換されます。SQL ペインにデータを直接入力する場合は、この形式を使用する必要があります。または CONVERT を明示的に呼び出します。

並べ替え順

結果ペインに表示されるデータの並べ替えは、地域別設定の影響を受けません。代わりに、照合順序ルールにより ORDER BY 句が解釈されます。

多言語の Transact-SQL

多言語データが含まれている SQL ステートメントをサーバーに送信する場合、データがサーバーに正しく送信されるかどうかは、(1) SQL ステートメント自体のエンコード、(2) ステートメント内の文字列リテラルのエンコードの 2 つが影響します。

SQL ステートメントのエンコード

Transact-SQL ステートメントで使用できる文字には制限があります。リテラル、データベース オブジェクト名、別名、パラメータ名、パラメータ マーカー文字には、DBCS 文字を入力できます。ただし、関数名や SQL キーワードなどの SQL 言語要素に DBCS 文字を使用することはできません。したがって、SELECT などの SQL キーワードを入力する場合は、日本語の全角文字の "ＳＥＬＥＣＴ" ではなく、半角文字の "SELECT" を使用する必要があります。

SQL 文字列で Unicode を使用している場合 (ADO を使用する SQL 文字列など)、すべての種類の文字をエンコードできます。文字列が Unicode を使用していない場合 (非 Unicode バッチ ファイルや .sql ファイルの文字列など)、任意の時点で変換する必要があります。この変換を行う場合、慎重に計画する必要があります。また、多言語アプリケーションの問題を回避するために、変換を実行するコンピュータの既定のシステム コード ページについて考慮する必要があります。

SQL ステートメント内の文字列リテラルのエンコード

ストアド プロシージャ内やトリガ内など、サーバーで実行されるコード中の Unicode 文字列定数には、定数の前に大文字の N を付ける必要があります。文字列リテラルが Unicode (N プレフィックス付き) でない場合、文字列はデータベースの既定のコード ページに変換されます。このとき、特定の文字は認識されないことがあります。多言語データでは、Unicode データ型と Unicode 文字列リテラルを使用することを推奨します。

次に、文字列の先頭に "n" プレフィックスを付けて Unicode 文字列として指定した例を示します。

SELECT n'??????'

次の図は、ヒンディー語のフォントが正しくインストールされたコンピュータでこの文字列 (ヒンディー語のヒンディー文字) がどのように表示されるかを示しています。

図 11 ヒンディー語クライアントでのヒンディー文字の例

文字列の前に "n" プレフィックスが付いていないと、?????? に変換されます。データがシステムの既定のコード ページに一致しない場合も、同じように変換されます。

    警告 **:   **文字列リテラルおよびデータ型 (nchar、nvarchar、ntext) に "n" プレフィックスを使用して Unicode データを表すのは、SQL Server だけです。ANSI-92 SQL 仕様では National 文字データ型が定義されますが、これらは Unicode として指定されません。ANSI-99 SQL 仕様では、"u" プレフィックス (utext、uchar、uvarchar など) を使用して Unicode 型のセットを表します。これらのデータ型は、SQL Server では使用できません。

文字列の先頭に N プレフィックスを使用すると、文字列は確実に Unicode として渡されます。これにより、サーバーの既定のシステム コード ページを使用する場合に、変換に関する意図しない問題を回避できます。

アプリケーションが SQL Server に Unicode データを送信せず、クライアントの ANSI コード ページが SQL Server のコード ページと一致する場合は、文字列定数の前に N を付ける必要はありません。このプレフィックスを省略しても、データを損失することはありません。

SQL Server 7.0 を使用してリンク サーバーを使用している場合は、注意すべき別の問題があります。SQL Server 7.0 では、インストール時に並べ替え順とは別に Unicode 照合順序を選択できます。場合によっては、このことによって、N が前に付けられた文字列に対する操作と、プレフィックスを持たない操作の結果が異なる場合があります。この問題の詳細については、Microsoft サポート オンライン サイトを参照してください。

文字列操作関数

Transact-SQL には、多言語の使用時に注意が必要な文字列操作関数が組み込まれています。

ASCII
現在の既定のシステム コード ページを使用して、文字列の最初の文字のコード ポイントを返します。コード ページに文字が含まれていない場合は、63 (疑問符のコード ポイント) を返します。この関数は、Visual Basic および VBScript の Asc() 関数と同じです。

CHAR
指定された ANSI コード ポイントの文字を返します。基本的に ASCII 関数とは逆の操作です。この関数は、Visual Basic および VBScript の Chr() 関数と同じです。コード ポイントが 0 ～ 255 の範囲にない場合、NULL を返します。

NCHAR
指定された Unicode コード ポイントの文字を返します。これは Unicode を使用する CHAR 関数です。この関数は、Visual Basic および VBScript の ChrW() 関数と同じです。

UNICODE
文字式の最初の文字の Unicode コード ポイントを返します。これは Unicode を使用する ASCII 関数です。この関数は、Visual Basic および VBScript の AscW() 関数と同じです。

前の例 (「日付/時刻型 : datetime、smalldatetime」を参照) では、NCHAR 関数を使用してヒジュラ暦の先頭に RLM (右から左マーク) が追加されています。RML マークを追加することにより、日付が想定どおりに書式設定されます。

SQL Server 2005 でのロケールのサポート

SQL Server 2000 では 33 種類の言語について特定のロケールがサポートされていました。SQL Server 2005 では、Microsoft Windows オペレーティング システムでサポートされているすべての言語についてサポートが追加されました。「付録 B」には、サポートされているすべての言語の一覧と、各言語のロケール ID が記載されています。

sp_helplanguage ストアド プロシージャを使用すると、これらの言語とその詳細を列挙できます。SQL Server のすべてのバージョンでは、次に示した項目の多くに関する情報が収録されますが、ローカライズ版をインストールしない限り、すべてのロケールについて翻訳されたシステム メッセージは表示されません。

言語に関する情報は syslanguages テーブルに格納されています。ただし、メッセージは sysmessages に格納されています。

言語の設定

SQL Server では、すべてのインスタンスにおいて、日付形式やメッセージなどの項目の処理に使用される既定の言語を設定する必要があります。この情報は、作成されるサーバーへのログインごとに格納されます。サーバーに対する既定の言語の定義は、最初はセットアップ時に行いますが、次の図に示す [SQL Server のプロパティ] ダイアログ ボックスの [詳細設定] タブで、サーバー レベルで変更できます (SQL Server 2000 では、このオプションは [サーバーの設定] タブにあります)。

図 12 サーバーに対する既定の言語の設定

sp_configure ストアド プロシージャを使用して既定の言語を変更することもできます。たとえば、次のステートメントは言語をイタリア語に変更します。

sp_configure "language", 6

sp_addlogin ストアド プロシージャを使用するか、図 13 の [ログインのプロパティ] ダイアログ ボックスを使用すると、既定の言語の設定をログイン単位で変更できます。

図 13 ログインに対する既定の言語の設定

次の例のように SET LANGUAGE ステートメントを使用すると、既定の言語をセッション レベルで変更できます。

SET LANGUAGE French
 SET LANGUAGE čeština
 SET LANGUAGE 한국어
 SET LANGUAGE N'日本語

文字列の操作

SET LANGUAGE 呼び出しによる方法以外に、個々のデータにアクセスして言語の設定を独自に指定する方法もあります。

• ADO では、ConnectionString でプロバイダ固有の言語キーワードがサポートされています。

• OLE DB では、プロバイダ固有の SSPROP_INIT_CURRENTLANGUAGE プロパティを設定できます。

• ODBC では、データ ソース定義で、または接続文字列の LANGUAGE キーワードで、言語を指定できます。

• DB-Library では、dblogin を使用して LOGINREC を割り当てた後、DBSETNATLANG を使用して言語の設定を指定できます。

次の項目が言語の設定の影響を受けます。言語の設定は、サーバー レベル、ログイン レベル、またはセッション レベルで指定されます。

• メッセージ

• 日付/時刻

• 週の最初の曜日

• 通貨単位と通貨記号

• 月名、日名、および短い月名

メッセージ

SQL Server 2000 および SQL Server 2005 では、言語固有のシステム エラー文字列およびメッセージのコピーを複数取得できます。これらのメッセージは、master データベースの sysmessages テーブルに格納されています。ローカライズ版の SQL Server をインストールすると、これらのシステム メッセージが対象の言語バージョン用のものに翻訳されます。既定では、これらのメッセージの英語 (U.S.) セットも取得されます。サーバー セッションの言語を指定するには、Set Language を使用します。既定では、メッセージはインストールされているバージョンの言語を使用して送られます。

SQL Server からメッセージが接続に送られるとき、その言語 ID セットが sysmessages テーブルの msglangid 列にある言語 ID の 1 つに一致する場合は、ローカライズされたメッセージが使用されます。これらの ID は 10 進形式で、メッセージのロケール ID (LCID) を表します。同じ LCID を持つメッセージが sysmessages テーブル内に存在しない場合は、英語 (U.S.) のメッセージが送られます。

sp_addmessage システム ストアド プロシージャの @lang パラメータを使用すると、ユーザーが定義した言語固有のメッセージを sysmessages テーブルに追加できます。エラー番号は 50,000 よりも大きくする必要があり、@lang パラメータを言語として指定するか、または LCID にマップされるメッセージの名前付き別名を指定する必要があります。言語固有のシステム エラー文字列およびメッセージはサーバーに複数インストールできます。そのため、"language" の値には、メッセージが sysmessages テーブルに書き込まれる際の言語を指定します。"language" を指定しない場合は、サーバー セッションの既定の言語が表示言語になります。サポートされている言語定義は master.dbo.syslanguages に格納されています。

sysmessages の複数の言語バージョンをインストールする必要がある場合、追加の手順や必要条件については、Microsoft サポート オンライン サイトを参照してください。異なる言語バージョンの SQL Server インスタンスを、同じコンピュータにインストールすることはサポートされていません。たとえば、ドイツ語の SQL Server 2005 とポルトガル語 (ブラジル) の SQL Server 2005 を、同じコンピュータで複数のインスタンスとして使用することはできません。

    注 **:   **以前にリリースされた SQL Server のシステム テーブルの多くは、SQL Server 2005 ではビューのセットとして実装されています。これらのビューは "互換性ビュー" と呼ばれ、旧バージョンとの互換性のためだけに用意されています。互換性ビューでは、SQL Server 2000 で利用できるメタデータと同じメタデータを利用できますが、SQL Server 2005 で導入された機能に関連するメタデータは利用できません。

日付/時刻

言語にはそれぞれ、短い日付形式に対する適切な既定値 (mdy、dmy、または ymd) があります。SET DATEFORMAT の設定を使用すると、この既定値を接続レベルで変更できます。短い日付の既定値を取得するには、sp_helplanguage ストアド プロシージャを使用します。この値は dateformat 列に格納されています。

週の最初の曜日

週の最初の曜日はロケールごとに異なります。syslanguages テーブルにある 33 種類の言語では、1 (月曜日) ～ 7 (日曜日) まであります。この情報は sp_helplanguage ストアド プロシージャを使用して取得できます。この値は datefirst 列に格納されています。

通貨単位と通貨記号

money 型または smallmoney 型の列にはすべて、通貨記号を含めることができます。記号は必ずしも [地域のオプション] ダイアログ ボックスで指定されているものである必要はなく、次の表に示す任意の文字を使用できます。

ユーロ記号 (16 進値 20AC) は、ユーロ通貨 (ECU) 記号 (16 進値 20A0) である 同じではありません。 を金額値に使用した場合は、エラーが発生します。

月名、日名、および短い月名

月名および日名は syslanguages テーブルに格納されています。これらは sp_helplanguage ストアド プロシージャを使用して取得でき、次の列を表示できます。

months
月名のコンマ区切りリスト。January (1 月) ～ December (12 月)。

shortmonths
短い月名のコンマ区切りリスト。January (1 月) ～ December (12 月)。

days
曜日のコンマ区切りリスト。Monday (月曜日) ～ Sunday (日曜日)。

COM のロケール競合の処理

SQL Server は日付/時刻や通貨の値を処理するうえで非常に強力な機能を備えていますが、ADO などの COM サービスを使用してサーバーにアクセスする場合は、そのサービスの操作を実行できるように許可を与える必要があります。

たとえば、前述の表に示した通貨記号が先頭に付いた数値を、Visual Basic で通貨値として認識できないことがあります。また、文字列に格納されている日付/時刻値を COM で正しく使用できないこともあります。

このような問題に対処するには、アプリケーションでいつ文字列を日付時刻値や通貨値に変換しているのかを理解しておく必要があります。まず、変換が行われるのがクライアントかサーバーかを判断し、次に、適用する規則を決めます。

たとえば、Access 2000 ADP は、日付、時刻、または通貨の値を変換するクライアントです。Access は OLE DB を通じて動作しているため、Access 2000 からの操作はすべて、クライアント コンピュータの地域の設定を使用する COM の規則によって制御されます。

Microsoft OLE DB Provider for SQL Server などの OLE DB プロバイダは、有効な COM 日付と SQL Server の日付との間で正しい変換を行います。可能であれば、文字列内の日付形式に依存しないようにするのが最善です。この種の機能は、クライアントのロケールが変更されると正しく機能しなくなります。

SQL Server 2005 Integration Services

SQL Server 2005 Integrations Services は SQL Server 2000 のデータ変換サービスに代わるものです。Integration Services では、多言語データのインポート、エクスポート、および変換の機能が大幅に強化されています。Integration Services は、多言語データの解析と操作をサポートし、すべての Windows ロケールをサポートしています。また、文字列データの並べ替えと比較のための特殊な比較オプションを備えています。

Integration Services パッケージでのロケールの設定

Integration Services は、パッケージ オブジェクト、コンテナ、タスク、およびデータ フロー コンポーネントのレベルでロケールをサポートしています。イベント ハンドラのロケールも設定でき、一部の変換元および変換先のロケールも設定できます。

1 つのパッケージで複数の異なるロケールを使用できます。たとえば、パッケージで英語 (米国) ロケールを使用している一方で、パッケージ内の 1 つのタスクでドイツ語 (ドイツ) ロケールを使用し、別のタスクで日本語 (日本) ロケールを使用できます。

Integration Services パッケージでは、任意の Windows ロケールを使用できます。ロケールはパッケージを作成するときに設定できます。ロケールのプロパティを更新する構成を使用していない限り、パッケージは、開発環境と異なる地域と言語のオプションが使用されているコンピュータに配置されたときでも同じ動作を行うことが保証されます。

ロケールの設定

Integration Services は、データを並べ替えたり、日付、時間、および 10 進数データを解釈するためのロケール固有のルールを推定する場合、コード ページを使用しません。その代わり、変換は、データ フロー コンポーネント、データ フロー タスク、コンテナ、またはパッケージ上の LocaleID プロパティによって設定されるロケールを読み取ります。

既定では、変換のロケールはデータ フロー タスクから継承され、データ フロー タスクはパッケージからロケールを継承します。データ フロー タスクが For ループ コンテナなどのコンテナ内にある場合は、コンテナからロケールを継承します。

また、フラット ファイル接続マネージャや、複数のフラット ファイル接続マネージャ用のロケールも指定できます。

オブジェクトのロケールやコード ページを変更するには、データ フロー オブジェクトまたは制御フロー オブジェクト用のエディタを使用します。パッケージ オブジェクトの場合は、LocaleID などのプロパティを [プロパティ] ウィンドウで設定する必要があります。

図 14 パッケージに対するロケールの指定

CodePage プロパティはパッケージ オブジェクトでは使用できません。これは、コード ページはパッケージ オブジェクトに対しては関係がなく、変換元、変換先、または変換に対してのみ関係があるためです。

フラット ファイル データの操作

フラット ファイル ソース データを操作する前に、フラット ファイル接続マネージャがフラット ファイル データをどのように解釈するのかを理解しておく必要があります。フラット ファイル ソースが Unicode の場合、すべての列が [DT_WSTR] として定義され、既定の列幅 50 が設定されます。フラット ファイル ソースが ANSI エンコードの場合は、列が [DT_STR] として定義され、列幅が 50 になります。これらの既定値を、使用中のデータに適した文字列型の列に変更する必要があります。これを行うには、データの書き込み先となる変換先のデータ型を調べます。次に、フラット ファイル接続マネージャで正しい型を選択します。

フラット ファイルからデータをインポートするときや、フラット ファイルにデータをエクスポートするときは、パッケージの特定のプロパティ、接続、およびデータ変換のタスクが、ロケールに基づいて自動的に設定されます。これらの設定は簡単に変更できます。また、ロケール設定の影響を受ける可能性のある情報がデータに含まれている場合に、変更が必要になることがあります。フラット ファイルの変換元や変換先について、ロケールを正しく変更しないと、意図しない結果を招く可能性があります。

たとえば、SQL Server 2005 と共にリリースされた Integration Services のチュートリアルには、フラット ファイルからデータをインポートするシナリオがあります。このファイルに含まれている BirthDate 列では、EN-US ロケールに対応した既定の日付形式の 1 つが使用されています。このチュートリアルを、異なる既定のロケールを使用しているコンピュータで実行した場合、日付データを解析できないために、データをインポートするパッケージの実行に失敗する可能性があります。この場合、パッケージ、データ フロー オブジェクト、および関連する変換元または変換先を編集して、それらすべてで正しいロケールが使用されるようにすることで、パッケージが動作するようになります。

図 15 フラット   ファイルに対するロケールとコード   ページの指定

テキスト データの解析

Integration Services は、フラット ファイルやその他の変換元からテキストを読み込むときに、あらかじめ定義された 1 組の解析ルーチン (高速解析または標準解析) に従ってテキストを解析します。

"高速解析" は、高速で単純な解析ルーチンのセットで、ロケール固有のデータ型の変換はサポートされません。最も頻繁に使用される日付と時間の形式のみがサポートされます。高速解析は、ロケール固有の解析の実行や、通貨データ内の特殊文字の認識は行いません。また、整数の 16 進数表記と科学的表記は変換できません。

"標準解析" は、解析ルーチンの大規模なセットで、Oleaut32.dll と Ole2dsip.dll で使用できるオートメーション データ型変換 API で提供される、すべてのデータ型の変換がサポートされています。

データ フローを作成するときは、変換出力列が、Microsoft SQL Server 2005 Integration Services (SSIS) で用意されているロケール非依存型の高速な解析ルーチンを使用するか、またはロケール依存型の標準的な解析ルーチンを使用するかを指定できます。

パッケージ内のデータ フローでロケール依存型の解析が必要な場合は、高速解析ではなく、標準的な解析を使用することをお勧めします。たとえば、高速解析では、コンマなど 10 進数の記号が含まれるロケール依存型のデータ、年 - 月 - 日形式以外の日付形式、および通貨記号は認識されません。

高速解析および標準解析でサポートされている各種のデータ形式については、SQL Server Books Online の「データの解析」を参照してください。

高速解析は、列レベルで指定されます。フラット ファイル ソースおよびデータ変換の変換では、出力列で高速解析を指定できます。入力と出力には、ロケール依存型の列およびロケール非依存型の列の、両方を含めることができます。ただし、高速解析を使用できるのは、フラット ファイル ソースまたはデータ変換の変換を使用する場合のみです。

比較オプション

ロケールは、データ フロー内の文字列データを比較するための基本的な規則を提供します。たとえば、ロケールは、アルファベットの各文字の並べ替え位置を指定します。ただし、目的の比較操作を行うのにこれらの規則では不十分な場合もあります。そこで、Integration Services では、ロケールの比較規則を超える高度な比較オプションのセットをサポートしています。たとえば、分音文字を無視することを選択した場合、比較目的では "a" と "á" は等価です。

文字列比較は、Integration Services によって実行される多くの変換において重要な部分です。また、文字列比較は、変数内の式やプロパティ式の評価でも使用されます。

例 :

• 条件分割変換は、式の内部で文字列比較を使用し、データ行を送信する出力を決定できます。

• 派生列変換は、式の内部で文字列比較を使用し、新しい列の値を生成できます。

• 並べ替え変換、集計変換、あいまいグループ化変換、およびあいまい参照変換をカスタマイズして、文字列の比較方法を列レベルで変更できます。参照で大文字と小文字を区別しないものの、アクセントのある文字とアクセントのない文字を区別して扱うように指定することもできます。

データおよび変換の構成によっては、文字列データの比較中に次の処理が発生する場合があります。

データの Unicode への変換。変換元のデータが Unicode でない場合、比較が行われる前に自動的に Unicode に変換されます。

• ロケールを使用した、日付、時間、10 進数データ、および並べ替え順序を解釈するための、ロケール固有のルールの適用。

• 比較の区別を変更するための、列レベルでの比較オプションの適用。

比較オプションの変更

Integration Services では、列レベルで設定できる高度な比較オプションのセットをサポートしています。たとえば、詳細比較オプションの 1 つを使用すると、分音文字を無視できます。このオプションをオンにした場合、文字列データの比較時にアクセントなどの分音文字が無視され、"a" と "á" が同一の文字と見なされます。

次の比較オプションを、並べ替え変換、集計変換、あいまいグループ化変換、およびあいまい参照変換で設定できます。

• 大文字と小文字を区別しない

• カタカナを区別しない

• 文字幅を区別しない

• 分音文字を無視する

• 記号を無視する

• 句読点を記号として並べ替え

あいまいグループ化変換とあいまい参照変換には、データを比較する際の FullySensitive オプションも含まれています。この比較フラグは詳細エディタでのみ使用できるもので、すべての比較オプションを適用することを示します。

データ ソースと変換先

多くの場合、Integration Services はデータ ソースから正しいコード ページを識別できます。Integration Services が予期しないコード ページを提供する場合、または、正しいコード ページを決定するための十分な情報を提供しないプロバイダを使用してパッケージがデータ ソースにアクセスする場合は、OLE DB ソースおよび OLE DB 変換先で既定のコード ページを指定できます。既定のコード ページは、Integration Services で提供されるコード ページの代わりに使用されます。

ファイルにはコード ページはありません。代わりに、パッケージがファイル データへの接続に使用するフラット ファイル接続マネージャおよび複数フラット ファイル接続マネージャに、ファイルのコード ページを指定するプロパティが含まれます。コード ページはファイル レベルでのみ設定できます。列レベルでは設定できません。

変換が実行する操作や変換の構成によっては、文字列データは、文字列の Unicode 表示である DT_WSTR データ型に変換される場合があります。

DT_STR データ型の文字列データは、列のコード ページを使用して Unicode に変換されます。Integration Services では、列レベルでのコード ページがサポートされており、各列はそれぞれ異なるコード ページを使用して変換できます。

文字列データから Unicode への明示的な変換

パッケージ内のデータ フローではデータの抽出と読み込みが行われます。データ フローからは異種データ ストアにアクセスできます。データ ストアでは、標準およびカスタムのさまざまなデータ型が使用されます。データ フローの内部では、"Integration Services の変換元" において、データの抽出、文字列データの解析、および Integration Services データ型へのデータ変換が行われます。次に続く変換で、データを解析して別のデータ型に変換したり、列のコピーを別のデータ型で作成することもあります。コンポーネントで使用する式で、引数やオペランドを別のデータ型にキャストする場合もあります。さらに、データがデータ ストアに読み込まれるとき、変換先でデータを解析して、変換先が使用するデータ型に変換する場合もあります。

データがパッケージ内のデータ フローに入ると、データを抽出する変換元によって、そのデータが Integration Services のデータ型に変換されます。数値データは数値データ型、文字列データは文字列データ型、および日付データは日付データ型に割り当てられます。GUID やバイナリ ラージ オブジェクト (BLOB) などの他のデータも、同様に適切な Integration Services のデータ型に割り当てられます。データのデータ型が Integration Services のデータ型に変換できない場合は、エラーが発生します。

データ フローにおけるデータ変換の詳細については、SQL Server Books Online の「Integration Services のデータ型」を参照してください。

"データ変換の変換" は、変換を制御するための機能を提供します。たとえば、コード ページを明示的に変更したり、形式を変更したり、入力列のデータを別のデータ型に変換したりできます。1 つの入力列に複数の変換を適用できます。変換されたデータで元のデータを置き換えたり、変換されたデータを新しい出力列にコピーしてダウンストリーム コンポーネントで使用したりできます。

たとえば、パッケージで複数の言語の変換元からデータを抽出し、この変換を使用して、列を変換先のデータ ストアで要求されるデータ型に変換できます。

データ変換の変換を使用すると、次の種類のデータ変換を実行できます。

• データ型の変更。

• 文字列データの列の長さ、および数値データの有効桁数と小数点以下桁数の設定。

• コード ページの指定。

もう 1 つのコンポーネントである文字マップ変換は、文字データに対して変換を実行するのに便利です。文字マップ変換は、小文字から大文字への変換関数などの文字列関数を、文字列データ型を持つデータに適用します。

文字マップ変換では、列データを適切に変換したり、変換出力に列を追加して、変換後のデータを新しい列に挿入できます。また、さまざまなマップ操作のセットを同じ入力列に適用し、その結果を別の列に格納できます。たとえば、同じ列を大文字と小文字に変換し、その結果を 2 つの異なる列に格納できます。

文字マップ変換では次のマップ操作がサポートされています。

変換では、複数の操作を実行できます。ただし、一部のマップ操作は相互に排他的です。ほとんどの場合、これらの排他性は常識的なものです。たとえば、ひらがなをカタカナにマップすると同時にカタカナをひらがなにマップすることはできません。相互に排他的なマップの詳細については、SQL Server Books Online の「文字マップ変換」を参照してください。

    注 **:   **状況によっては、マップによってデータが切り捨てられる場合があります。たとえば、1 バイト文字をマルチバイトで表記される文字にマップした場合、切り捨てが発生することがあります。データ変換を実行するときは、データ ビューアを使用してデータ内の変換を監視してください。また、エラー出力を使用して、切り捨てられたデータやエラー データを別の出力に送ってください。詳細については、SQL Server Books Online の「データのエラー処理」を参照してください。

SSIS での補助文字のサポート

Integration Services ではサロゲート ペアが透過的に扱われます。つまり、データ ソース、データの変換先、または変換によって文字列のサイズが変更されていない限り、サロゲート ペア文字は他のすべての Unicode 文字と同じように扱われます。文字列のサイズを返す関数や機能では、サロゲート ペア文字が 2 つの別々の未定義 Unicode 文字として扱われます。文字列関数 LEN および SUBSTRING では、この処理が行われます。

補助文字を表示するには、補助文字の拡張をサポートしているフォントを使用するように Business Intelligence Development Studio をカスタマイズする必要があります。ただし、SQL Server では補助文字がメタデータではなくデータとしてサポートされているだけなので、それらの文字の表示を必要とする場所はデータのプレビューやクエリの WHERE 句などに限定されます。

構成を使用したロケールの動的な変更

パッケージを異なるサーバーに配置するときに異なるロケールを使用する必要がある場合は、パッケージの実行時に使用する、更新されたロケールを提供する構成を作成できます。

構成は属性と値のペアで、これらを使用すると開発環境の外部からランタイムのプロパティと変数を設定できます。構成を開発に組み込むことによって、配置と配信の両方を簡単に実行できる柔軟なパッケージを作成できます。Integration Services では次の種類の構成を行えます。

• XML 構成ファイル

• 環境変数

• レジストリのエントリ

• 親パッケージの変数

• SQL Server テーブル

さらに柔軟性を高めるため、Integration Services では間接構成を使用することもできます。これは、環境変数を使用して構成の場所を指定し、それによって実際の値を指定する方法です。

XML 構成ファイルには、複数のプロパティの構成を含めることができ、特定の条件では複数のパッケージの構成も格納できます。

既に公開されているいくつかの新しい Integration Services チュートリアルでは、構成の作成とテストを行い、動的な構成を含む新しいパッケージを作成するための配置ユーティリティを作成するまでの手順を説明しています。これらのチュートリアルを実行し、コード ページや変換オプション、その他の国際化の設定を、構成を使用して動的に更新し、パッケージを配置するまでの手順を習得することをお勧めします。

簡単な ETL パッケージ作成のチュートリアル
「簡単な ETL パッケージ作成のチュートリアル」では、次のタスクについて手順ごとに説明しています。

• 簡単な Integration Services パッケージを作成してループを追加します。

• パッケージ構成ウィザードを導入し、XML 構成の形式を記述します。

• ループ処理を行うテキスト ファイルを格納したディレクトリを変更するパッケージ構成を作成します。

• 構成をテストします。これには、開発環境の外部から変数の値を修正し、修正したプロパティから新しいサンプル データ フォルダを参照するようにします。パッケージをもう一度実行すると、構成ファイルによってファイル ディレクトリが更新されます。

パッケージの配置のチュートリアル
「パッケージの配置のチュートリアル」は次のタスクを習得するのに役立ちます。

• XML 構成ファイルと間接構成を組み合わせて使用し、ログ ファイルの接続文字列、テキスト ファイル、および、パッケージが実行時に使用する XML ファイルと XSD ファイルの場所を更新します。

• パッケージのインストールに使用する配置バンドルを作成します。配置バンドルは、Integration Services プロジェクトに追加したパッケージ ファイルとその他の項目、Integration Services に自動的に含まれるパッケージの依存関係、および構築した配置ユーティリティから構成されます。

• パッケージ インストール ウィザードを実行し、パッケージとパッケージの依存関係をインストールします。パッケージが msdb SQL Server データベースにインストールされ、サポート ファイルがファイル システムにインストールされます。

• 新しい値が使用されるように構成を更新し、パッケージが新しい環境で正常に実行できるようにします。

コマンド ライン ユーティリティを使用した多言語データの操作

ここでは、SQL Server 2005 で提供されているコマンド ライン ユーティリティの一部について、その基本的な事柄を説明します。更新された bcp ユーティリティでは、多言語のシナリオで役立つ機能が提供されており、XML 形式のサポートが追加されています。sqlcmd はスクリプトを簡素化する新しいユーティリティで、スクリプト ファイルのコード ページを制御できます。

bcp

特定のコード ページに対してデータのインポートやエクスポートを行う場合、引き続き bcp ユーティリティを使用できます。bcp ユーティリティは、ユーザー指定の形式に基づいて、Microsoft SQL Server のインスタンスとデータ ファイルとの間でデータの一括コピーを行います。

SQL Server 2005 では、bcp によって新しいデータ検証とデータ チェックが実行されます。これにより、既存のスクリプトがデータ ファイル内にある無効なデータに対して実行された場合、このスクリプトは失敗する可能性があります。たとえば、bcp では新たに次の検証が行われます。

• float 型と real 型のネイティブ表記が有効かどうか。

• Unicode データが偶数バイト長かどうか。

  注:   以前のバージョンの SQL Server で一括インポート可能であった無効な形式のデータが、現在のバージョンでは読み込みに失敗する場合があります。以前のバージョンでは、クライアントが無効なデータにアクセスを試行するまで、エラーは発生しませんでした。検証機能が追加された理由は、データが読み込まれる前に検証を行うことで、一括読み込み後にデータのクエリが正しい結果にならないことを可能な限り回避するためです。

bcp ユーティリティではデータのロスレス変換に対応した次のフラグがサポートされています。

フォーマット ファイルを使用して照合順序を列レベルで指定することもできます。-C、-N、または -w を指定しない場合、bcp ではインポートやエクスポートを実行する前に、列ごとに照合順序とコード ページ情報を指定するよう求められます。次に、情報をフォーマット ファイルに保存するよう求められます。情報は次のように保存されます。

9.0
9
1   SQLCHAR   0   11   ""1   au_id   Latin1_General_CI_AI
2   SQLCHAR   0   40   ""   2   au_lname   Latin1_General_CI_AI
3   SQLCHAR   0   20   ""   3   au_fname   Latin1_General_CI_AI
4   SQLCHAR   0   12   ""   4   phone   Latin1_General_CI_AI
5   SQLCHAR   0   40   ""   5   address   Latin1_General_CI_AI
6   SQLCHAR   0   20   ""   6   city   Latin1_General_CI_AI
7   SQLCHAR   0   2   ""   7   state   Latin1_General_CI_AI
8   SQLCHAR   0   5   ""   8   zip   Latin1_General_CI_AI
9   SQLBIT   0   1   ""   9   contract   ""

フォーマット ファイルの詳細については、SQL Server Books Online の「XML 以外のフォーマット ファイルについて」を参照してください。

SQL Server 2005 では bcp 用の XML フォーマット ファイルが導入されています。XML フォーマット ファイルには、対応するテーブル列の説明が含まれている、対象の列のデータ型が含まれている、などの多くの利点があります。XML ファイルは読み取り、作成、および拡張が容易です。XML フォーマット ファイルを作成するには、bcp で –x オプションを使用します。

フォーマット ファイルを作成したら、bcp で –f オプションを使用してデータのインポートやエクスポートを行うことができます。

次の表に、bcp を使用してインポートやエクスポートを実行できるデータ型の一覧を示します。照合順序は列に対して指定されている既定の照合順序であり、データベースやサーバーから継承される場合があります。

varchar および nvarchar のデータ型はこの表には記載されていません。bcp ユーティリティでは、これらの代わりに char および nchar のデータ型をそれぞれ使用してください。

bcp では "地域別設定有効" のための -R フラグがサポートされています。このフラグは ODBC の [地域設定を使用する] オプションと同じ効果があります。このオプションは、テキスト以外のフィールドに格納されている日付/時刻、数値、および通貨のデータの解釈に影響を与える可能性があります。

sqlcmd

sqlcmd は SQL Server 2005 の新しいユーティリティで、従来 osql、isql、バッチ ファイル、および VBScript の組み合わせによって提供されていた機能を提供するものです。このユーティリティは OLE DB を使用して Transact-SQL バッチを実行します。

コマンド プロンプト ウィンドウからアドホック クエリを対話的に実行できます。または、Transact-SQL ステートメントやシステム プロシージャを含むスクリプトを実行できます。スクリプト ファイルを作成して実行できます。スクリプトは、コマンド プロンプト、SQLCMD モードのクエリ エディタ、Windows スクリプト ファイル、またはオペレーティング システム (Cmd.exe) の SQL Server エージェント ジョブのジョブ ステップで、それぞれ実行できます。

–f オプションを使用すると、入力コード ページと出力コード ページを指定できます。

コード ページ番号には、インストールされている Windows コード ページを示す数値を指定する必要があります。sqlcmd でコード ページを指定しない場合は、入力ファイルと出力ファイルの両方で現在のシステムのコード ページが使用されます。ただし、–u オプションを使用すると、入力ファイルの形式に関係なく、出力ファイルを Unicode 形式で格納するよう指定できます。

この構文の例を次に示します。スクリプト ファイル MyScript.sql には、

‘USE AdventureWorks; GO; SELECT * FROM Production.vProductAndDescription; ORDER BY CultureID;’

というクエリが含まれています。

1 番目の例は、クエリを実行して、出力を Unicode でファイルに保存します。2 番目の例は、同じクエリを実行しますが、出力ファイルを ID 950 のコード ページで保存します。コード ページが使用できない場合はエラーが発生する可能性があります。

sqlcmd -i C:\Temp\MyScript.sql -o C:\temp3\MyOutput1.txt -u
sqlcmd -i C:\ Temp\MyScript.sql -f1252 -o C:\temp3\MyOutput2.txt -f950

sqlcmd では、ビッグ エンディアンとリトル エンディアンの両方の Unicode 入力ファイルが自動的に認識されます。-u オプションを指定すると、出力は常にリトル エンディアン Unicode になります。

複数の入力ファイルは、同じコード ページが指定されていると想定されます。Unicode 入力ファイルと Unicode 以外の入力ファイルを混在させることができます。

SQL Server Management Studio (SSMS) のクエリ エディタを使用すると、sqlcmd のスクリプトの作成と編集が行えます。ただし、SSMS では実行の際に Microsoft .NET SqlClient が使用されますが、sqlcmd ではコマンド ラインからのスクリプトの実行時に OLE DB プロバイダが使用されます。したがって、同じクエリでも、SQL Server Management Studio で SQLCMD モードで実行した場合と、sqlcmd ユーティリティで実行した場合とで、動作が異なることがあります。

SQL Server Analysis Services のインターナショナル機能

Microsoft SQL Server 2005 Analysis Services では、Microsoft Windows オペレーティング システムでサポートされているすべての言語がサポートされています。Analysis Services では、Windows の言語識別子を使用して、Analysis Services のインスタンスおよびオブジェクト用に選択された言語を指定します。Windows の言語識別子は、Windows の第一言語の識別子と第二言語の識別子の組み合わせに対応しています。たとえば、セットアップ時に [英語 (米国)] を選択すると、対応する Windows の言語識別子である 0x0409 (または 1033) が Analysis Services インスタンスの構成設定ファイルの Language 要素で指定されます。

翻訳

Analysis Services インスタンスで使用される既定の言語および照合順序を指定することに加えて、Analysis Services オブジェクトに対応する翻訳を定義することによって、キューブ、メジャー グループ、ディメンション、階層、属性など、個々の Analysis Services オブジェクトに対して多言語サポートを提供することもできます。

Business Intelligence Development Studio を使用して、Analysis Services データベースのキャプション、説明、および勘定科目の種類の翻訳を定義できます。翻訳を使用すると、クライアント アプリケーションで Analysis Services オブジェクトを異なる言語および照合順序で受け取ることができます。

特定の言語識別子の翻訳が Analysis Services オブジェクトに指定されていない場合や、Analysis Services インスタンスへの接続時にクライアント アプリケーションによって言語識別子が指定されない場合は、Analysis Services インスタンスの既定の言語および照合順序の設定により、データおよびメタデータに使用される設定が指定されます。

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

クライアント アプリケーションが、指定された言語識別子内の情報を要求すると、Analysis Services インスタンスは、Analysis Services オブジェクトのデータおよびメタデータを、最も近い言語識別子に解決しようとします。クライアント アプリケーションで既定の言語が指定されていない場合、ニュートラルなロケール識別子 (0) が指定されている場合、または既定の言語識別子 (1024) が処理される場合、Analysis Services はインスタンスの既定の言語を使用して Analysis Services オブジェクトのデータおよびメタデータを返します。

クライアント アプリケーションで既定の言語識別子以外の言語識別子が指定されている場合、インスタンスはすべての使用可能なオブジェクトに対して、可能なすべての翻訳を反復処理します。指定された言語識別子が翻訳の言語識別子と一致した場合、Analysis Services はその翻訳を返します。一致する言語識別子が見つからない場合、Analysis Services は次のいずれかの方法を使用して、指定された言語識別子に最も近い言語識別子を持つ翻訳を返します。

次の言語識別子については、指定された言語識別子の翻訳が定義されていない場合、Analysis Services は代替言語識別子の使用を試みます。

他のすべての言語識別子の場合、Analysis Services は、指定された言語識別子の第一言語を抽出し、Windows によって指示された言語識別子を第一言語に最も近いものとして取得します。

最も近い言語識別子の翻訳が見つからない場合や、指定された言語識別子が第一言語に最も近い場合は、既定の言語が使用されます。

Analysis Services の照合順序

Analysis Services では、Windows の照合順序を使用して、Analysis Services のインスタンスおよびオブジェクト用に選択された照合順序を指定します。Analysis Services に対して Windows 照合順序を指定すると、Analysis Services インスタンスは、その照合順序に関連付けられた Windows ロケールが指定されているコンピュータ上で実行されるアプリケーションと同じコード ページおよび並べ替え規則と比較規則を使用します。たとえば、Analysis Services のフランス語 Windows 照合順序は、Windows のフランス語ロケールの照合順序と属性が一致します。

Analysis Services に定義されている Windows 照合順序よりも多くの Windows ロケールがあります。Windows ロケールの名前は、英語などの言語識別子と、米国やオーストラリアなどの第二言語識別子に基づいています。多くの言語の間では、アルファベットおよび文字の並べ替えと比較の規則が共通です。

たとえば、すべてのポルトガル語 Windows ロケールおよび英語 Windows ロケールを含む 33 個の Windows ロケールは、Latin1 コード ページ (1252) を使用し、共通の規則に従って文字の並べ替えと比較を行います。SQL Server Windows 照合順序 Latin1_General は、このコード ページと関連する並べ替え規則に基づいており、これら 33 個の Windows ロケールのすべてをサポートしています。また、Windows ロケールには、通貨、日付、時刻の形式など、Analysis Services Windows 照合順序が対象としていない属性が指定されます。オーストラリアと米国などの国と地域では、通貨、日付、時刻の形式が異なるため、国によって異なる Windows 照合順序が必要になります。ただし、オーストラリアと米国では、使用される文字とその並べ替え規則および比較規則が同じなので、異なる Analysis Services Windows 照合順序は必要とされません。

Analysis Services オブジェクトに対して複数の言語識別子を指定できますが、言語識別子にかかわらず、すべての Analysis Services オブジェクトに対して同じ Analysis Services Windows 照合順序が使用されます。ただし、この機能に対するただ 1 つの例外として、データベース ディメンション内の属性の CaptionColumn プロパティがあります。このプロパティには、指定した属性のメンバを照合するための Analysis Services Windows 照合順序を指定できます。

Analysis Services の並べ替え順オプション

すべてのユーザーが Analysis Services インスタンスに対して同じ言語を使用している場合は、インスタンスに対して指定された既定の言語をサポートする照合順序を選択します。複数の言語が使用されている場合は、さまざまな言語の必要条件に最も一致する照合順序を選択します。たとえば、インスタンスのユーザーが主に西ヨーロッパ言語を使用している場合は、Latin1_General の照合順序を選択します。

いくつかの並べ替え順オプションは、指定した Analysis Services Windows 照合順序に適用して、大文字と小文字、アクセント、かな、および文字幅の区別に基づいて並べ替えおよび比較の規則をさらに定義できます。並べ替え順オプションは SQL Server データベース エンジンの場合と同じであり、大文字と小文字の区別、文字幅の区別、アクセントの区別、およびかなの種類の区別を定義できます。

Analysis Services インスタンスの既定の言語として英語 (米国) の言語識別子 (0x0409 または 1033) を使用する場合は、EnableFast1033Locale 構成プロパティを設定することによって、パフォーマンスをさらに向上させることができます。これは、この言語識別子にのみ使用できる高度な構成プロパティです。このプロパティの値を true に設定すると、Analysis Services は文字列のハッシュおよび比較に高速アルゴリズムを使用できます。

    注 **:   **データ ウェアハウスを構成する階層データ構造の各部分に異なる照合順序を持たせる機能については、サポートされていません。データの分析では一般に便利というわけではありませんが、データをアルファベット順にパーティション分割するような事例では役立つ可能性があります。そうした事例では、順序とパーティションを明示的に定義し、文字順序を想定しないように、別の方法でデータをパーティション分割する必要があります。また、この機能は階層データの表示にも非常に役立つことになります。このような機能を必要とする場合は、OLAP ソースから返されるデータのサブセットを並べ替えます。

複数の通貨のサポート

Analysis Services では、複数の通貨を含むキューブで通貨換算がサポートされています。

キューブに通貨換算を定義するには、少なくとも 1 つの通貨ディメンション、少なくとも 1 つの時間ディメンション、および少なくとも 1 つのレート メジャー グループを定義する必要があります。ビジネス インテリジェンス ウィザードでは、レポートの通貨ディメンションと MDX スクリプトの作成に使用するデータとメタデータをこれらのオブジェクトから取得し、通貨換算機能を提供できます。

通貨換算を実装する前に、次の項目を定義する必要があります。

この後、ビジネス インテリジェンス ウィザードを使用して、ディメンション、属性、メジャー グループのデータおよびメタデータの組み合わせを使用する MDX スクリプトを生成し、通貨データを含むメジャーを換算できます。このウィザードを使用して通貨換算を作成する方法の詳細については、SQL Server Books Online の「通貨換算の処理 (SSAS)」を参照してください。

SSAS での日付と時刻の値の操作

月と曜日の比較および操作を実行する場合は、日付および時刻部分の文字列ではなく、日付および時刻の数値部分を使用します。日付および時刻部分の文字列は、インスタンスに指定されている言語識別子と、時刻ディメンションのメンバのインスタンスによって指定されている現在の翻訳によって部分的に決定されます。

時間ディメンションを操作する場合は、MDX の日付および時刻関数を利用します。また、Visual Basic for Applications (VBA) の日付および時刻関数も、名前の文字列の代わりに日付および時刻の数値部分を返す場合に非常に便利です。多くの場合、文字列は数値表現よりも意味を持ちます。そのため、クライアント アプリケーションでユーザーに表示する結果を返す場合は、日付および時刻部分のリテラルの文字列を使用します。ただし、特定の言語で表示されている名前に依存しているロジックはコーディングしないでください。

SQL Server 2005 での XML のサポート

SQL Server 2005 では SQLXML 4.0 が導入されています。SQLXML 4.0 では、SQLXML 3.0 と同じ基本機能を提供しつつ、Microsoft SQL Server 2005 で導入された新機能に対応するように更新が追加されています。

SQL Server 2005 では xml データ型がサポートされており、これを使用して XML のドキュメントやフラグメントをSQL Server データベースに格納できます。XML フラグメントとは、単一の最上位要素を欠いた XML インスタンスです。xml 型の列および変数を作成し、それらに XML インスタンスを格納できます。ただし、格納データのサイズは 2 GB 以内である必要があります。xml データ型および関連するメソッドが実装されていることで、SQL Server のリレーショナル フレームワークに XML を統合できます。

XML と Unicode

SQL Server 2005 の xml データ型には、ISO SQL-2003 標準の xml データ型が実装されています。したがって、整形式の XML Version 1.0 ドキュメントを保存できるほか、テキスト ノードが含まれた、いわゆる XML コンテンツ フラグメントを保存することもできます。システムにより、データが整形式であることが確認されます。このとき XML スキーマに列をバインドする必要はなく、整形式でないデータは拒否されます。

    注 **:   **ただし、この空白文字の処理は XML 1.0 仕様の空白文字に関する記述とは異なります。SQL Server で、要素の内容に含まれる空白文字は、開始タグや終了タグなどのマークアップで区切られた空白文字だけのシーケンス内に出現し、エンティティに変換されていない場合、重要でないと見なされます (CDATA セクションは無視されます)。これは、SQL Server の XML パーサーが XML 1.0 の定義に従って、限定された数の DTD サブセットしか認識しないためです。

SQL Server 2005 では、文字列の型キャスト、SELECT ステートメントと FOR XML 句の使用、一括読み込みの使用、XML の文字列定数への代入など、XML をさまざまな方法で生成できます。文字列型およびバイナリ型が XML ドキュメントのエンコードとやり取りする方法、および XML パーサーの動作の詳細については、SQL Server Books Online の「XML インスタンスの生成」を参照してください。

XML ドキュメントは、UTF-8、UTF-16、Latin-1252 など、さまざまなエンコードを使用してエンコードできます。いくつかの方法で XML のエンコードを指定できます。

• ADO ストリーム オブジェクトでデータを XML として書式化する場合は、出力エンコードを指定でき、適切なエンコードが XML 形式のデータ内にマークされます。

• 出力エンコードを URL で指定できます。

• XML テンプレートでエンコードを指定できます。

上記のいずれの方法も使用しない場合でも、既定で Unicode サポートがサポートされ、正常に動作します。

アップデートグラム

アップデートグラム、または OPENXML Transact-SQL 関数を使用すると、既存の XML ドキュメントから Microsoft SQL Server 2005 データベースのデータを変更 (挿入、更新、または削除) できます。アップデートグラムは多言語テキストで威力を発揮するもので、エンコードを指定するためのメソッドをサポートしています。

OPENXML 関数は、既存の XML ドキュメントを細分化し、INSERT、UPDATE、または DELETE ステートメントに渡すことのできる行セットを提供することによって、データベースを変更します。OPENXML では、データベース テーブルに対して操作が直接実行されます。したがって、OPENXML はテーブルなどの行セット プロバイダをソースとして利用できる場合に最も適しています。

OPENXML と同じように、アップデートグラムを使用してもデータベース内でデータを挿入、更新、または削除できます。ただし、アップデートグラムは、注釈付き XSD (または XDR) スキーマによって提供される XML ビューに対して使用します。たとえば、更新はマッピング スキーマによって提供される XML ビューに適用されます。一方、マッピング スキーマには、XML 要素および XML 属性を対応するデータベースのテーブルおよび列にマップするための必要な情報が含まれています。アップデートグラムはこれらのマッピング情報を使用して、データベースのテーブルと列を更新します。

XML クライアントのためのデータ アクセス

SQLXML 4.0 を使用するには、Microsoft SQL Native Client と、MDAC 2.6 またはそれ以降も必要になります。SQL Native Client に依存するアプリケーションを配置する際は、アプリケーションと一緒に SQL Native Client を再配布する必要があります。現在オペレーティング システムのコンポーネントとなった Microsoft Data Access Components (MDAC) とは異なり、SQL Native Client は SQL Server 2005 のコンポーネントです。したがって、SQL Server Native Client を開発環境にインストールし、SQL Native Client をアプリケーションと一緒に再配布することが重要です。

注 :   SQL Server 2005 でサポートされている限定された DTD サブセットの詳細については、 SQL Server Books Online の「 CAST および CONVERT (Transact-SQL) 」を参照してください。

以前のバージョンの SQLXML では、SQLXML IIS 仮想ディレクトリと SQLXML ISAPI フィルタを使用した、HTTP ベースのクエリの実行がサポートされていました。SQLXML 4.0 では、これらのコンポーネントは類似および重複した機能として削除され、現在 SQL Server 2005 ではネイティブ XML Web サービスと共に提供されています。xml データ型やユーザー定義データ型 (UDT) などの SQL Server 2005 拡張データ型機能と、Web ベースのアクセスを、ソリューションで必要とする場合は、SQLXML マネージ クラスなどの別のソリューションか、SQL Server 2005 のネイティブ XML Web サービスなどの別の種類の HTTP ハンドラを使用する必要があります。

このような SQL Server 2005 の型拡張を必要としない場合は、引き続き SQLXML 3.0 を使用して、インストールされている SQL Server 2005 に接続できます。SQLXML 3.0 の ISAPI のサポートは SQL Server 2005 に対して機能しますが、SQL Server 2005 で導入された xml データ型や UDT 型はサポートされておらず、認識されません。

SQL Server 2005 におけるすべての XML 機能の詳細については、SQL Server Books Online の「SQL Server での XML の使用」および「XML の推奨事項」を参照してください。

クライアント アプリケーションで XML を操作する方法の詳細については、「アプリケーションでの xml データ型の操作」および「SQLXML 4.0 のプログラミング」を参照してください。

フルテキスト検索の機能強化

SQL Server 2005 のフルテキスト検索には、Microsoft Search サービス (MSSearch) のバージョン 3.0 へのメジャー アップグレードが含まれています。次の機能が強化されています。

• フルテキスト インデックスの作成処理のパフォーマンスが大幅に向上。

• SQL Server のインスタンスごとに MSSearch 3.0 のインスタンスを 1 つ使用して、フルテキスト エンジンを別々のインスタンスにサイド バイ サイドでインストール可能。

• クエリの機能強化 (言語を指定する機能など)。

• フルテキスト インデックスの作成と xml データ型の検索をサポート。

フルテキスト エンジンの複数のインスタンス

Microsoft Full-Text Engine for SQL Server (MSFTESQL) サービスは、Microsoft Search (MSSearch) サービスがベースとなっています。SQL Server 2005 では、Microsoft SQL Server のインスタンスごとに別々のサービスがインストールされます。このため、SQL Server と、MSSearch サービスを使用する他のサーバー製品とが MSSearch サービスを共有する必要がなくなりました。フルテキスト エンジンのインスタンスを別々にインストールすることで、サーバーの管理および更新のプロセスが簡略化されます。新しいバージョンの MSSearch サービスがフルテキスト検索の動作に与える影響を心配せずに、MSSearch サービスを使用する Microsoft SharePoint Portal Server などの他の製品をインストールできます。

新しいバージョンの MSSearch へのアップグレードは SQL Server 2005 のセットアップ中に行われます。SQL Server 2005 のインスタンスは、SQL Server の旧バージョンとサイド バイ サイドでセットアップされ、データが移行されます。旧バージョンの SQL Server にフルテキスト検索がインストールされている場合は、新しいバージョンのフルテキスト検索が自動的にインストールされます。

フルテキスト カタログの形式の変更

SQL Server 2005 では、フルテキスト カタログが大幅に変更されています。この変更を行うには、以前のバージョンの SQL Server について、そのすべてのフルテキスト カタログを再構築する必要があります。再構築は自動的に行われ、アップグレードの完了を妨げることはありません。その結果、アップグレード後もフルテキスト カタログの再構築が続行している場合があります。

フルテキスト カタログの再構築の際、新しいフォルダは元のフルテキスト カタログが格納されていたパスの下に作成されます。再構築されたフルテキスト カタログと関連付けられているファイルは、この新しいフォルダに格納されます。

フルテキスト検索の言語固有のオプション

Microsoft SQL Server 2005 では、列の既定言語ではない言語をフルテキスト クエリで使用して、フルテキスト データを検索できます。言語がサポートされていて、そのリソースがインストールされていれば、CONTAINS、CONTAINSTABLE、FREETEXT、FREETEXTTABLE クエリの LANGUAGE language_term 句に指定した言語が、単語の分解、ステミング、シソーラス (類義語)、ノイズ語の処理に使用されます。

列のフルテキスト インデックスを作成する際は、列の言語を選択する必要があります。言語を選択することで、フルテキスト エンジンがテキストをトークン化する方法、およびインデックスを作成する方法のオプションが定義されます。これには、次の作業が含まれます。

• 言語固有のワード ブレーカ、またはニュートラル ワード ブレーカの使用

• 言語ベースのステミング

「付録 E」には、言語固有のステミングまたは単語の分解をサポートしている言語の一覧が記載されています。他の言語ではすべて、言語のニュートラル エンジンが使用されます。この場合、単語の分解では空白が分割に使用され、ステミングは実行されません。

ワード ブレーカは主に通常のテキストの処理を目的としています。したがって、HTML などの何らかのマークアップがテキストに含まれている場合には、言語面での精度が高いインデックス作成と検索は期待できません。このような場合には、2 つの選択肢があります。推奨される方法は、テキスト データを varbinary(max) 列に格納し、ドキュメント タイプを明示してフィルタ処理されるようにする方法です。

データを varbinary(max) 列に格納できない場合は、ニュートラル ワード ブレーカの使用を試みることもできます。可能であれば、マークアップ データ (HTML の "br" など) をノイズ語の一覧に追加することもできます。データを varbinary(max) 列に格納しない場合は、特別なフィルタ処理は実行されず、テキストはそのままの形で単語を分解するコンポーネント (ワード ブレーカ) に渡されます。

Unicode 照合ロケール識別子の設定は、フルテキスト インデックス作成で有効なすべてのデータ型 (char 型や nchar 型など) に適用されます。char、varchar、または text 型の列の並べ替え順を、Unicode 照合ロケール識別子で指定された言語とは異なる言語に設定した場合でも、char、varchar、および text 型の列のフルテキスト インデックスを作成または照会するときは Unicode 照合ロケール識別子が使用されます。

フルテキスト検索のクエリの機能強化

SQL Server 2005 の CONTAINS、CONTAINSTABLE、FREETEXT、および FREETEXTTABLE 句のフルテキスト クエリ構文ではすべて、新しい LANGUAGE <lcid> パラメータがサポートされています。このパラメータを使用して、列の既定のフルテキスト言語を句レベルの言語に変更できます。この句レベルの言語は、フルテキスト クエリのすべての語句に対して、どのワード ブレーカ、ステマ、シソーラス、およびノイズ語の一覧を使用するのかを示します。LCID は数値または文字列のどちらかで指定します。LANGUAGE <lcid> パラメータをストアド プロシージャのフルテキスト クエリで使用する場合は、その値を Transact-SQL の変数として指定することもできます。

たとえば、検索文字列とクエリ レベル言語値を入力パラメータとしてストアド プロシージャに渡すことができます。ストアド プロシージャは、テキスト入力フィールドから検索文字列を取得し、サポートされている言語の一覧からクエリ言語を取得します。

LCID パラメータの使い方を紹介するサンプル コードについては、MSDN ライブラリの「SQL Server 2005 のフルテキスト検索機能 : 内部構造と強化機能について」を参照してください。

フルテキスト クエリでの LCID パラメータの使い方については、SQL Server Books Online の「FREETEXT」、「FREETEXTTABLE」、「CONTAINS」、または「CONTAINSTABLE」を参照してください。

以前のリリースでは、フルテキスト エンジンで DocId からフルテキスト キー値へのマッピングが行われていました。SQL Server 2005 では、この処理はデータベース エンジンに移され、より効率的で一貫性のあるキャッシュ方式を利用できます。この移行により、クエリ エンジンの機能が強化されるだけでなく、以前のリリースよりもフルテキスト クエリの処理速度が向上します。

XML データのフルテキスト検索

SQL Server 2005 では、XML フラグメントまたはドキュメントを格納できる新しい xml データ型が採用されています。SQL Server のフルテキスト検索では、xml データ型に格納されたデータについて、フルテキスト インデックスの作成とフルテキスト クエリがサポートされるようになりました。

クエリは、列値の粒度で実行されます。フルテキスト インデックスが作成された XML 列に対してフルテキスト述語を発行すると、指定された検索文字列が列内に含まれる行が返されます。詳細については、SQL Server Books Online の「varbinary(max) 列および xml 列のクエリ」を参照してください。

他のデータベース製品とのやり取り

国際化対応アプリケーションでは、他のデータベース システムを操作する際、そのシステムのコード ページと規則を決める作業が最も重要になります。SQL Server ではデータ アクセス手段の多くで COM が使用されているため、Unicode データが使用されています。また、SQL Native Client でも Unicode が使用されています。このため、国際化対応アプリケーションが他のデータベース製品とどの程度良好に連動するかを判断するには、まず、それらの他のデータベース製品で Unicode がどの程度適切にサポートされているかを知る必要があります。

たとえば、Oracle や Sybase SQL Server などの他のデータベース製品では、UTF-8 エンコードを使用する Unicode がサポートされています。この場合、データは必ず ADO/OLE DB を使用して UTF-16 に変換されてから情報として表示されるため、通常は問題となることはありません。ただし、これらの製品のデータを直接操作しようとする場合には注意が必要です。

製品によっては、National 文字データ型をサポートしているものの、それらを Unicode データ型として扱わないものがあります。そのようなデータベースでは、nchar および nvarchar フィールドを使用して、本来は米国英語となるデータベースに日本語データを格納することが可能です。Unicode テキストを指定するために National 文字データ型を使用する方法は、Microsoft SQL Server に固有のものです。

したがって、OPENROWSET などのコマンドを使用したり、別の製品に対してクエリを実行したり、他のシステムからデータをインポートしたりする場合は、国際化テキスト情報が他のデータベースでどのように扱われるのかについて理解しておくことが非常に重要になります。

詳細については、SQL Server Books Online の「SQL Server データベース エンジンへの接続」および「分散クエリ」を参照してください。

アプリケーションの開発において SQL Server 2005 で外部データ ソースに接続する場合は、その詳細について SQL Server Books Online の次の各トピックを参照してください。

結論

Microsoft SQL Server 2005 は、SQL Server 2000 で提供されていた強力な国際化機能のセットをベースとして構築され、より一貫性のある強化された Unicode サポートが追加されています。また、Windows オペレーティング システムや共通言語ランタイム (CLR) の多言語機能との統合も追加されています。SQL Server 2005 によって、国際化データベースをサポートする強固な基盤と、広範な多言語環境ツールが組み合わされ、財務、電子商取引、グローバル通信などの分野の国際化ソリューションを迅速に開発し、確実に配置できます。

詳細については、以下を参照してください。
https://msdn2.microsoft.com/ja-jp/sql/default(en-us).aspx

このホワイト ペーパーは役に立ちましたか?フィードバックをお寄せください。1 (役に立たなかった) ～ 5 (非常に役に立った) の 5 段階で評価してください。

謝辞

このホワイト ペーパーの初版は、SQL Server 2000 向けとして、Michael Kung (SQL Server プログラム マネージャ)、Peter Carlin (SQL Server リレーショナル エンジン開発マネージャ)、および Fernando Caro (国際化プログラム主任マネージャ) の支援のもと、Michael Kaplan によって執筆されました。また、Michael Rys、Euan Garden、Fadi Fakhouri、James Howey、および Margaret Li によって補足情報が加筆されました。SQL Server 7.0 および 2000 の照合順序のサポートに関する情報は、Julie Bennett、Cathy Wissink、および John McConnell から提供されました。

SQL Server 2005 の機能に関する最新情報については、Fernando Caro および Nobuhiko Kishi の支援のもと、SQL Server User Education チームから提供されました。

付録 A 照合順序サフィックス

**注:   ** かなの区別は、既定では区別しないように設定されています。つまり、既定ではカタカナとひらがなは同じものとして扱われます。文字幅の区別も、既定では区別しないように設定されています。つまり、既定では全角文字と半角文字は同じものとして扱われます。

付録 B Windows でサポートされているロケール

付録 C SQL 固有の並べ替え順序

SQL 固有の並べ替え順序は SQL Server 2000 にも組み込まれています。次の表にこれらの SQL 固有の並べ替え順序を示します。これらの多くは前述したサフィックスの各部分のいくつかをサポートしていますが、すべてのサフィックスをサポートしているとは限りません。

付録 D SQL Server 2005 でサポートされている言語

次のステートメントを実行すると、これと同じ一覧を SQL Server 2005 で表示できます。

select langid, alias, lcid, msglangid from sys.syslanguages

付録 E SQL Server 2005 で追加されたフルテキスト言語

この一覧は SQL Server Books Online の「フルテキスト検索の言語選択時の注意」でも参照できます。フルテキストのインデックス作成およびクエリの操作で使用できる言語の一覧を参照するには、sys.fulltext_languages を使用してください。

付録 F SQL Server 2005 で更新された照合順序

この一覧は SQL Server Books Online の「セットアップでの照合順序の設定」でも参照できます。SQL Server 2005 のインスタンスでサポートされている照合順序の一覧を参照するには、fn_helpcollations () を使用してください。