Microsoft SQL Server 2000 のインターナショナル機能
Michael Kaplan
Trigeminal Software, Inc.
April 2001
要約 : この記事では、Microsoft SQL Server の開発者を対象に、SQL Server 2000 のインターナショナル機能について説明します。Unicode および SQL Server のインターナショナル データ型について詳しく説明すると共に、実装に関する問題点を取り上げます。
内容
はじめに
Unicode とその使用方法
SQL Server 2000 のデータ型
パフォーマンスと記憶域
システム テーブルのメタデータ情報
照合順序
サーバーとクライアント間の通信 (コード ページと照合順序に関する問題)
ユーザー インターフェイスの多言語データ
SQL Server のデータにアクセスする (データ アクセス方式)
多言語の Transact-SQL
SQL Server 2000 のロケール サポート
データ変換サービス
bcp ユーティリティを使用して多言語データを処理する
Microsoft Search サービスと FTS
OLAP/階層構造データを操作する
SQL Server 2000 の XML サポートを使用して多言語データを操作する
ほかのデータベース製品とやり取りする
結論
謝辞
著者紹介
はじめに
Microsoft® SQL Server 2000 には、インターナショナルな操作および環境をサポートするための強力な機能が用意されています。多彩な多言語機能を備えた SQL Server 2000 は、非常に優れたデータベース製品であり、アプリケーション プラットフォームであると言えます。この記事では、グローバル環境におけるこれらの機能の使用方法について詳しく説明します。機能の一覧を紹介するだけでなく、インターナショナル要件と多言語要件がプロジェクトのさまざまな側面に与える影響についても説明します。
Unicode とその使用方法
SQL Server 2000 における多言語サポートの基本となるのが Unicode です。Unicode は、世界各国の文字体系に対応できるように設計された標準規格であり、使用するプラットフォーム、プログラム、および言語にかかわらず、すべての文字にそれぞれ固有のコード ポイントが割り当てられています。Unicode 対応のプログラムは、あらゆる言語のデータを処理することができます。Unicode 3.0 では、最大 1,114,112 文字の処理が可能です。
Unicode は Unicode Consortium が管理している業界標準です。Unicode Consortium は、あらゆる言語に対応した単一の文字セットを提供することの重要性を提唱している組織であり、Microsoft もそのメンバです。グローバル ソフトウェア ソリューションを開発する上で、多言語データを表現するための手段が重要なのは言うまでもありません。Unicode Consortium に加入しているほとんどの企業は、Microsoft と同様、その重要性を十分に感じています。さらに、多言語データを処理するための方法やその問題点については、ほかの多くの企業や個人も関心を寄せています。
Unicode 規格 (現在はバージョン 3.01) は、Unicode 1.1 のリリース後に国際標準 ISO-10646 として採用されました。ISO-10646 では、Unicode とまったく同じコード ポイントが使用されています。業界標準として、さらには国際標準として採用された今、"すべてのユーザーに単一の文字セットを提供する" というその目標を阻止することはだれにもできません。
詳細については、Unicode Consortium の Web サイト .gif)
(英語) を参照してください。
エンコーディング
Unicode はコード ポイントを文字にマップします。ただし、メモリ、データベース、または Web ページ上で実際にデータをどのように表現するかは指定しません。そこで、Unicode データのエンコードが必要となります。Unicode にはさまざまな種類のエンコード方式があります。ここでは、次の一般的なエンコード方式について説明します。
UCS-2
UTF-16
UTF-8
ここでエンコード方式について説明するのは、Unicode がどのように使用され、どのように格納されるのかを理解していただくためです。通常は、Unicode のデータ型を選択するだけなので、詳細を把握している必要はありません。ただし、次の場合はエンコード方式についての理解が重要となります。
Unicode を別の方法でエンコードするアプリケーションを使用する場合
ほかのプラットフォーム (Microsoft Windows® 以外のプラットフォーム) または Web サーバーにデータを送信する場合
データのインポート元またはエクスポート先とエンコード方式が異なる場合
UCS-2
UCS-2 は、Microsoft Windows NT® 4.0、Microsoft SQL Server 7.0、および Microsoft SQL Server 2000 で使用されている基本の Unicode エンコード方式です。UCS-2 では、65,536 種類のコード ポイントをエンコードできます。SQL Server 2000 で扱うすべての Unicode データはこのエンコード方式で格納されます。つまり、使用する文字の種類にかかわらず、どの文字もすべて 2 バイトで表されます。したがって、ラテン文字の "A" は、次の文字と同じように処理されます。
キリル文字 Sha
.gif)
ヘブライ文字 Lamed
.gif)
タミル文字 Rra
.gif)
日本語のひらがな E
.gif)
各文字にはそれぞれ異なるコード ポイントが割り当てられます。たとえば、上記の文字の場合は、順に U+0041、U+0248、U+05DC、U+0BB1、U+3048 が割り当てられます (4 桁の 16 進数値は、UCS-2 が使用する 2 バイトを表します)。
オペレーティング システム レベルではバイト順が非常に重要です。SQL Server は Windows プラットフォーム上で動作するので、(下位のバイトを最初に置く) リトル エンディアン エンコーディング システムを使用します。したがって、0x1234 などの 16 進ワードは、0x34 0x12 としてメモリに格納されます。
UTF-16
UTF-16 は、Microsoft Windows 2000 で使用されている基本的な Unicode エンコード方式です。わずか 65,536 文字では Unicode の目標 (あらゆる言語のすべての文字を 1 つのコード ポイントで表現する) を達成できないことは、Unicode 2.0 のリリース以前に既に明らかになっていました。中国語など一部の言語には使用頻度の低い文字が多数ありますが、それらもすべてエンコードしなければなりません。そこで、さらに 1,048,576 文字を処理できるようにサロゲート領域が追加されました。UTF-16 は、当初の標準規格に追加されたこの拡張領域を完全にサポートしているエンコード方式です。サロゲート領域の詳細については、後の「サロゲートについて」を参照してください。
UTF-16 の場合、基本的には各コード ポイントを 2 バイトで表しますが、一部のコード ポイントではその後に別のコード ポイントを追加して文字を定義します。
UCS-2 と同様、やはり Windows 上で使用する UTF-16 も既定ではリトル エンディアン方式で格納されます。
重要 : UCS-2 はサロゲートを認識しませんが、サロゲートを含むデータベース内のデータを壊す心配はありません。UCS-2 は、2 つの異なる (未定義の) 文字としてサロゲートを処理します。
SQL Server 7.0 および SQL Server 2000 は情報を損なうことなくサロゲート ペアを格納できますが、1 つの文字としてではなく、2 つの未定義の Unicode 文字としてサロゲート ペアを処理します。一般に、このようなアプリケーションを "サロゲート対応" または "サロゲート セーフ" と呼んでいます (ここで言う "セーフ" とは、サロゲート ペアを処理するための機能が備わっていなくても、データを格納できることを意味しています)。サロゲート文字はまだ正式に定義されていないため、現在のところ、"サロゲート対応" のアプリケーションはそれほど多くありません。Microsoft Word 2000、Microsoft Windows 2000、Microsoft Internet Explorer 5.0 以降は、そのごく少ないサロゲート対応のアプリケーションです。
UTF-8
8 ビット エンコーディングを必要とする ASCII システムやバイトを基本とするその他多くのシステム (メール サーバーなど) は、エンコード方式、バイト順、使用言語の異なる多種多様なコンピュータに対応しなければなりません。UTF-8 は、コンピュータのバイト順にかかわらず、Unicode データを統一的に処理できるように設計されたエンコード方式です。SQL Server 2000 はデータを UTF-8 形式で保存しませんが、非常に重要なシナリオで UTF-8 をサポートしています。それが XML (Extensible Markup Language) です。詳細については、後の「SQL Server 2000 の XML サポートを使用して多言語データを操作する」を参照してください。
Oracle や Sybase SQL Server など、その他多くのデータベース システムは Unicode を UTF-8 形式で格納します。サーバーの実装によっては、この方がデータベース エンジンをより簡単に実装できます (サーバー上の既存のテキスト管理コードはいずれもデータを 1 バイトつず処理するように設計されているので、大きく手直しする必要がありません)。ただし、Windows 環境の場合、UTF-8 形式での格納には次のようなデメリットがあります。
コンポーネント オブジェクト モデル (COM) の API およびインターフェイスがサポートしているのは UTF-16 と UCS-2 だけなので、UTF-8 形式で格納されたデータは必ず変換しなければなりません (この問題が発生するのは COM を使用する場合だけです。通常、SQL Server データベース エンジンは COM インターフェイスを呼び出しません)。
Windows NT および Windows 2000 のカーネルはいずれも Unicode であり、それぞれ UCS-2 と UTF-16 を使用します。したがって、UTF-8 形式で格納されている場合はやはり変換が必要となります (上記の COM についての説明と同様、SQL Server データベース エンジンには負担がかかりませんが、クライアント側の多くの操作に影響を与える可能性があります)。
通常、UTF-8 を使用すると文字列処理が低速になります。文字が固定幅ではないので、並べ替えや比較など、ほとんどすべての文字列操作で余分な時間を要します。
UTF-8 は 2 バイトを超える場合が多く、それだけディスク領域やメモリを消費します。
XML は、バイト単位の処理を基本とするインターネット通信の非常に重要な規格の 1 つです。したがって、UTF-8 を使用しているのはある意味当然と言えます。
サロゲートについて
Unicode の U+D800 から U+DFFF までの範囲をサロゲート領域と言い、1024 の下位サロゲート値と 1024 の上位サロゲート値で構成されています。上位と下位のサロゲートを合わせれば、100 万種類以上の文字を表現できます。サロゲート ペアは、その片方だけでは有効と見なされません。必ず、上位サロゲートと下位サロゲートがペアになっていなければなりません。これによって、サロゲート領域を簡単にチェックできるので、DBCS (2 バイト系) 文字の検出に伴う複雑さがかなり軽減されます。
SQL Server 7.0 のリリース時にはサロゲートがありませんでした。SQL Server 2000 のリリース時には、プレーン テキストの言語タグに関するサロゲート文字だけが定められていました。
重要 : 既に説明したように、サロゲートはデータを損失することなく格納できます。ただし、SQL Server の文字列操作関数を使用してこれらのデータを操作するときは、十分な注意が必要です。また、現在、Windows 2000 がサポートしているのは、サロゲート文字のコード ポイントの並べ替えだけです。
SQL Server 2000 がリリースされた後、ISO および Unicode 標準化グループの努力により、さらに多くの文字がサロゲート領域に追加されました。CJKV (中国語、日本語、韓国語、ベトナム語) の約 40,000 種類の表意文字もこの中に含まれています。これらの文字は主に歴史書や古典文学などで用いられ、CJKV の豊かな文学遺産のエンコードに役立っています。
SQL Server 2000 のデータ型
データベースの主なタスクは、言うまでもなくデータの格納です。ここでは、SQL Server 2000 のデータ型を使用して多言語データを格納する際の問題点について説明します。
非 Unicode の文字列型 : char、varchar、text
char 型、varchar 型、または text 型で格納された文字列データを処理する場合、考慮すべき最も重要な制限は、1 つのコード ページの情報しか格納できないという点です。実際のコード ページは、列の照合順序によって異なります (列レベルの照合順序が指定されていない場合は、データベースの照合順序が使用されます)。特定の列で使用されるコード ページを確認するには、次のように 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
最後の例で Hindi (ヒンディー語) が指定されているのは、多くのロケール (グルジア語やヒンディー語など) にコード ページが存在しないことを示すためです。これらの照合順序は "Unicode のみ" となります。"Unicode のみ" の照合順序は、非 Unicode のデータ型に適していません。
このような列に Unicode データを挿入しなければならない場合、WideCharToMultiByte API および対象となる照合順序のコード ページを使用して、Unicode データが内部で変換されます。そのコード ページでは表すことのできない文字があると、それらの文字は疑問符 (?) に置き換えられます。必要以上に多数の文字が疑問符に置き換えられている場合は、変換時にデータが破損したと考えてよいでしょう。また、本当は Unicode データ型を使用すべき場合にも同様の結果となります。非 Unicode 型の文字列リテラルを使用する場合、まず、(照合順序に基づく) データベースの既定のコード ページを使用してそのリテラルが変換されます。
使用するすべての文字が目的のコード ページに含まれていない場合にも、データの格納時に問題が発生します。その一例がアラビア文字です。アラビア文字は、バルーチー語、ベルベル語、ペルシア語、カシミール語、カザフ語、キルギス語、クルド語、パシュトウ語、シンド語、ウイグル語、ウルドゥー語などさまざまな言語で使用されています。これらすべての言語には、アラビア語 (Windows コード ページ 1256) 以外の文字も含まれています。したがって、Arabic (アラビア) 照合順序を使用してこれらの言語を非 Unicode 列に格納した場合、アラビア語のコード ページに含まれていない文字は疑問符に変換されてしまいます。多くの場合、この問題の原因は、ある 1 つのコード ページが "最適な" コード ページだと見なされる点にあります。つまり、そのコード ページが最も適しているというだけで、それを使用してすべての文字を処理できるという保証はありません。
Unicode の文字列型 : nchar、nvarchar、ntext
SQL-92 仕様ではこれらの "N" (National の略) データ型が定義されていますが、Unicode での使用は義務付けられていません。これらのデータ型の実際の定義は、データベース プラットフォームや開発者に任されています。SQL Server 7.0 および SQL Server 2000 では、これらのデータ型を使用して UCS-2 と UTF-16 の Unicode を表すように定義されています。ただし、これは Microsoft SQL Server の場合だけであることに注意してください。ほかのデータベース サーバー (Sybase SQL Server など) を使用する場合、"N" データ型は Unicode を意味しません。
ヒンディー語やタミル語など、複雑な言語体系の文字を格納するときは、データが正しい順序であることが前提となります。タミル語を含む多くの言語では、文字列を表現するときに一部の文字が並べ替えられます。つまり、メモリに格納されている文字列の論理順序と、ユーザー インターフェイスに表示される文字列の順序が異なることになります。インド語派、アラビア語、ペルシア語、ヘブライ語など文字体系の複雑な言語では、必ず正しい論理順序でデータを格納する必要があります。これらのデータが実際にどのように表示されるかについては、この後の「ユーザー インターフェイスの多言語データ」を参照してください。
"N" 列には、あらゆる言語およびあらゆる言語の組み合わせのデータを格納できますが、実際には 1 つの照合順序だけが適用されます (詳細については、後の「照合順序」を参照してください)。前に説明したコード ページの制約は Unicode 列には適用されません。
日付/時刻型 : datetime、smalldatetime
これらのデータ型は多言語対応ではありません。次の定義に基づいて日付/時刻値を表します。
datetime
グレゴリオ暦の 1753 年 1 月 1 日～ 9999 年 12 月 31 日の日付と時刻を 1/300 秒の精度 (3.33 ミリ秒または 0.00333 秒) で表します。
smalldatetime
グレゴリオ暦の 1900 年 1 月 1 日～ 2079 年 6 月 6 日の日付と時刻を分単位で表します。smalldatetime 値が 29.998 秒以下の場合は前の分数に切り捨てられ、29.999 以上の場合は次の分数に切り上げられます。
Microsoft SQL Server はこの範囲外のデータを拒否します。実際には、日付と時刻を表す 2 つの整数 (datetime は 4 バイトの整数、smalldatetime は 2 バイトの整数) として格納されます。これらの日付/時刻値はロケールに合わせて書式設定されません。必要に応じて開発者が書式変換を定義します。
SQL Server 2000 は、世界各国に対応した多数の書式変換をサポートしています。これらの変換はサーバーで実行されるので、独自のソリューションを開発する必要はありません。日付の書式を定義するには、データ型、式、書式を指定して CONVERT 関数を呼び出します。次の表を参照してください。
| 西暦 (4 桁表示) | 西暦 (2 桁表示) | 規格 | 入力 (datetime へ変換) 出力 (文字列へ変換) |
| 0 または 100 | - | 既定値 | mon dd yyyy hh:miAM (または PM) |
| 101 | 1 | USA | mm/dd/yy |
| 102 | 2 | ANSI | yy.mm.dd |
| 103 | 3 | イギリス/フランス | dd/mm/yy |
| 104 | 4 | ドイツ | dd.mm.yy |
| 105 | 5 | イタリア | dd-mm-yy |
| 106 | 6 | - | dd mon yy |
| 107 | 7 | - | Mon dd, yy |
| 108 | 8 | - | hh:mm:ss |
| 9 または 109 | - | 既定値 + ミリ秒 | mon dd yyyy hh:mi:ss:mmmAM (または PM) |
| 110 | 10 | USA | mm-dd-yy |
| 111 | 11 | 日本 | yy/mm/dd |
| 112 | 12 | ISO | yymmdd |
| 13 または 113 | - | ヨーロッパ既定値 + ミリ秒 | dd mon yyyy hh:mm:ss:mmm(24h) |
| 114 | 14 | - | hh:mi:ss:mmm(24h) |
| 20 または 120 | - | ODBC 標準 | yyyy-mm-dd hh:mi:ss(24h) |
| 21 または 121 | - | ODBC 標準 + ミリ秒 | yyyy-mm-dd hh:mi:ss.mmm(24h) |
| 126 | - | ISO8601 (スペースなし) | yyyy-mm-dd Thh:mm:ss:mmm |
| 130 | - | クウェート (ヒジュラ) | dd mon yyyy hh:mi:ss:mmmAM |
| 131 | - | クウェート (ヒジュラ) | dd/mm/yy hh:mi:ss:mmmAM |
次の例は、CONVERT 関数の使用方法を示しています。
SELECT CONVERT(char, GETDATE(), 100) AS [100]
Aug 16 2000 11:50AM
同じ方法で、日付を表す文字列を日付値へ変換することもできます。
SELECT CONVERT(datetime, 'Aug 16 2000 11:50AM', 100) AS [100]
スタイル 130 (クウェートまたはヒジュラ) の日付を char データ型に変換する場合、コード ページ 1256 を使用する Arabic (アラビア語) 照合順序に基づいて Unicode 変換を行わないと、データが壊れる可能性があります。次の図 (図 1) はこの問題を示しています。
.gif)
図 1. 日付/時刻 Transact-SQL の変換
日本語クライアント コンピュータで char データ型を使用すると、アラビア文字は疑問符に変換されます。nchar データ型の場合はアラビア文字として表示されます。SQL クエリ アナライザの SQL グリッドに制約があるため、日本語クライアント コンピュータではこのアラビア文字を正しく表示できません (アラビア語のクライアント コンピュータでは正しく表示できます)。次の図 (図 2) は、ヒジュラの日付文字列が実際にどのように表示されるかを示しています。
.gif)
図 2. ヒジュラの日付文字列
これは、アラビア語などの複雑な文字体系では表記ルールが定められており、データを正しく表示するためにそのルールが必ず適用されるためです。ヘブライ語などの双方向 (BIDI) 言語ではすべてのデータが逆方向に表示されるので、その影響はより顕著になります。これは、文字の実際の表記がその前後の文字によって変わってくるためです。Windows 2000 およびアラビア語対応のその他の Windows ではこの問題が発生しません。
さらに、双方向言語では、返される日付文字列自体が問題となる場合もあります。アプリケーション (Internet Explorer や Windows 2000 など) が使用する双方向テキストのレイアウト ルールにより、日付が次の図 (図 3) のように表示されてしまいます。
.gif)
図 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 データ型を使用すると、記憶域と処理速度に悪影響を及ぼす可能性があります。
記憶域に関する問題
Unicode データ型を格納するには 1 文字につき 2 バイト必要です。非 Unicode データ型では、1 文字につき 1 バイト (DBCS 以外のすべてのテキスト) または 2 バイト (DBCS を使用するアジア言語) を使用します。したがって、アジア言語のコード ページのデータでない限り、データを格納するのに 2 倍の領域を使用することになります。既存のデータベースをアップグレードするときや、新規プロジェクトのデータ型を決定するときは、この点を考慮しなければなりません。(アジア言語以外の) 1 つのコード ページの列にのみデータを格納する場合は、Unicode を使用しない方がディスク領域やメモリを節約することができます。
処理速度に関する問題
処理速度は複雑な問題です。次の点に注意してください。
Windows NT または Windows 2000 のカーネルは Unicode データの処理を前提としています。したがって、非 Unicode 列を使用した場合、データを表示するときやオペレーティング システムのサービスを使用するときなど、さまざまな場面で変換処理が必要となります。
大量のデータは読み込みに時間がかかります。DBCS データを処理する場合もこの点を考慮しなければなりません。
Windows 95 および Windows 98 のクライアントまたはサーバーでは、データ表示などオペレーティング システムのサービスを必要とするとき、多くの情報を Unicode から変換しなければなりません。
複数のサーバー (後の「サーバーとクライアント間の通信」を参照)、データベース サーバー製品、またはその他の製品を使用して作業する場合、変換処理が必要となり、パフォーマンスに大きな影響を与えます。
アジア言語を処理する場合、その言語の DBCS コード ページを使用するより、Unicode を使用した方が高速に処理できます。これは、DBCS データが固定幅ではなく、2 バイト文字と 1 バイト文字が混在しているためです。
アジア言語以外の場合、Unicode データを使用すると、非 Unicode データを使用したときと比べて最大 30% 処理速度が低下します。グローバル データを表現するには、処理速度のある程度の犠牲はやむを得ません。
重要 : 正確なパフォーマンスを評価するには、それぞれの環境で実際にテストする必要があります。
システム テーブルのメタデータ情報
SQL Server 2000 のシステム テーブルには、すべてのデータが Unicode として格納されます。これによって、データベースや列によって照合順序が異なっていても、問題の発生を最小限に抑えることができます。同じサーバー上で、Unicode 列名を使用しているデータベースと非 Unicode 列名を使用しているデータベースが混在する状況に対処するには、これ以外に方法がありません。また、現在のサポート対象が 1 つの言語だけだとしても、今後サポートされるすべての言語に対応できなければなりません。
SQL Server 6.5 および以前のバージョンからデータベースやサーバーを変換する場合、メタデータの変換はどうなるのでしょうか? 心配はいりません。SQL Server Version 6.5 以前のバージョンでは 1 つのコード ページと照合順序がサーバー レベルで定義されているだけなので、Unicode へ簡単に変換できます。
1 つ問題なのは、システム テーブルに格納されているオブジェクトの識別子を使用する場合です。SQL Server 2000 は Unicode 2.0 の文字プロパティ定義を使用して、識別子の有効な文字リストを作成します (SQL Server 2000 の完成時には Unicode 3.0 はリリースされていませんでした)。Unicode 2.0 の文字プロパティ定義に含まれていない多言語文字を使用したときに問題が発生するのを防ぐには、識別子を角カッコ ([ ]) または二重引用符 (") で囲む必要があります。これによって、サーバーが文字の有効性をチェックしなくなります。
照合順序
だれもが "アルファベットを当然" と思い込み、特に疑いを持たないことの 1 つにデータの並べ替えがあります。ギリシャ語、ロシア語、タイ語、日本語など、アルファベット以外の文字セットを使用する言語が存在するにもかかわらず、少なくとも米国内ではアルファベットが基本となっています。
問題は、それが大きな間違いだという点です。たとえばスペイン語では、"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 フィールドの照合順序ではこの基本的な問題が生じます。さらに、ペルシア語のように、"最適な" コード ページを使用する言語では、やはり同様の問題が発生します (前の「非 Unicode の文字列型 : char、varchar、text」を参照)。
SQL Server 7.0 の照合順序
SQL Server 7.0 では、サーバーごとに異なる Unicode 照合順序と非 Unicode 照合順序を使用します。非 Unicode 照合順序は、コード ページと並べ替え順 ID で構成されます。これは、各コード ページが複数の並べ替えをサポートしているためです。たとえば、ラテン系言語を並べ替えるときは、大文字と小文字を区別するかどうかを指定できます。簡体字中国語では、画数で並べ替えるか、発音に基づいて並べ替えるかを選択できます。
Unicode 照合順序では、あらゆる言語のすべての文字を同じ列に挿入することが可能です。この場合、その照合順序独自のルールが適切に処理されるので、"最適な" コード ページに伴う問題を解決できます。たとえば、汎用 Unicode 照合順序を使用してペルシア語のデータを並べ替えれば、期待どおりの結果が得られます。Unicode 照合順序は、1 つのロケールと複数の比較スタイルで構成されます。通常、ロケールには対象となる国または文化圏と同じ名前が付けられ、その地域の言語規則に基づいて文字列を並べ替えます。Unicode 規格のすべての文字の並べ替え順を定めた Unicode 照合順序もありますが、指定されたロケールの方が優先されます。
次の表は、SQL Server 7.0 がサポートしている Unicode 照合順序を示しています。この表に記載されていないロケールは汎用 Unicode 照合順序を使用します。
| ロケール ID (LCID) | 説明 |
| 1033 | 汎用 Unicode |
| 33280 | バイナリ順 |
| 1027 | カタロニア語 |
| 197636 | 中国語 (台湾) |
| 2052 | 中国語 (句読法) |
| 133124 | 中国語 (画数) |
| 1028 | 中国語/画数 (台湾) |
| 1050 | クロアチア語 |
| 1029 | チェコ語 |
| 1043 | オランダ語 |
| 1061 | エストニア語 |
| 1036 | フランス語 |
| 66615 | グルジア語 (モダン) |
| 1031 | ドイツ語 |
| 66567 | ドイツ語 (電話帳) |
| 1038 | ハンガリー語 |
| 66574 | ハンガリー語 (実用) |
| 1039 | アイスランド語 |
| 1040 | イタリア語 |
| 1041 | 日本語 |
| 66577 | 日本語 Unicode |
| 1042 | 韓国語 |
| 66578 | 韓国語 Unicode |
| 1062 | ラトビア語 |
| 1063 | リトアニア語 |
| 1071 | マケドニア語 |
| 1044 | ノルウェー語/デンマーク語 |
| 1045 | ポーランド語 |
| 1046 | ポルトガル語 |
| 1048 | ルーマニア語 |
| 1051 | スロバキア語 |
| 1060 | スロヴェニア語 |
| 1034 | スペイン語 (トラディショナル) |
| 3082 | スペイン語 (モダン) |
| 1053 | スウェーデン語/フィンランド語 |
| 1054 | タイ語 |
| 2057 | 英語 (U.K.) |
| 1058 | ウクライナ語 |
| 1066 | ベトナム語 |
この一覧に記載されていない言語もありますが、それらの言語には汎用 Unicode が適用されます。たとえば、汎用 Unicode の並べ替え順は Unicode データを正しく処理するだけでなく、アフリカーンス語、アルバニア語、アラビア語、バスク語、ベラルーシ語、ブルガリア語、英語、フェロー語、ペルシア語、グルジア語 (トラディショナル)、ギリシャ語、ヘブライ語、ヒンディー語、インドネシア語、マレー語、ロシア語、セルビア語、スワヒリ語、ウルドゥー語の並べ替えでも使用されます。この表に記載されているのは、汎用 Unicode とは何らかの点で規則の異なる照合を使用する言語です。
SQL Server の開発者は "政治" とは無関係なので、ある国や地域に対して "ほかの国または地域の名前が付いた並べ替え順を強要" するつもりはありません。たとえば、セルビア・モンテネグロに住んでいるユーザーの場合、必ずしも "クロアチア" 並べ替え順を使用する必要はありません。クロアチア語とセルビア語は同じ照合順序を使用するので、どちらの名前を使用するかは自由です。このように、並べ替え順の名前はまったくの任意なので、ほかの国または地域のユーザーを対象とする場合は数値を使用してください。最も重要なのは、データを適切に処理するための照合順序を選択できるという点です。
SQL Server 7.0 における大きな変更点の 1 つに、オペレーティング システムに依存しない文字列比較モデルの採用があります。これによって、Windows 95 から Windows 2000 まで、すべてのオペレーティング システムで一貫した照合順序を使用できるようになりました。このコードは、Windows 2000 が独自の文字列正規化で使用しているコードに基づいており、すべてのコンピュータ上で実行できるようにカプセル化されています。この変更によって、小規模な MSDE から大規模な SQL Server Enterprise Edition まで、オペレーティング システムに頼らなくても多言語機能を実現できるようになりました。
SQL Server 2000 の照合順序
SQL Server 2000 では、次の理由から照合モデルが変更されています。
2 種類の照合順序を使用するのは混乱を招く。
新しいすべての地域に対応するには、より柔軟な照合モデルが必要。
SQL Server 2000 では、非 Unicode 列のコード ページも照合順序によって指定されるので、より多くの照合順序が必要となる。
Unicode と非 Unicode 両方の並べ替えを処理するため、一貫した統合モデルが設計されました。このモデルは次の言語をサポートしています。
| SQL Server 2000 の照合順序 | ||
| Albanian | Arabic | Chinese_PRC |
| Chinese_PRC_Stroke | Chinese_Taiwan_Bopomofo | Chinese_Taiwan_Stroke |
| Cyrillic_General | Croatian | Czech |
| Danish_Norwegian | Estonian | Finnish_Swedish |
| French | Georgian_Modern_sort | German_PhoneBook |
| Greek | Hebrew | Hindi |
| Hungarian | Hungarian_Technical | Icelandic |
| Japanese | Japanese_Unicode | Korean_Wansung |
| Korean_Wansung_Unicode | Latin1_General | Latvian |
| Lithuanian | Lithuanian_Classic | FYRO Macedonian |
| Modern_Spanish | Polish | Romanian |
| Slovak | Slovenian | Thai |
| Traditional_Spanish | Turkish | Ukrainian |
| Vietnamese |
これらの照合順序は、大文字/小文字、アクセント、全角/半角、ひらがな/カタカナの区別を定義するためのサフィックスと組み合わせて使用します。指定できるサフィックスは次の表のとおりです。前の表に記載されている 40 種類の言語は、それぞれ次の 17 のサフィックスをサポートしています。したがって、合計 680 種類の Windows 照合順序を使用できることになります。
| 照合順序のサフィックス | 意味 |
| _BIN | バイナリ順 |
| _CI_AI | 大文字/小文字を区別しない、アクセントを区別しない、ひらがな/カタカナを区別しない、全角/半角を区別しない |
| _CI_AI_WS | 大文字/小文字を区別しない、アクセントを区別しない、ひらがな/カタカナを区別しない、全角/半角を区別する |
| _CI_AI_KS | 大文字/小文字を区別しない、アクセントを区別しない、ひらがな/カタカナを区別する、全角/半角を区別しない |
| _CI_AI_KS_WS | 大文字/小文字を区別しない、アクセントを区別しない、ひらがな/カタカナを区別する、全角/半角を区別する |
| _CI_AS | 大文字/小文字を区別しない、アクセントを区別する、ひらがな/カタカナを区別しない、全角/半角を区別しない |
| _CI_AS_WS | 大文字/小文字を区別しない、アクセントを区別する、ひらがな/カタカナを区別しない、全角/半角を区別する |
| _CI_AS_KS | 大文字/小文字を区別しない、アクセントを区別する、ひらがな/カタカナを区別する、全角/半角を区別しない |
| _CI_AS_KS_WS | 大文字/小文字を区別しない、アクセントを区別する、ひらがな/カタカナを区別する、全角/半角を区別する |
| _CS_AI | 大文字/小文字を区別する、アクセントを区別しない、ひらがな/カタカナを区別しない、全角/半角を区別しない |
| _CS_AI_WS | 大文字/小文字を区別する、アクセントを区別しない、ひらがな/カタカナを区別しない、全角/半角を区別する |
| _CS_AI_KS | 大文字/小文字を区別する、アクセントを区別しない、ひらがな/カタカナを区別する、全角/半角を区別しない |
| _CS_AI_KS_WS | 大文字/小文字を区別する、アクセントを区別しない、ひらがな/カタカナを区別する、全角/半角を区別する |
| _CS_AS | 大文字/小文字を区別する、アクセントを区別する、ひらがな/カタカナを区別しない、全角/半角を区別しない |
| _CS_AS_WS | 大文字/小文字を区別する、アクセントを区別する、ひらがな/カタカナを区別しない、全角/半角を区別する |
| _CS_AS_KS | 大文字/小文字を区別する、アクセントを区別する、ひらがな/カタカナを区別する、全角/半角を区別しない |
| _CS_AS_KS_WS | 大文字/小文字を区別する、アクセントを区別する、ひらがな/カタカナを区別する、全角/半角を区別する |
これらの言語名は、非 Unicode データで使用する各コード ページ、およびすべてのデータを対象とした並べ替え順に合わせて任意に付けたものです。ある言語を別のコード ページで完全に表すことができる場合、またはある言語の並べ替え順が別の言語の並べ替え順とまったく同じ場合、重複して記載する必要はないので、その言語は表から "削除" されています。既定値では、ひらがな/カタカナおよび全角/半角が区別されません。
以前のバージョンの SQL Server のコード ページにも対応できるようにするため、SQL Server 2000 は、下位互換性が保証された SQL 独自の多数の並べ替え順をサポートしています (次の表を参照)。これらの多くは、前に説明したさまざまなサフィックスに対応しています。ただし、すべてのサフィックスをサポートしているわけではありません。
| SQL の並べ替え順 | ||
| SQL_1xCompat_CP850 | SQL_Estonian_CP1257 | SQL_Latin1_General_Pref_CP437 |
| SQL_AltDiction_CP1253 | SQL_Hungarian_CP1250 | SQL_Latin1_General_Pref_CP850 |
| SQL_AltDiction_CP850 | SQL_Icelandic_Pref_CP1 | SQL_Latvian_CP1257 |
| SQL_AltDiction_Pref_CP850 | SQL_Latin1_General_CP1 | SQL_Lithuanian_CP1257 |
| SQL_Croatian_CP1250 | SQL_Latin1_General_CP1250 | SQL_MixDiction_CP1253 |
| SQL_Czech_CP1250 | SQL_Latin1_General_CP1251 | SQL_Polish_CP1250 |
| SQL_Danish_Pref_CP1 | SQL_Latin1_General_CP1253 | SQL_Romanian_CP1250 |
| SQL_EBCDIC037_CP1 | SQL_Latin1_General_CP1254 | SQL_Scandinavian_CP850 |
| SQL_EBCDIC273_CP1 | SQL_Latin1_General_CP1255 | SQL_Scandinavian_Pref_CP850 |
| SQL_EBCDIC277_CP1 | SQL_Latin1_General_CP1256 | SQL_Slovak_CP1250 |
| SQL_EBCDIC278_CP1 | SQL_Latin1_General_CP1257 | SQL_Slovenian_CP1250 |
| SQL_EBCDIC280_CP1 | SQL_Latin1_General_CP437 | SQL_SwedishPhone_Pref_CP1 |
| SQL_EBCDIC284_CP1 | SQL_Latin1_General_CP850 | SQL_SwedishStd_Pref_CP1 |
| SQL_EBCDIC285_CP1 | SQL_Latin1_General_Pref_CP1 | SQL_Ukrainian_CP1251 |
| SQL_AltDiction_CP1253 | SQL_Hungarian_CP1250 | |
| SQL_Latin1_General_Pref_CP850 |
照合順序に関する実際の情報を取得するには、COLLATIONPROPERTY 関数を使用します。前述した CodePage 値に加え、LCID などのその他の情報を渡すと、Windows ロケール ID が返されます (SQL 照合順序の場合は Null が返されます)。Windows ComparisonStyle も指定できます (バイナリ照合順序および SQL 照合順序の場合は Null が返されます)。この情報を使用すれば、Windows のすべての照合順序について、Windows 2000 の文字列正規化と SQL Server 2000 のそれが実際に対応しているかどうかを検証できます。
使用可能なすべての照合順序を取得するには、次のように fn_helpcollations() 関数を使用します。
SELECT * FROM ::fn_helpcollations()
このクエリは、SQL Server 2000 の 753 の行を返します。サービス パックまたは今後のバージョンに追加されない限り、新しい照合順序を追加することはできません。
照合順序によるデータの並べ替え
照合順序によって、Unicode データが実際にどのように処理されるのかを簡単に説明しておきましょう。どのような場合でも、Unicode 列に指定されている SQL Server の各照合順序は、定義されているすべての Unicode 文字を並べ替えます。データの並べ替えにはさまざまな方法があるので、照合順序の種類も多岐にわたります。その一例がグルジア語 (モダン) の並べ替えです。グルジア語 (トラディショナル) ではすべての文字が決まった順序で並べ替えられますが、グルジア語 (モダン) では、次のような使用頻度の低い文字は最後に配置されます。
HE :
.gif)
HEI :
.gif)
WE :
.gif)
HAR :
.gif)
したがって、図 4 と図 5 に示すように、グルジア語アルファベットには 2 種類の並べ替え方法があります。
.gif)
図 4. グルジア語 (トラディショナル) によるアルファベットの並べ替え
.gif)
図 5. グルジア語 (モダン) によるアルファベットの並べ替え
ただし、ほかのすべての Unicode データは、Latin1_General 照合の同じ並べ替え順に基づいて並べ替えられることには変わりありません。Georgian_Modern_Sort 照合順序だけが例外であり、ほかのすべての照合順序はグルジア語をトラディショナル方式で並べ替えます。ほかの照合順序についても同じルールが適用され、例外的な場合のみ使用する照合順序が変更されます。
照合順序の指定レベル
SQL Server 2000 では、次のレベルで照合順序を指定できます。
サーバー レベル
データベース レベル
列レベル
式
サーバー レベルの照合順序
これまで照合順序は必ずサーバー レベルで指定しており、多くの場合、設定を必要とする唯一の照合順序でした。データベースの作成時にデータベース レベルの照合順序を明示的に設定しない限り、サーバー上のすべてのデータベースには既定値としてサーバー レベルの照合順序が適用されます。しかし実際には、データベースに必ず照合順序が割り当てられるので、データベースの作成時を除き、サーバー レベルの照合順序が参照されることはありません。
Program Files\Microsoft SQL Server\80\Tools\BINN ディレクトリに格納されている Rebuild Master ユーティリティ (RebuildM.exe) を使用すると、セットアップ プログラムを再実行しなくてもこの照合順序を変更することができます。詳細については、SQL Server 2000 の SQL Server Books Online の「Master 再構築ユーティリティ」を参照してください。
次のように Transact-SQL の SERVERPROPERTY 関数を使用して、サーバーに照合順序を問い合わせることもできます。
SELECT CONVERT(char, SERVERPROPERTY('collation'))
データベース レベルの照合順序
データベース レベルで設定されている並べ替え順に応じて、データベースごとに異なる照合順序を指定できます。次の図 (図 6) は、SQL Server Enterprise Manager での照合順序の設定方法を示しています。
.gif)
図 6. Enterprise Manager を使用した照合順序の設定
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
さらに、ALTER DATABASE ステートメントを使用すると、既存のデータベースの照合順序を変更することもできます (SQL Server Enterprise Manager では変更できません)。たとえば、次のステートメントは、製品データベースの照合順序を Czech_CS_AS (大文字/小文字およびアクセントを区別する) から Czech_CI_AI (大文字/小文字およびアクセントを区別しない) に変更します。
ALTER DATABASE Products
COLLATE Czech_CI_AI
データベースの照合順序を変更する際の注意点
データベースの照合順序を変更するには、次のすべての条件を満たしていなければなりません。
ほかのすべてのユーザーがそのデータベースを使用できない状態であること。
スキーマ バインド オブジェクトがそのデータベース照合順序を参照しないこと。対象となるスキーマ バインド オブジェクトは次のとおりです。
SCHEMABINDING で作成されたユーザー定義関数とビュー
計算列
CHECK 制約
既定のデータベース照合順序を継承する照合を使用している文字列を含むテーブルを返すテーブル操作関数
データベース レベルの照合順序を変更した結果、システム名が重複しないこと。たとえば、French_CI_AS (大文字/小文字を区別しない) から French_CS_AS (大文字/小文字を区別する) に照合を変更するとします。以前のバージョンの SQL Server の照合順序では、Table1 および TABLE1 という名前の付いた 2 つのテーブルが存在していても問題ありません。しかし、SQL Server 2000 ではテーブル名が重複していると見なされます。重複のチェック対象となるオブジェクトは次のとおりです。
オブジェクト名 (プロシージャ、テーブル、トリガ、ビュー)
スキーマ名 (グループ、ロール、ユーザー)
スカラタイプ名 (システム、ユーザー定義)
フルテキスト カタログ名
オブジェクト内の列またはパラメータの名前
テーブル内のインデックスの名前
これらは決して非現実的な制約ではありません。これらの制約があることによって、データやデータベースが壊れるのを防ぐことができます。場合によっては、まだ十分とは言えないかもしれません。たとえば、text、varchar、または char フィールドにデータが入力されており、その列に明示的な照合順序が設定されていないとします。ここでデータベースの照合順序を変更すると、データのエンコーディングの解釈方法が変更され、その結果、(すべてのコード ページに含まれている) ASCII 範囲以外の文字が壊れてしまいます。このような事態に陥らないためにも、Unicode 型でないテキスト データ列がデータベースに含まれている場合、それらの列に明示的な照合順序が設定されていない限り (この後の「列レベルの照合順序」を参照)、データベースの照合順序を変更しないようにしてください。
次のように、Transact-SQL の DATABASEPROPERTYEX 関数を使用してデータベースの照合順序を確認することもできます。
SELECT CONVERT(char, DATABASEPROPERTYEX('pubs', 'collation'))
列レベルの照合順序
SQL Server 2000 では、特定の列の文字列の照合順序を変更できます。この機能は、大文字と小文字を区別するパスワード列などで使用すると便利です。また、列によって言語が異なる場合にもこの機能が役立ちます。たとえば、ギリシャを拠点とする企業の場合、世界各国の顧客に対応できるよう、顧客名は Latin1_General を使用した Unicode 形式で格納します。製品名はギリシャ語なので Greek 照合順序を使用します。次の図 (図 7) は、SQL Server Enterprise Manager を使用し、テーブル設計時に照合順序を指定する方法を示しています。
.gif)
図 7. テーブル設計時に Enterprise Manager を使用して照合順序を指定
[...] ボタン (参照ボタン) をクリックすると、次の図のようなダイアログ ボックス (図 8) が表示されます。ここで照合順序を選択することができます。
.gif)
図 8. 照合順序を指定するためのダイアログ ボックス
Transact-SQL を使用して、照合順序を列レベルで設定することもできます。方法は、CREATE TABLE ステートメントの列定義に COLLATE 句を追加するだけです。次の例では、ジョブの説明 (job_desc) に 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 列を除く) で変更できます。ただし、ntext 列の照合順序は SQL Server Enterprise Manager で変更できます。この場合、SQL Server Enterprise Manager はまず temp テーブルを作成します。次に、その temp テーブルにデータを移動し、古いテーブルを削除します。さらに、新しい照合順序が設定された新しいテーブルを作成し、そのテーブルにデータをコピーします。
式内で指定された照合順序
さまざまな国のユーザーに、その地域に適した並べ替え方法でデータを表示しなければならない場合も頻繁に発生します。SQL Server 2000 では、式の中で照合順序を指定することができます。この高度な新機能を使用すれば、言語ごとに ORDER BY 句を指定し、最適な方法で並べ替え行うことができます。
たとえば、次のクエリは、顧客テーブルを "姓" で並べ替え、次に "名" で並べ替えます (並べ替え順として Lithuanian (リトアニア語) を使用したのは、文字 "Y" の並べ替えルールに特徴があり、照合順序の違いを示すのに適しているためです)。
SELECT
FROM
tblCustomers
ORDER BY
LastName COLLATE Lithuanian_AI_CI,
FirstName COLLATE Lithuanian_AI_CI
SQL Server 2000 の SQL Server Books Online には、次のような一般的な比較例も示されています。
SELECT
FROM
Table1
WHERE
Field1 = Field2 COLLATE Turkish_ci_ai
この場合、Table1 に列レベルの照合順序が明示的に設定されていないとすると、2 つの列が Turkish (トルコ語) 並べ替え順で比較されます。詳細については、後の「照合順序の優先ルール」を参照してください。
COLLATE キーワード
COLLATE キーワードの構文は次のとおりです。
COLLATE [<Windows_Collation_name>|<SQL_Collation_Name]
照合順序名の選択は難しい作業です。このキーワードは、データベース レベル、列レベル、または式内で指定できます。一般に、フィールドが Unicode 型 (ntext、nvarchar、nchar) でない場合は、最初に照合順序をコード ページに変換しておきます。
照合順序には次の 2 種類があります。
Windows の照合順序
Windows で定義されている照合順序です。大文字/小文字、アクセント、ひらがな/カタカナ、全角/半角を区別するかどうかを指定できます。バイナリ順の定義も可能です。
SQL の照合順序
以前のバージョンとの互換性を維持するため、SQL Server で定義されている照合順序です。並べ替えに関するすべてのオプションを指定できるわけではありません。
通常は、できるだけ Windows の照合順序を使用してください。次の図 (図 9) は、並べ替えルールがどのように影響するかを示しています。この例では、pubs データベースを使用しています。Y が I と J の間にくるか、X と Z の間にくるかは、Lithuanian (リトアニア語) 照合順序を使用するかどうかによって異なります。このように、照合順序はクエリ結果の並べ替えに影響を与えます。
.gif)
図 9. 並べ替えに対する照合順序の影響
照合順序の優先ルール
SQL Server 2000 では、サーバー レベル、データベース レベル、列レベル、および式内で照合順序を指定できます。これらはどのように作用するのでしょうか?
これらの照合順序は明確なルールに基づいて適用されます。ただ、最初は少し分かりにくいかもしれません。次の表は、比較対象 A と B がどのように作用するかを示しています。
| 明示的 B | 暗黙的 B | 既定値 | 照合順序なし | |
| 明示的 A | 実行時エラー | 明示的 A | 明示的 A | 明示的 A |
| 暗黙的 A | 明示的 B | 照合順序なし | 暗黙的 A | 照合順序なし |
| 既定値 | 明示的 B | 暗黙的 B | 既定値 | 照合順序なし |
| 照合順序なし | 明示的 B | 照合順序なし | 照合順序なし | 照合順序なし |
上の表で使用されている用語の定義は次のとおりです。
明示的 A/明示的 B
式で明示的に定義されている照合順序。
暗黙的 A/暗黙的 B
列レベルで定義されている照合順序。
既定値
データベース レベルで定義されている照合順序。
照合順序なし
2 つの演算子が競合している状態。照合順序を使用しないで式が処理されます。
この表から分かるように、SQL Server が式を処理できないのは、互いに競合する 2 種類の照合順序を明示的に指定した場合と、比較対象の 2 つの項目に共通する要素がない場合だけです。これらは決して制約ではなく、理にかなったルールと言えます。SQL Server が要求しているのは、比較のごく基本的な条件だけです。
たとえば、次の 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
このステートメントは、Greek (ギリシャ語) 照合順序 (大文字/小文字を区別しない、アクセントを区別する) を使用する列と、General Latin1 (汎用ラテン 1) 照合順序 (大文字/小文字を区別する、アクセントを区別する) を使用する列で構成されたテーブルを作成します。
次に、この 2 つの列を明示的に比較するクエリを実行したとします。
SELECT *
FROM TestTab
WHERE GreekCol = LatinCol
すると、次のようなエラーが返されます。
メッセージ 446、レベル 16、状態 9、サーバー V-MICHKA3、行 1
equal to 操作での照合順序の競合を解決できません。
これは、テキストの 2 つのセグメントにそれぞれ異なる照合順序が設定されているため、両者を比較できないことが原因です。ただし、次のように式内で COLLATE キーワードを明示的に使用すると、両者を比較できるようになります。
SELECT *
FROM TestTab
WHERE GreekCol = LatinCol COLLATE greek_ci_as
通常、LatinCol では大文字/小文字が区別されますが、この式では大文字/小文字を区別しないように指定しているので、大文字の "A" と小文字の "a" は同じと見なされます。
COLLATE キーワードの制約
COLLATE キーワードおよびその関連機能はいずれも非常に優れており、著者の見るところ、最新のエンタープライズ データベース製品の中でもこれに匹敵するものはありません。ただし、次に説明するようにいくつかの制約を伴います。これらすべての制約には回避策があります。この後の説明を参照し、何を直接実行でき、そうでない場合はどのような作業が必要になるのかを確認してください。
照合順序の一覧表示に関する問題
fn_helpcollations 関数 (前の「列レベルの照合順序」の図を参照) は、すべての種類の照合順序を返します。ただし、「データベース レベルの照合順序」で説明したダイアログ ボックスに示されているように、1 つのロケールだけ (アルバニア語など) が表示され、その他のフラグはオプションとして提供されています。したがって、この機能のユーザー インターフェイスを作成する場合は、多少の手直しが必要となります。
列レベルでの照合順序の定義に関する問題
データベースと列にそれぞれ異なる並べ替え順 (Latin1_General と Greek など) を指定する必要が生じるのはどのようなときでしょうか? それが絶対条件となるケースもありますが、通常、データベースのデータが 1 つの同じ照合順序を使用しない場合、それは多言語データであり、複数の照合順序に基づいて格納しなければなりません。それぞれにインデックスの付いた複数の照合順序を定義すれば、Greek 照合順序を指定することによってギリシャ語のデータにアクセスできます。また、このクエリをインデックス付き検索として実行することができます。
ここで問題となるのは、"クエリをインデックス付き検索として実行できる" という部分です。前の例では、クエリの ORDER BY 句で COLLATE 式を使用することによってこの機能を実現しました。しかし、これはインデックス付き並べ替えではないので、大規模なデータセットでは処理に時間がかかります。現在のところ、照合順序を列レベルで設定することに意味があるのは、列に格納するのが単一言語データでない場合、または複数の言語をそれぞれ異なる列に格納するため、データベースを非正規化する場合だけです。
LCID と照合順序
Windows はロケール ID (LCID) を使用して並べ替えを定義します。結果を書式設定するには、既に取得している LCID を使用します (このほか、1024 を指定して既定の LCID を使用する方法、または Microsoft Visual Basic® の書式設定関数を使用する方法があります)。たとえば、Web ベースの ASP アプリケーションで Microsoft Visual Basic Scripting Edition (VBScript) の SetLocal 関数を使用すると、日付/時刻、数値、通貨を目的のロケールの書式設定に変更することができます。ただし、この 2 つを関連付ける方法は用意されていません。照合順序から LCID を取得することは可能ですが、LCID から照合順序を取得することはできません。これは、LCID と照合順序が一対多の関係にあるためです。
これによって、どのような不都合がもたらされるのでしょうか? たとえば、さまざまな国のユーザーがアクセスして製品情報を参照する多言語 Web サイトを開設している場合を考えてみましょう。Session.LCID プロパティを使用して日付と通貨の値を書式設定できるよう、既に各ユーザーが使用しているブラウザの HTTP_ACCEPT_LANGUAGE 変数を LCID に割り当てているとします。ここで、ユーザーのロケールに基づいてデータを並べ替えることができれば、Web サイトの有用性がさらに向上します。
これを実現するには、独自のマッピング関数を作成する必要があります。SQL Server 2000 の SQL Server Books Online の「Windows 照合順序指定子」に記載されている変換表を参照してください。
ISO 文字列と照合順序
VBScript で次のスクリプトを使用すれば、HTTP_ACCEPT_LANGUAGE 変数を取得できます。
Dim stLang
stLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE")
ロケール情報の処理で多くの Web 開発者が使用する唯一の値であることから、VBScript の SetLocale 関数は LCID 値だけでなく、この値を直接受け取るように設計されています。つまり、この値を LCID に変換するための手順は必要ありません。しかし、SQL Server 2000 は "en-us" (English-United States) や "vi" (Vietnamese) などの文字列を受け付けません。前者を Latin1_General 照合順序にマップし、後者を Vietnamese 照合順序にマップするには、その処理をすべて自分で行う必要があります。
独自の照合順序の定義
SQL Server 2000 には多数の照合順序オプションが用意されていますが、それでも多くの開発者から "照合順序を自分で定義するにはどうすればよいのか" という質問が寄せられます。残念ながら、照合順序を自分で定義することはできません。Windows 2000 に照合順序が追加されない限り、SQL Server 2000 に新しい照合順序を追加のは不可能です。照合順序は、Unicode 規格で定義されているすべての文字の並べ替え順を指定するためのものなので、その作成を目的としたユーザー インターフェイスは用意されていません。
注 : SQL Server の新しい照合順序は、いずれも Windows の情報 (Windows の照合順序) が基盤となります。
サーバーとクライアント間の通信 (コード ページと照合順序に関する問題)
サーバーである 1 台のコンピュータ上で SQL Server のすべての処理を行い、SQL Server のツール (SQL クエリ アナライザや SQL Server Enterprise Manager など) だけを使用するというケースはほとんどありません。通常は、サーバーがほかの複数のサーバーまたはクライアントとやり取りし、場合によっては複数のデータ アクセス方式を使用します。ここでは、こうした環境における SQL Server 2000 の処理について説明します。この場合、SQL Server にアクセスする側がクライアントとなります。基本的に、クライアントには次の 2 種類があります。
Unicode クライアント : OLE DB、ODBC 3.7 以降
非 Unicode クライアント : ODBC 3.7 以前、DB-Library
非 Unicode データの処理で重要なのは、コード ページ間でデータを変換する方法、または ODBC 使用時に Unicode との間でデータを変換する方法です。SQLSetConnectAttr へ送信する際、SQL_COPT_SS_TRANSLATE 属性には次の 2 つの値を設定することができます。
SQL_XL_OFF
クライアントとサーバー間で文字データを交換する際、1 つのコード ページから別のコード ページへ文字が変換されません。
SQL_XL_ON
クライアントとサーバー間で文字データを交換する際、1 つのコード ページから別のコード ページへ文字が変換されます。この場合、サーバーにインストールされているコード ページとクライアントが使用しているコード ページが検出され、文字変換が自動的に行われます。
既定では、SQL_XL_ON 属性が設定されています。SQLServer オブジェクトの SQL-DMO TranslateChar メソッドを使用してこの属性を設定することもできます。通常、非 Unicode データを処理するときは、この既定値 (auto_translate をオンに設定) を使用します。
この後、クライアント/サーバー接続の種類とその問題点について説明します。
Unicode サーバーと Unicode クライアント
理想的な構成です。プロセス全体を通じて Unicode データを使用すれば、最高のパフォーマンスが得られると同時に、取得したデータが壊れる心配もありません。ADO と OLE DB の場合も同様です。
Unicode サーバーと 1 台または複数台の非 Unicode クライアント
この構成の場合、データの格納に関しては特に問題ありませんが、データをクライアントに送信し、そのデータをクライアント上で使用するときに大きな制約を受けます。いずれかの時点で、クライアントのコード ページを使用して Unicode データを変換しなければなりません。
データ層における制約の一例として、DB-Library を使用しているコンピュータから SQL Server 2000 データベースに接続する場合を考えてみましょう。DB-Library は、C アプリケーションから SQL Server へのアクセスを可能にする呼び出しレベルのインターフェイスです。しかし、SQL Server 6.5 以降大きなアップグレードは行われていないので、Unicode データを処理する上で、DB-Library クライアントはどうしても制約を受けることになります。使用できるデータは、1 つのコード ページ (システムの既定のコード ページ OEM) のデータです。ロケール情報についても、クライアント システムのロケール設定を適用するかどうかを選択できます。次の図 (図 10) に示すように、SQL Server クライアント ネットワーク ユーティリティの [DB-Library オプション] タブには、DB-Library による情報の変換方法を指定するためのオプションが 2 つ用意されています。既定では、これら両方のオプションが選択されています。
.gif)
図 10. [DB-Library オプション] の既定値
ほかのコード ページのデータは処理できないので、DB-Library がデータ層として意味をなすのは、SQL Server から取得したデータを処理するレガシ システムにおいてのみです。以前から使用している既存のアプリケーションを書き直さずに済むという利点はありますが、多言語データをサポートする必要がある場合はアプリケーションを書き直した方がよいでしょう。
非 Unicode クライアントのもう 1 つの例として、Microsoft Access 97 など、Unicode 対応でないプログラムがあります。Access データベースは SQL Server 2000 データベースへのリンクが可能ですが、いくつかの制約が伴います。たとえば、英語 (U.S.) のコンピュータから日本語のテーブル名を使用したデータベースへ接続した場合、ダイアログ ボックスにはそれらのテーブル名が疑問符として表示されます。次の図 (図 11) を参照してください。
.gif)
図 11. 疑問符に変換されたテーブル名 (Access 97)
理由は簡単です。Access 97 はバージョン 3.7 以前の ODBC を使用しているので、データは既定のシステム コード ページに基づいて Unicode から ANSI へ変換されます。最新バージョンの ODBC をインストールしたとしても、Access 97 の Jet 3.5 によって同じ変換結果となります。英語 (U.S.) のコンピュータのコード ページ 1252 には日本語の文字がないので、日本語のテーブル名は疑問符に変換されてしまいます。
これらのテーブルへ接続することはできません。接続しようとすると、図 12 のようなエラー メッセージが表示されます。
.gif)
図 12. Microsoft Access のエラー メッセージ
これもまた理由は簡単です。データが不適切なコード ページに変換され、疑問符に置き換えられてしまうと、それを元の状態に変換し直す方法はありません。Jet および ODBC は "dbo.????" という名前のテーブルに接続しようとしますが、このようなテーブル名は存在しないので当然失敗します。この問題は、コード ページ 1252 に含まれていないすべてのデータを処理する場合に発生します。
さらに、テーブルに格納されているデータ自体についても同様の問題が生じます。たとえば、テーブルに韓国語のデータが保存されている場合、非 Unicode クライアント (Access など) ではそれらのデータが疑問符として表示されます。図 13 を参照してください。
.gif)
図 13. 疑問符として表示されたデータ (非 Unicode クライアント データベース)
これら 3 種類 (DB-Library、ODBC、Jet 3.5) のクライアントでは、既定のシステム コード ページへの変換が可能だとしても、コンポーネントが Unicode を識別しなければこの種の多言語データを処理することはできません。これらのクライアントで使用できるのは、既定のシステム コード ページに含まれるデータだけです。
非 Unicode サーバーと Unicode クライアント
多言語データをサーバー上に格納することができないので、理想的な構成とは言えません。ただし、少なくともデータを正しく表示することは可能です。この構成は、前の構成例で説明したすべての制約を伴いますが、受け取ったデータが不適切な変換によって壊れる危険性はありません。一例として、SQL Server 2000 データベースが SQL Server 6.5 データベースにリンクしている構成が考えられます。SQL Server 6.5 を実行しているサーバーから受け取る情報はすべて有効ですが、コード ページにないデータは挿入されません。
非 Unicode サーバーと 非 Unicode クライアント
基本的に、常に 1 つのコード ページしか使用できないので、最も制約の多い構成です。
以前のバージョンの SQL Server の多言語データを変換する
すべてのユーザーが SQL Server 7.0 および SQL Server 2000 の Unicode 機能を使用して多言語データを処理しているわけではありません。これ以前に多言語データの処理を必要としていたユーザーは、独自のエンコーディング方法でデータを格納しています。このような場合は、一括コピー ユーティリティ (bcp) を使用して、データをバイナリ形式で保存します (変換はしません)。次に、コマンド ライン パラメータ -C を使用して適切なコード ページを指定し、再度一括コピーする必要があります。bcp ユーティリティの詳細については、後の「bcp ユーティリティを使用して多言語データを処理する」を参照してください。
Access 2000 の新しい ADP 形式
Microsoft Access 2000 には、Jet データベースではない新しいファイル形式 Access Data Project (ADP) が追加されました。これらのファイルは、SQL Server へのフロント エンドとして直接動作します。
ここでは ADP の機能について詳しく説明しませんが、重要な点を 2 つだけ挙げておきます。
SQL Server 2000 クライアントのツールをインストールしない限り、Access 2000 は SQL Server 2000 へアクセスできません。
Access 内から SQL Server のデータへアクセスするためのすべてのエントリ ポイント (フォーム、データ アクセス ページ、テーブル データシート ビュー、ADO) では、Access と SQL Server 間に COM という 1 つの層が存在します。データの意味はクライアント (この場合は ADP が置かれているコンピュータ) の地域設定に基づいて解釈されるので、日付/時刻値、数値、通貨値の入力に影響を与えることになります。SQL Server のルールの方が制限が緩い場合があるので、Access を使用するときはこの点に十分注意してください。詳細については、後の「COM のロケール干渉に対処する」を参照してください。
ユーザー インターフェイスの多言語データ
SQL Server には多くの管理ツールが備わっています。多言語データをサポートするため、SQL Server 2000 ではこれらのツールがさらに強化されました。
全般的な UI の変更 (Unicode のサポート)
SQL Server Enterprise Manager は、現在の既定のコード ページまたはサーバーのコード ページに含まれているテーブル名を適切に処理します。また、Windows のフォントのリンク テクノロジ利用し、必要に応じてほかのフォントから文字を "借りる" こともできます (図 14 を参照)。
.gif)
図 14. フォントのリンク テクノロジの例
ただし、この図が示しているように、フォントのリンクを使用したとしてもすべての文字を表示できるわけではありません。アルメニア語、グルジア語、ヒンディー語など、Windows が高度なフォント リンク情報を保持していない言語も多数あります。さらに、アゼルバイジャン語 (キリル) など、あまり一般的でない文字が含まれている場合も、その数文字だけが表示されないこともあります。
次の 3 つの点に注意してください。
テーブル名で使用されている文字がフォントに含まれておらず、しかもフォントのリンクを適用できない場合、画面上には壊れた文字が表示されません。上図のように、表示できない文字は四角形として表されます。
Windows 2000 を使用していない限り、SQL Server 2000 クライアント ツールは、複雑なスクリプトを表示するときにユニスクライブ テクノロジを使用しません。そのため、双方向言語 (前の図のヘブライ語、イディッシュ語、アラビア語、ペルシア語) では文字列が逆方向に表示されます。ただし、Windows 2000 および BIDI 対応のプラットフォームでは、これらの文字列が正しく表示されます。タイ語の単語分割など、その他の複雑な文字体系を表現する場合も同様の制約が見られます (Windows 2000 を除く)。
SQL Server Enterprise Manager が使用する "基本" フォントは、そのコンピュータのデスクトップ設定で定義されています。これを変更することはできません。
SQL クエリ アナライザのグリッドおよび SQL ペインに表示される多言語情報
SQL Server Enterprise Manager ではフォントを変更できません。ただし、SQL クエリ アナライザの [オプション] ダイアログ ボックスにある [フォント] タブ (図 15) では、ユーザー インターフェイスのさまざまな部分のフォントを明示的に変更できます。
.gif)
図 15. SQL Server 2000 クエリ アナライザの [フォント] タブ
フォントのリンク機能を使用すればほとんどの文字列を表示できるので、最初はその目的がよく分からないかもしれません。しかし、文字列に対応したフォントを単に探すためだけでなく、文字列を適切に表示する上で大きな役割を果たします。多くの場合、フォントの選択は有効に作用します。したがって、多言語データを正しく表示するにはこの機能が欠かせません。フォントのリンクによって文字を表示できない場合でも、この機能を使用すれば、四角形ではなく、正しい文字として表示することができます。
クエリ デザイナの書式に関する問題
基本的に、クエリ デザイナのグリッド ペインに入力する情報には、そのコンピュータの既定の地域設定が適用されます。また、CONVERT 関数を明示的に使用して、文字列を任意の書式で処理することも可能です。
地域の設定を使用する場合、設計上の制約がいくつかあります。
長いデータ形式は使用できません。
グリッド ペインには通貨記号を入力できません。ただし、US ドル記号 ($) は使用可能です。いずれの場合も、結果ペインでは、地域の設定で指定した通貨記号が使用されます。
地域の設定にかかわらず、マイナス記号は常に左側に表示されます。かっこで囲まれません。したがって、[地域のオプション] ダイアログ ボックスでどのように指定したとしても、-1 は -1 と表示され、1- や (1) とは表示されません。
クエリ デザイナのこれらの制約は、各国の言語をサポートするために設けられたものです。ロケールに固有のデータの使用を妨げるものではありません。
グリッド ペインに入力したすべての情報は、ロケールに依存しない形式に変換された状態で SQL ペインに表示されます。したがって、ドイツ語 (標準) コンピュータで「03.09.65」と入力すると、{ ts ' 1965-09-03 00:00:00 } という形式に変換されます。SQL ペインにデータを直接入力する場合は、必ずこの形式を使用してください。または、CONVERT を明示的に呼び出します。
並べ替え順
結果ペインに表示されるデータの並べ替えは、地域の設定の影響を受けません。照合順序 (前の「SQL Server 2000 の照合順序」を参照) に基づいて ORDER BY 句が解釈されます。
2 バイト (DBCS) 文字
リテラル、データベース オブジェクト名、別名、パラメータ名、パラメータ マーカを入力するときは DBCS 文字を使用できます。ただし、関数名や SQL キーワードなど、SQL 言語の要素では DBCS 文字を使用できません。たとえば、キーワード SELECT を入力するときは半角文字を使用します。次のような日本語の全角文字は使用できません。.gif)
SQL Server のデータにアクセスする (データ アクセス方式)
SQL Server のデータへどのようにアクセスするかは非常に重要な問題です。データ アクセス方式にはさまざまな種類があるので、各方式における多言語データの処理方法を理解しておく必要があります。ここでは、いくつかのデータ アクセス方式について説明します。
OLE DB
OLE DB は、Microsoft Data Access Components (MDAC) の中心となるコンポーネントです。SQL Server 7.0 では MDAC 2.1、SQL Server 2000 では MDAC 2.6 が使用されています。OLE DB は COM を基本としているので、すべての文字列は Unicode BSTR として処理されます (Windows 2000 では UTF-16、その他すべてのオペレーティング システムでは UCS-2)。SQL Server の場合、プロバイダは Microsoft OLE DB Provider for SQL Server (SQLOLEDB) です。この方式は、実際のデータの照合順序を使用してデータを Unicode に変換します。データ操作を最適化するには、プロセス全体を通じてデータを Unicode 形式で処理する必要があります。
ADO
Microsoft ActiveX® Data Object は、OLE DB のラッパーとして機能する Visual Basic およびスクリプト対応のインターフェイスです。COM コンポーネントでもあるので、Unicode のサポートが可能です。ADO と OLE DB を切り離し、両者間でデータを変換する方法はないので、問題があるとすれば、その原因は常に OLE DB 層にあります。
ODBC
ODBC が Unicode 層かどうかは、使用している ODBC のバージョンによって異なります。ODBC を使用する際の規則については、前の「サーバーとクライアント間の通信」を参照してください。
DB-Library
Unicode 対応の最新バージョンはありません。詳細については、前の「サーバーとクライアント間の通信」を参照してください。
SQL-DMO
SQL 分散管理オブジェクト (SQL-DMO) は、SQL Server 2000 データベースとレプリケーション管理をカプセル化した COM 層です。SQL-DMO は COM なので、ADO/OLE DB と同様の規則が適用されます。SQLServer2 オブジェクト、Database2 オブジェクト、Column2 オブジェクト、SystemDateType2 オブジェクト、UserDefinedDataType2 オブジェクトの Collation プロパティなど、前述した機能で使用できるプロパティも備わっています。
多言語の Transact-SQL
SQL ステートメントに多言語データが含まれている場合、そのデータをサーバーに正しく送信できるかどうかは次の 2 つの要素に左右されます。
SQL ステートメント自体のエンコーディング
SQL ステートメント内の文字列リテラルのエンコーディング
SQL ステートメント内の文字列リテラルのエンコーディング
SQL 文字列自体をエンコードした後、何らかの方法で文字列リテラルを処理しなければなりません。選択肢は 2 つあり、コンピュータの既定のコード ページの文字列を使用するか、Unicode 文字列を使用するかです。後者の場合、次のように、文字列の先頭に "n" (National) を追加します。
.gif)
"n" プレフィックスを付けないと、この文字列 (ヒンディー語のヒンディー文字) は "??????" に変換されます。データがシステムの既定のコード ページに含まれていない場合も、同様に変換されます。
警告 : 文字列リテラルおよびデータ型 (nchar、nvarchar、ntext) に "n" プレフィックスを付加して Unicode データを表すのは、SQL Server の場合だけです。ANSI-92 SQL 仕様でも National 文字データ型が定義されていますが、これらは Unicode を表しません。ANSI-99 SQL 仕様では、utext、uchar、uvarchar のように、"u" プレフィックスを追加して Unicode 型を表しています (SQL Server 2000 のリリース時にはこの仕様が完成していませんでした。Unicode のサポートについては今後さらに検討され、修正が加えられると思われます)。SQL Server 2000 ではこれらのデータ型を使用できません。ただし、ほかのサーバー データベース製品では使用できる場合もあります。詳細については、後の「ほかのデータベース製品とやり取りする」を参照してください。
SQL 文字列のエンコーディング
SQL 文字列が Unicode 形式の場合 (ADO を使用している SQL 文字列など)、すべての種類の文字をエンコードすることができます。SQL 文字列が Unicode 形式でない場合 (非 Unicode バッチ ファイルや .SQL ファイルの文字列など)、いずれかの時点でデータを変換しなければなりません。その際、通常は、変換を実行するコンピュータの既定のシステム コード ページを使用します。入念に計画しておかないと、多言語アプリケーションではこれがトラブルの大きな原因となります。
Unicode 形式でない文字列リテラルに n プレフィックスを付加すると、その文字列は、データベースの既定のコード ページを使用して Unicode に変換されます。多言語データを処理するときは、Unicode データ型と Unicode 文字列リテラルを使用するのが理想的です。
文字列操作関数
Transact-SQL には、多言語処理に大きく影響する文字列操作関数が組み込まれています。
ASCII
現在の既定のシステム コード ページを使用して、文字列の最初の文字のコード ポイントを返します。既定のシステム コード ページに対象の文字が含まれていない場合は、63 (疑問符のコード ポイント) を返します。この関数は、Visual Basic および VBScript の Asc() 関数と同じです。
CHAR
指定された ANSI コード ポイントに対応する文字を返します。つまり、ASCII 関数と逆の操作を行います。この関数は、Visual Basic および VBScript の Chr() 関数と同じです。コード ポイントが 0 ～ 255 の範囲にない場合は Null を返します。
NCHAR
CHAR 関数の Unicode バージョンです。指定された Unicode コード ポイントに対応する文字を返します。Visual Basic および VBScript の ChrW() 関数と同じです。
UNICODE
ASCII 関数の Unicode バージョンです。文字列の最初の文字の Unicode コード ポイントを返します。Visual Basic および VBScript の AscW() 関数と同じです。
前の例 (「日付/時刻型 : datetime、smalldatetime」を参照) では、NCHAR 関数を使用してヒジュラ暦の先頭に RLM (右から左マーク) を追加し、適切に書式設定されるようにしています。
SQL Server 2000 のロケール サポート
SQL Server 2000 は 33 種類の言語のロケールをサポートしています。Windows の NLS データベースのような完全なロケール サポートではありませんが、基本的な多数の機能を提供します。次の表はサポートされている言語の一覧です (各言語名は、日本語およびその国の言語で記載されています)。
SQL Server 2000 および Windows 2000 でサポートされている言語
| 日本語訳 | 母国語 |
| アラビア語 | Arabic |
| 英語 (U.K.) | British |
| ポルトガル語 (ブラジル) | Português - Brasil |
| ブルガリア語 | .gif) |
| 簡体字中国語 | .gif) |
| 繁体字中国語 | .gif) |
| クロアチア語 | hrvatski |
| チェコ語 | .gif) |
| デンマーク語 | Dansk |
| オランダ語 | Nederlands |
| 英語 | us_english |
| エストニア語 | eesti |
| フィンランド語 | Suomi |
| フランス語 | .gif) |
| ドイツ語 | Deutsch |
| ギリシャ語 | .gif) |
| ハンガリー語 | magyar |
| イタリア語 | Italiano |
| 日本語 | .gif) |
| 韓国語 | |
| ラトビア語 | Latviešu |
| リトアニア語 | lietuviø |
| ノルウェー語 | Norsk |
| ポーランド語 | polski |
| ポルトガル語 | Português |
| ルーマニア語 | românã |
| スロバキア語 | slovenèina |
| スロヴェニア語 | slovenski |
| スペイン語 | Español |
| スウェーデン語 | Svenska |
| タイ語 | .gif) |
| トルコ語 | .gif) |
| ロシア語 | .gif) |
これらの言語およびその情報を列挙するには、sp_helplanguage ストアド プロシージャを使用します。SQL Server のどのバージョンでも多くの言語に関する完全な情報が格納されますが、SQL Server のローカライズ版をインストールしていない限り、その国の言語に翻訳されたシステム メッセージは表示されません。
言語に関する情報は、sysmessages 内の syslanguages テーブルに格納されます (メッセージを除く)。
言語の設定
各 SQL Server には、データを書式設定したり、メッセージを表示するときに使用する既定の言語が割り当てられます。この情報は、それを作成したサーバーへログインするたびに使用されます。既定の言語は最初のセットアップ時に設定されますが、[SQL Server のプロパティ] ダイアログ ボックスの [サーバーの設定] タブ (図 16 を参照) を使用すればサーバー レベルで変更できます。
.gif)
図 16. SQL Server の言語を設定するためのダイアログ ボックス
また、sp_configure ストアド プロシージャを呼び出して、既定の言語を変更することもできます。次の例は、既定の言語をイタリア語に変更します。
sp_configure "language", 6
次の表は、使用可能な言語 ID (langid) を示しています (これらの言語 ID は、syslanguages テーブルからクエリによって取得できます)。
| langid | 言語名 |
| 0 | 英語 |
| 1 | ドイツ語 |
| 2 | フランス語 |
| 3 | 日本語 |
| 4 | デンマーク語 |
| 5 | スペイン語 |
| 6 | イタリア語 |
| 7 | オランダ語 |
| 8 | ノルウェー語 |
| 9 | ポルトガル語 |
| 10 | フィンランド語 |
| 11 | スウェーデン語 |
| 12 | チェコ語 |
| 13 | ハンガリー語 |
| 14 | ポーランド語 |
| 15 | ルーマニア語 |
| 16 | クロアチア語 |
| 17 | スロバキア語 |
| 18 | スロヴェニア語 |
| 19 | ギリシャ語 |
| 20 | ブルガリア語 |
| 21 | ロシア語 |
| 22 | トルコ語 |
| 23 | 英語 (U.K.) |
| 24 | エストニア語 |
| 25 | ラトビア語 |
| 26 | リトアニア語 |
| 27 | ポルトガル語 (ブラジル) |
| 28 | 繁体字中国語 |
| 29 | 韓国語 |
| 30 | 簡体字中国語 |
| 31 | アラビア語 |
| 32 | タイ語 |
既定の言語設定をログイン単位で変更するには、sp_addlogin ストアド プロシージャ、または [SQL Server ログインのプロパティ] ダイアログ ボックス (図 17) を使用します。
.gif)
図 17. [SQL Server ログインのプロパティ] ダイアログ ボックス
言語設定をセッション レベルで変更するには、次のように SET LANGUAGE ステートメントを使用します。
.gif)
文字列を Unicode として渡す場合は、文字列の先頭に "n" を追加してください。これによって、サーバーの既定のシステム コード ページを使用して変換する際のトラブルを防ぐことができます。
SET LANGUAGE 以外では、言語設定を指定する方法はデータ アクセス方式によって異なります。
ADO では、プロバイダ固有の言語キーワードを ConnectionString に指定します。
OLE DB では、プロバイダ固有の SSPROP_INIT_CURRENTLANGUAGE プロパティを設定します。
ODBC では、データ ソース定義、または接続文字列の LANGUAGE キーワードで言語を指定します。
DB-Library では、dblogin を使用して LOGINREC を割り当て、次に DBSETNATLANG を使用して言語設定を指定します。
サーバー、ログイン、セッションのどのレベルで指定されているかにかかわらず、言語設定は次の項目に影響を与えます。
メッセージ
日付/時刻
週の最初の曜日
通貨および通貨記号
月と曜日の表記方法および月の省略名
メッセージ
SQL Server 2000 では、システム エラーおよびメッセージが各国の言語で表示されます。これらのメッセージは、master データベースの sysmessages テーブルに格納されています。SQL Server 2000 のローカライズ版をインストールすると、そのローカライズ版の言語に合わせてシステム メッセージが変換されます。既定では、英語 (U.S.) でメッセージが表示されます。Set Language を使用すれば、サーバー セッションの言語を指定することができます。既定では、インストールしたローカライズ版の言語が適用されます。SQL Server がメッセージを送信するとき、sysmessages テーブルの msglangid 列のいずれかの言語 ID と language ID Set が一致すれば、ローカライズされたメッセージが使用されます。これらの ID は 10 進数で表され、メッセージのロケール ID (LCID) に対応しています。同じ LCID を持つメッセージが sysmessages テーブルにない場合、英語 (U.S.) のメッセージが送信されます。
sp_addmessage システム ストアド プロシージャの @lang パラメータを使用すれば、言語に固有のユーザー定義メッセージを sysmessages テーブルに追加できます (エラー番号は、50,000 より大きい数値を使用してください)。@lang には、メッセージを表示する言語 (LCID に割り当てられている別名) を指定します。
サーバー上には複数の言語によるシステム エラー文字列およびメッセージがインストールされるので、どの言語のメッセージを sysmessages テーブルに書き込むかを指定します。言語を指定しない場合は、サーバー セッションの既定の言語が適用されます。サポートされている言語の定義は、master.dbo.syslanguages に格納されます。複数言語の sysmessages をインストールする必要がある場合は、製品サポート サービスにお問い合わせください。
日付/時刻
日付の省略形式 (mdy、dmy、または ymd) を指定できます。SET DATEFORMAT 設定を使用すれば日付の表示形式を接続レベルで変更できますが、言語ごとに適切な既定値が設定されています。既定値を取得するには、sp_helplanguage ストアド プロシージャを使用します。この値は dateformat 列に格納されています。
週の最初の曜日
週の最初の曜日はロケールの種類によって異なります。syslanguages テーブルには 33 種類の言語が格納されており、それぞれ 1 (月曜) ～ 7 (日曜) のいずれかの値が割り当てられています。この情報を取得するには、sp_helplanguage ストアド プロシージャを使用します。この値は datefirst 列に格納されています。
通貨および通貨記号
money 型および smallmoney 型の列には通貨記号を入力できます。必ずしも、[地域のオプション] ダイアログ ボックスで指定されている通貨記号を使用する必要はありません。次のいずれかの文字を使用できます。
| 通貨記号 | 通貨 | Unicode (16 進数) |
| $ | U.S. ドル | 0024 |
.gif) |
イギリス ポンド | 00A3 |
.gif) |
(ユニバーサル) 通貨記号 | 00A4 |
.gif) |
円 | 00A5 |
.gif) |
ベンガル ルピー | 09F2 |
.gif) |
ベンガル ルピー | 09F3 |
.gif) |
タイ バーツ | 03EF |
.gif) |
コローン | 20A1 |
.gif) |
クルゼイロ | 20A2 |
.gif) |
フランス フラン | 20A3 |
.gif) |
リラ | 20A4 |
.gif) |
ナイラ | 20A6 |
.gif) |
ペセタ | 20A7 |
.gif) |
ルピー | 20A8 |
.gif) |
ウォン | 20A9 |
.gif) |
シェケル (新) | 20AA |
.gif) |
ドン | 20AB |
.gif) |
ユーロ | 20AC |
SQL Server 2000 Books Online ではユーロ記号の 16 進数値が 20A0 となっていますが、20AC の誤りです。20A0 によって表される文字 (.gif)
) は欧州通貨 (ECU) 記号です。これはユーロ記号ではないので、使用しないように注意してください。金額を表す値で を使用するとエラーが発生します。
月と曜日の表記方法および月の省略名
月および曜日の名前は syslanguages テーブルに格納されています。これらを取得するには sp_helplanguage ストアド プロシージャを使用します。各列の情報は次のとおりです。
months
1 月 ～ 12 月までの月名がカンマで区切って表示されます。
shortmonths
1 月 ～ 12 月までの省略名がカンマで区切って表示されます。
days
月曜 ～ 日曜まで曜日がカンマで区切って表示されます。
COM のロケール干渉に対処する
SQL Server には、日付/時刻や通貨の値を処理するための非常に高度な機能が備わっていますが、ADO などの COM サービスを使用してサーバーにアクセスした場合、これらの機能が十分に働きません。たとえば、いずれかの通貨記号 (前の表を参照) に続けて数値を入力しても、Visual Basic はそれを通貨値として認識しません。また、文字列内の日付/時刻値が正しく処理されない場合もあります。
こうした状況に対処するには、文字列から日付/時刻または通貨値への変換がどこで行われるのかを確認する必要があります。変換がクライアント側で行われるのか、サーバー側で行われるのかが分かれば、対処方法を特定できます。
このようなクライアントの一例として Access 2000 ADP があります (前の「Access 2000 の新しい ADP 形式」を参照)。Access は OLE DB を介して動作するので、Access 2000 でのすべての操作は、クライアント コンピュータの地域の設定に基づいた COM ルールによって管理されます。
注 : Microsoft OLE DB Provider for SQL Server などの OLE DB プロバイダは、COM の有効な日付を SQL Server の日付へ、SQL Server の日付を COM の日付へ正しく変換します。ただし、クライアント側のロケールを変更した場合はこの機能がうまく働かないので、文字列内に日付の書式を設定するのはできるだけ避けてください。
データ変換サービス
多言語データを処理する場合、DTS インポート/エクスポート ウィザード (図 18) のユーザー インターフェイスでいくつかの問題が発生します。
.gif)
図 18. DTS インポート/エクスポート ウィザード
このウィザードはさまざまな種類のデータを処理するためのインターフェイスを備えていますが、SQL Server Enterprise Manager や SQL クエリ アナライザとは異なり (前の「ユーザー インターフェイスの多言語データ」を参照)、データを表示を伴う一部のダイアログ ボックスは完全な Unicode 対応ではありません。そのため、ウィザード画面にデータが正しく表示されない場合があります。ただし、データ転送は正常に実行されます。DTS 操作の信頼性と安定性は、こうした UI の制約によって影響を受けません。ほとんどの場合、制約を受けるのはデータを画面上で確認できないという点だけです。図 19 のように、表示できないデータは四角形として表されます。
.gif)
図 19. DTS インポート/エクスポート ウィザードの表示例
これは、簡体字中国語のデータが保存された Unicode テキスト ファイルです。インポート先が Unicode のテキスト列であるか、簡体字中国語のテキスト列であるかにかかわらず、インポートしたデータは正しく処理されます。
ただし、テキスト ファイルで使用されているコード ページがシステムの既定のコード ページと一致しない場合、このウィザードはデータを正しく読み取ることができません (図 20 を参照)。これは、決して特別なケースではないことに注意してください。メモ帳やワードパッドなど多くのプログラムには、決まったコード ページを使用していないファイルを読み取るための機能が備わっていません。
.gif)
図 20. DTS インポート/エクスポート ウィザードによって正しくインポートされないファイル
日本語のコンピュータでは、この韓国語ファイルを正しくインポートすることができません。また、このウィザードでは、インポート時にコード ページを指定することができません (データを正しく表示することも、正しくインポートすることもできないのはそのためです)。ほかの多くのケースと同様、この場合の対応策もいたって明白です。多言語データを処理するときは Unicode を使用してください。
DTS での変換時に情報をエンコードするには、"変換元のコード ページを使用する"、"変換先のコード ページを使用する"、"照合順序を使用する" という 3 つの方法があります。
最適な結果が得られるのは "照合順序を使用" した場合です。SQL-DMO と DTS デザイナでは、この方法が既定値として設定されています (DTS インポート/エクスポート ウィザードでは既定値として設定されていませんが、簡単に設定できます)。照合順序を使用するには、変換元と変換先が両方とも SQL Server 2000 データベースでなければなりませんが、各列の照合情報に基づいて最適な変換方法が決定されます。
ほかの 2 つの変換方法は、変換元サーバーまたは変換先サーバーのコード ページに基づいて変換方法が決定されるので、柔軟性に欠けます。これら 2 つの変換方法では、サーバーのコード ページ設定しか使用できません。マルチインスタンス サーバーの照合順序は考慮されるものの、サーバーと異なるデータベース照合順序は使用できません。
DTS には、SQL Server のインスタンスの NLS 情報を使用して文字列やその他のデータ (日付/時刻以外) を変換する高度な機能も備わっています。日付/時刻データが文字列として格納されている場合、この機能を使用すれば、意図したとおりにデータをインポートすることができます。必ずしも SQL Server 2000 と同じ数だけのデータ形式を使用できるとは限らないので、この機能は非常に重要です。DTS は、限られた数の形式と SQL Server の機能との重要な橋渡し役となります。
そのほか DTS では、SQL Server 7.0 の非 Unicode 列から SQL Server 2000 の非 Unicode 列へデータを移動する場合や、SQL Server 2000 の列の照合順序を SQL Server 7.0 で簡単に表現できない場合にも問題が発生します (SQL Server 2000 から SQL Server 7.0 への変換時にも同様の問題が発生します)。このような場合、SQL Server 7.0 ではサーバーの既定のコード ページが使用されます。ここでもやはり、Unicode データ型を使用することによってこうした問題を防ぐことができます。
データを変換するのではなく、DTS を使用してデータをコピーする場合は次の 3 つのケースがあります。
OLE DB プロバイダの列
データが直接コピーされるので、2 つの列のデータが同じコード ページを使用していない場合に問題が発生します。コピー元の列とコピー先の列のデータが同じコード ページを使用している場合は便利ですが、両者のコード ページが異なる場合は使用できません。
NCHAR から CHAR
サーバーのコード ページを使用して、データが Unicode から変換されます。
CHAR から NCHAR
コピー元サーバーのコード ページを使用して、データが Unicode へ変換されます。
DTS でのデータ変換に関するまとめ
最初に強調しておきたいのは、変換元と変換先が Unicode であれば、どのようなケースにでも対応できるという点です。この事実だけはよく覚えておいてください。問題が発生するのは、次のような状況で非 Unicode データを使用する場合だけです。
変換先テーブルを作成する
SQL Server 7.0 から SQL Server 2000 に変換する場合、変換先サーバーのコード ページと変換先データベースのコード ページが一致しないと、その変換は失敗します。
SQL Server 2000 から SQL Server 7.0 に変換する場合、変換元の列の照合順序と変換元サーバーのコード ページが一致しないと、その変換は失敗します。
SQL Server 2000 から SQL Server 2000 に変換する場合、[照合順序を使用] チェック ボックスがオンになっていないとその変換は失敗します。それ以外の場合、データは失われません。
変換先テーブルが既に存在する
SQL Server 7.0 から SQL Server 2000 に変換する場合、変換先サーバーのコード ページと変換先の列のコード ページが一致しないと、その変換は失敗します。
SQL Server 2000 から SQL Server 7.0 に変換する場合、変換元の列の照合順序が変換元サーバーのコード ページと一致しないと、その変換は失敗します。
SQL Server 2000 から SQL Server 2000 に変換する場合、次のいずれかの条件を満たしているとその変換は成功します。
変換元のコード ページと変換先のコード ページが一致しており、[照合順序を使用] チェック ボックスがオンになっている。
変換先の列のコード ページと変換先サーバーのコード ページが一致しており、[照合順序を使用] チェック ボックスがオフになっている。
[照合順序を使用] チェック ボックスがオンの場合、データはそのまま転送されます。[照合順序を使用] チェック ボックスがオフの場合、データは変換元サーバーのコード ページに変換され、その後、変換先の列のコード ページに変換されます。
列のデータをコピーする
char から char へコピーする場合、データはそのまま転送されます。コピー元とコピー先のコード ページが一致しない場合、そのコピー操作は失敗します。
char から Unicode へコピーする場合、コピー元のデータがコンピュータのコード ページに変換され、その後で Unicode に変換されます。ただし、コピー元データがそのコード ページに存在しない場合、そのコピー操作は失敗します。
Unicode を char にコピーする場合、コピー先のコード ページにかかわらず、データはコンピュータのコード ページに変換されます。コピー先の列のコード ページとコンピュータのコード ページが一致しない場合、そのコピー操作は失敗します。
Unicode から Unicode への移動は変換を必要としないので、処理に失敗したり、データが壊れる危険性はまったくありません。したがって、多言語データの処理に適しています。
bcp ユーティリティを使用して多言語データを処理する
特定のコード ページに対してデータのインポートやエクスポートを行う場合も、bcp ユーティリティを使用できます。このユーティリティでは、データを損なわずに変換するため、次のフラグを設定できます。
| フラグ | 意味 | 説明および注意 |
| -Cxxx | コード ページ指定子 | xxx には、コード ページ、ANSI、OEM、または RAW を指定します。RAW を指定すると、データが変換されずに直接コピーされます。最も高速に処理できるオプションです。 |
| -N | Unicode ネイティブ形式を使用 | 文字以外のすべてのデータではネイティブ (データベース) データ型が使用され、文字データでは Unicode 形式が使用されます。 |
| -w | Unicode 文字形式を使用 | すべての列で Unicode 文字データ形式が使用されます。 |
フォーマット ファイルを使用し、照合順序を列レベルで指定することもできます (bcp に -C、-N、または -w を指定しないと、インポートやエクスポートを行う前に、各列、照合順序、およびコード ページに関する情報が取得されます)。この場合、フォーマット ファイルを保存するよう要求されます。次の例を参照してください (pubs データベースの authors テーブル)。
8.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 ""
使用可能なデータ型は次の表のとおりです。照合順序は、各列に指定されている既定値です。データベースまたはサーバーの照合順序を継承している場合もあります。
| データ型 | 正式名 |
| c | Char |
| T | Text |
| i | Int |
| s | Smallint |
| t | Tinyint |
| f | Float |
| m | Money |
| b | Bit |
| d | Datetime |
| x | Binary |
| I | Image |
| D | Smalldatetime |
| r | Real |
| M | Smallmoney |
| n | Numeric |
| e | Decimal |
| w | Nchar |
| W | Ntext |
| u | Uniqueidentifier |
この表には varchar 型と nvarchar 型が記載されていません。bcp ユーティリティでは、必要に応じて char 型または nchar 型を使用してください。
bcp は、-R フラグ ("Regional Enable") もサポートしています。このフラグは、ODBC の [システムで設定した地域情報を使用する] オプションと同じ効果があり (前の「サーバーとクライアント間の通信」を参照)、非テキスト フィールドに格納された日付/時刻、数値、通貨データの解釈方法を決定します。
Microsoft Search サービスと FTS
Microsoft Search サービスは多くの Microsoft 製品で使用されており、SQL Server 2000 と Exchange 2000 もこのサービスを使用します。エンジンは Index Server で使用されているエンジンと同じです。将来は、ほかの多くの製品にもこの機能が採り入れられる予定です。Microsoft Search サービスの最も特徴的な機能は、言語に対応した語形変化 (動詞の活用) と単語区切り機能です。たとえば、フランス語の l'unique などの単語にインデックスを付けることができます。Microsoft Search サービスがサポートしている言語は次のとおりです。
オランダ語
英語 (U.K.)
英語 (U.S.)
フランス語
ドイツ語
イタリア語
日本語
韓国語
簡体字中国語
スペイン語 (モダン)
スウェーデン語
繁体字中国語
タイ語
上記の言語に固有の語形変化/単語区切りに加え、その他の言語で使用する汎用的な語形変化/単語区切り機能も備わっています。特定の語形変化/単語区切り機能が適用される言語 (カタロニア語の代わりにスペイン語、アフリカーンス語の代わりにオランダ語など) を使用した方が望ましい結果を得られる可能性もありますが、原則として、このようなときは汎用言語を選択することを推奨しています。別の "同種の" 言語を使用するときは、適切な結果が得られるかどうかを実際のデータでテストしてください。言語のサポートは非常に複雑です。選択した言語と少しでも異なるデータを使用するとトラブルが発生します。
Microsoft Search サービスと関連コンポーネントはさまざまなプロバイダに実装されていますが、どれを使用するかは処理の内容によって異なります。たとえば、Exchange のデータにインデックスを付けるときは、Exchange の実装が適しています。ただし、ファイル システムを使用するときは Index Server を使用してください。SQL Server 2000 を使用する場合は、当然、SQL Server 2000 のフルテキスト検索が最も適しています。
Microsoft Search サービスでは、特定の言語のテキスト領域に "タグ" を付け、1 つのデータ セットに多言語インデックスを作成することができます。一方、SQL Server 2000 ではこの方法でデータに "タグ" を付けることができないので、言語を列レベルで指定する必要があります。ただし、1 つの列に複数のインデックスを作成することは可能です。1 つの列に多言語データが格納されており、言語固有の検索を行う必要がある場合は、この方法でも十分に対応できます。使用する言語を指定するには、sp_fulltext_column ストアド プロシージャの @language パラメータを使用します。
フルテキスト検索で使用する既定の言語を指定するには、次のように、default full-text language オプションを指定して sp_configure ストアド プロシージャを実行します。
sp_configure '詳細設定オプションを表示', 1
GO
RECONFIGURE
GO
sp_configure '既定のフルテキスト言語', 1041
GO
RECONFIGURE
GO
既定の言語を使用する場合、sp_fulltext_column を呼び出して言語を指定する必要はありません。
多くのユーザーから、"自国の言語をフルテキスト検索で使用できるようにするにはどうすればよいのか" という質問を受けます。残念ながら、現在のところその方法はありません。
FTS および Microsoft Search サービスは、サロゲート ペア (前の「サロゲートについて」を参照) をサポートしていません。さらに、これらの値に基づいて検索を行った場合、または SQL Server 2000 が未定義と見なした文字に基づいて検索を行った場合は正しい結果が得られません。
OLAP/階層構造データを操作する
一般に、Unicode フィールドの多言語テキストを SQL Server 2000 で処理する場合に適用されるすべてのルールは、SQL Server 2000 の Analysis Services コンポーネントに含まれている Online Analytical Processing Capabilities (OLAP) にもそのまま適用されます。Analysis Services は、SQL Server 2000 自体がサポートしているすべての文字を処理できます。対象のデータがクライアント システムの既定のコード ページにない場合、そのデータは、OLAP およびそのウィザードのユーザー インターフェイスに疑問符として表示されます。ただし、実際のデータには影響を与えません。単なる UI 表示上の問題です。
OLAP 対応の SQL Server 2000 では、データ ウェアハウスを構成する階層データ構造の各部にそれぞれ異なる照合順序を指定できません。通常、データ分析ではそれほど使用しませんが、(分析時に) データをアルファベット順で分割するときに影響を受けます。その場合は、順序と分割方法を明示的に定義し、かつ文字順序を前提としない別の方法を使用しなければなりません。これは、階層構造のデータを表示するときにも役立ちます。この機能が必要な場合、OLAP ソースから返されたデータのサブセットを並べ替える必要があります。
SQL Server 2000 の XML サポートを使用して多言語データを操作する
SQL Server 2000 が強力にサポートしている XML は多言語データの処理にも役立ちます。XML 自体は UTF-8 を使用して Unicode をエンコーディングしますが、多くの場合、SQL Server は、自身が作成する XML で UCS-2 エンコーディングを使用するためです。XML でのエンコーディングを指定するにはいくつかの方法があります。
ADO ストリーム オブジェクトでデータを XML としてフォーマットし、そのストリームを維持する場合、出力エンコーディングを指定できます。この場合、XML 形式のデータに適切なエンコーディングが指定されます。
URL の出力エンコーディングを指定できます。
XML テンプレートを使用してエンコーディングを指定できます。
これらの方法を使用しない場合でも、Unicode が既定でサポートされ、適切に動作します。
重要な注意点が 1 つあります。XML で名前として使用できる文字は、SQL Server で識別子として使用できる文字よりかなり厳しく制限されています。SQL Server の識別子を完全にサポートするため、XML で使用不可能な文字は _x0000_ という特殊な形式に変換されます (0000 には、Unicode コード ポイント番号が代入されます)。SQL Server はこれらの文字を正しく認識し、適切な結果を返します。Updategrams は、どのような場合でもエンコーディングを解釈します。ただし、これらを使用する必要があるのはマッピング スキーマが用意されていない場合だけです。
たとえば、次の Transact-SQL ステートメントを使用して、UCS-2 エンコーディングの XML ファイルを作成することができます。
USE Northwind
GO
SELECT TOP 1 * FROM "Order Details" FOR XML AUTO
DECLARE @h int
EXEC sp_xml_preparedocument @h output,
N'<?xml version="1.0" encoding="ucs-2"?>
<root test_x0020_2="foo">.gif)
</root>'
SELECT * FROM OPENXML(@h,'/root') WITH("test 2" varchar(200) )
EXEC sp_xml_removedocument @h
このスクリプトは、キリル文字列 .gif)
をエンコードする XML ドキュメントを作成します。この単語はウクライナ語に含まれています。
詳しい図は、SQL Server 2000 の XPath サポートに収められています。現在、Web 上では Updategrams のベータ版がリリースされていますが、2001 年初頭には最終版がリリースされる予定です。これらの機能は多言語テキストの高度な処理を目的として設計されており、エンコード方法を指定するための方法が用意されています。また、識別子の使用方法のセクションで説明した構文もサポートしています。
ほかのデータベース製品とやり取りする
ほかのデータベース システムを使用する際の最も重要な作業は、コード ページを指定し、そのシステムのルールを明確にすることです。ほとんどの場合、SQL Server 側のデータ アクセス方式は COM です。つまり、Unicode データを使用します。したがって、SQL Server とほかのデータベースとの間でインターナショナル アプリケーションをいかにスムーズに実行できるかは、相手のデータベース製品が Unicode をどの程度サポートしているかにかかっています。
たとえば、Oracle や Sybase SQL Server などのデータベース製品は、UTF-8 エンコーディングの Unicode をサポートしています。通常、データは、ADO/OLE DB によって UTF-16 に変換された上で画面に表示されるので、この点は問題になりません。しかし、これらの製品のデータを直接処理する場合は事情が違ってきます。
問題はもう 1 つあります。Sybase SQL Server などの製品は National 文字データ型をサポートしていますが、それらを Unicode データ型としては処理しません。nchar と nvarchar は、英語 (U.S.) のデータベースに日本語データを格納するときに使用するフィールドです。ほかの製品に対してクエリを実行するときは、そのデータベースで情報がどのように処理されるかを確認する必要があります。OPENROWSET などのコマンドを使用すれば、インターナショナル テキストを適切に処理することができます。National 文字データ型を使用した Unicode テキストの指定は、すべての言語を適切にエンコードするために Microsoft SQL Server が独自に採用している方式です。
結論
Microsoft SQL Server 2000 には、さまざまな種類の強力なインターナショナル機能が備わっています。SQL Server 7.0 は、真の多言語機能を実現した最初の SQL Server です。SQL Server 2000 ではその機能がさらに強化され、真のグローバル アプリケーションを構築できるようになりました。インターネットや Web の重要性が叫ばれている現在、そのニーズに応えることはアプリケーションおよびデータベースの必須条件となっています。さらに、電子商取引やグローバル通信の必要性が高まってきたことで、それに対応できるデータベース製品が強く求められています。SQL Server 2000 は、グローバル組織に最も適したデータベースです。
謝辞
この記事の執筆にあたり、多くの方々に多大なご協力をいただきました。この場を借りてお礼を申し上げます。
Michael Kung 氏。SQL Server のグローバリゼーション担当プログラム マネージャとして、この記事のさまざまな箇所を詳細にチェックすると共に、製品分野で疑問点が発生したときに適切な担当者を紹介してくださいました。多分野にわたって豊富な知識を有する Michael 氏は、この記事に限らず、常に私の大切な情報源です。このプロジェクトで彼の協力を得られたことをうれしく思います。
Peter Carlin 氏。SQL Server リレーショナル エンジンを担当している開発マネージャ Peter 氏からは、ほかのだれよりも多くのフィードバックをいただきました。また、電子メールでも、SQL Server の Unicode サポートに関する多くの貴重な情報を提供していただきました。この電子メールからさまざまな発想を得たおかげで、当初の予定の 25 倍もの長さの記事を書き上げることができました。
Fernando Caro 氏。主任インターナショナル プログラム マネージャである Fernando 氏には、SQL Server の OLAP 機能について詳しく説明していただきました。また、ローカライズされたシステム メッセージについても、彼の協力によって、"sorry, not supported" という不親切なものから、適切なリソースを指示するように変更することができました。この記事が問題点を指摘する機会を与えてくれたことに感謝します。そしてそれ以上に、Fernando 氏および Peter 氏がその指摘を受け入れ、解決してくれたことに感謝します。SQL Server が優れた製品であるのは、常にユーザーのことを考え、可能なあらゆる方法で対応しているこうしたスタッフのおかげです。
ご協力いただいたその他のプログラム マネージャおよびテスターの方々にも感謝の意を表します。彼らの手助けがなければ、SQL Server 製品の多くのインターナショナル機能は実現しなかったことでしょう。また、ここに記載されている内容の多くも彼らの協力なくしては執筆できませんでした。改めて、Michael Rys 氏、Euan Garden 氏、Fadi Fakhouri 氏、James Howey 氏に感謝いたします。また、SQL Server のフルテキスト検索の基盤となる Microsoft Search サービスについて、洞察鋭い意見を与えてくださった Margaret Li 氏にもお礼を申し上げます。
Windows 2000 チームの多くの熱心なスタッフにも助けていただきました。照合順序やロケール サポートの機能といった基本的な情報、そして SQL Server 7.0 および SQL Server 2000 の照合順序サポートに関するデータを提供していただきました。質問に答え、激励してくださった Julie Bennett 氏、Cathy Wissink 氏、John McConnell 氏にも感謝の意を表します。
SQL Server のインターナショナル機能および多言語機能は単なる "アドオン" ではなく、この製品の中心的な存在なので、SQL Server 製品の開発に携わっているほぼすべてのスタッフがこれらの機能のプランニング、開発、テストにかかわっています。ここで、グローバル環境に最適なこの製品を生み出したすべてのスタッフにお礼を申し上げます。
著者紹介
Michael Kaplan 氏は、Trigeminal Software 社の社長を務めると同時に、主任開発者としても活躍しています。同社は、Microsoft Visual Basic、Microsoft SQL Server、Microsoft Access、および ASP アプリケーションのインターナショナリゼーションとローカリゼーションを専門とするソフトウェア開発およびコンサルティング会社です。Michael 氏は、Sams Publishing から出版された『Internationalization with Visual Basic』の著者であり、2001 年中頃には同氏の 2 冊目の著作となる『Internationalization with SQL Server』が出版される予定です。インターナショナル開発についての記事を多数執筆しており、公演も数多く行っています。電子メール アドレスは michka@trigeminal.com、Trigeminal Software 社の Web サイトは http://www.trigeminal.com/ です。