適用対象:SQL Server
Azure SQL Database
Azure SQL Managed Instance
全文インデックスを作成する際は、インデックスされた列にカラムレベルの言語を指定してください。 列に対する全文クエリは、指定された言語の 単語ブレーカーと語幹 を用います。 Full-Text エンジンがカラム言語を選択する際にテキストをどのようにトークン化し、インデックス付けするかを考えてみてください。
注
フルテキスト インデックスの列に対して列レベルの言語を指定するには、列を指定するときに LANGUAGE <language_term> 句を使用します。 詳細については、「CREATE FULLTEXT INDEX と ALTER FULLTEXT INDEX」を参照してください。
Full-Text Search での言語サポート
このセクションでは、ワード ブレーカーとステミング機能の概要について説明し、Full-Text Search で列レベル言語の言語コード識別子 (LCID) を使用する方法について説明します。
ワード ブレーカーとステマーの紹介
SQL Server データベース エンジンには、多くの言語向けのワードブレーカーやステマーが含まれており、デフォルトで有効化されています。 Microsoft 自然言語グループ (NLG) は、これらの言語コンポーネントを実装し、サポートしています。 サポートされている言語の一覧については、 sys.fulltext_languagesを参照してください。
ワード ブレーカーやフィルターなどの外部コンポーネントは、セキュリティを向上させるために署名されるべきです。 署名を確認するには、以下の文を実行します。
EXECUTE sp_fulltext_service 'verify_signature';
Full-Text Search で列レベル言語の名前を使用する方法
全文索引を作成する際は、各列に有効な言語名を指定してください。 言語名が有効でも sys.fulltext_languages カタログビューで返さない場合は、Full-Text 検索は同じ言語族の最も近い利用可能な言語名にフォールバックします。 それ以外の場合、Full-Text 検索はニュートラル ワード ブレーカーにフォールバックします。 このフォールバック動作を避けるために、有効かつ利用可能な言語名を指定してください。
注
LCID は、フルテキスト インデックス作成で有効なすべてのデータ型 ( char 型や nchar型など) に適用されます。 char、 varchar、または text 型の列の並べ替え順を、LCID で識別された言語とは異なる言語に設定した場合でも、それらの列に対してフルテキスト インデックスを作成したりクエリを実行したりするときには LCID が使用されます。
単語区切り
インデックス作成の対象テキストを単語の境界でトークン化するのは、言語固有のワード ブレーカーです。 したがって、単語を区切る動作は言語によって異なります。 1 つの言語 ( x) を使用して複数の言語 {x、 y、および z} のインデックスを作成すると、一部の動作で予期しない結果が発生する可能性があります。 例えば、ダッシュ(-)やコンマ(,)は、ある言語では使われる単語区切り要素ですが、別の言語では使われないことがあります。 ごくまれに、同じ単語でも言語によってステミング結果が異なるため、予期しないステミング動作が発生することがあります。 たとえば、英語では通常、単語の境界は空白またはなんらかの句読点になります。 ドイツ語など他の言語では、単語や文字が組み合わせられることもあります。 そのため、選択する列レベルの言語は、その列の行に格納する言語を表す必要があります。
西洋言語
西洋言語ファミリの場合、列に格納する言語がわからない場合、または複数の言語が格納されると予想される場合は、一般的な回避策として、列に格納される可能性がある最も複雑な言語にワード ブレーカーを使用します。
たとえば、英語、スペイン語、ドイツ語のコンテンツを 1 つの列に格納することが想定される場合があります。 これらの 3 つの西洋言語は、ドイツ語のパターンが最も複雑で、同様の単語区切りのパターンを持っています。 したがって、この場合、英語とスペイン語のテキストを正しく処理できるドイツ語のワードブレーカーを使うのが良い選択です。 一方、英語のワード ブレーカーを使用した場合は、複合語を持つドイツ語のテキストを完璧には処理できないことがあります。
言語ファミリで最も複雑な言語のワード ブレーカーを使用しても、ファミリ内のすべての言語の完全なインデックス作成が保証されるわけではありません。 最も高度な単語分割器でも、他言語で書かれたテキストを正しく処理できないまれなケースが存在する可能性があります。
非西洋言語
非西洋言語(中国語、日本語、ヒンディー語など)では、言語的な理由から前の回避策は必ずしも効果がありません。 非西洋語については、以下のいずれかの回避策を検討してください。
異なるファミリに属する複数の言語の場合
類似性のない複数の言語 (たとえばスペイン語と日本語) が 1 つの列に格納される可能性がある場合は、格納する列を言語ごとに分けることを検討してください。 この区切りにより、各列ごとに言語固有のワードブレーカーを使えます。 この回避策を選択した場合に、クエリ時にクエリ言語が判明していないときは、両方の列に対してクエリを実行し、適切な行やドキュメントを検索できるようにする必要があります。
バイナリコンテンツ(Microsoft Word文書など)の場合
インデックスされたコンテンツが バイナリ 型の場合、テキストをワードブレーカーに送る前に処理する Full-Text 検索フィルターがバイナリファイル内の特定の言語タグを尊重することがあります。 この場合、インデックス作成時に、フィルターはドキュメントまたはドキュメントのセクションに対して適切な LCID を出力します。 Full-Text エンジンは、その LCID を持つ言語のワード ブレーカーを呼び出します。 しかし、多言語コンテンツをインデックス化した後は、そのコンテンツが正しくインデックスされているかを確認してください。
プレーン テキスト コンテンツの場合
コンテンツがプレーンテキストの場合は、 xml データ型に変換して、各ドキュメントまたはドキュメント セクションに対応する言語を示す言語タグを追加できます。 ただし、そのためには、フルテキスト インデックスの作成前に言語を把握しておく必要があります。
語幹検索
列レベルの言語を選択する際のもう 1 つの考慮事項は 、ステミングです。 フルテキスト クエリでのステミングは、特定の言語で単語のすべての語幹 (変曲) 形式を検索するプロセスです。 汎用のワード ブレーカーで複数の言語を処理する場合、列に対して指定された言語に対してのみステミング プロセスが機能します。列内のその他の言語に対しては、ステミング プロセスが機能しません。 たとえば、ドイツ語のステマーは、英語やスペイン語 (など) では機能しません。 この挙動は、クエリ時に選ぶ言語によって想起に影響を与える可能性があります。
列の種類が Full-Text 検索に及ぼす影響
言語を選択する際のもう 1 つの注意点は、データの表記方法に関連するものです。 varbinary(max) 列に格納されていないデータの場合、特別なフィルター処理は実行されません。 テキストはそのままの形で単語を分解するコンポーネント (ワード ブレーカー) に渡されます。
また、ワード ブレーカーは主に記述されたテキストを処理することを目的として設計されています。 テキストにマークアップ(HTMLなど)が含まれている場合、インデックス作成や検索時の言語精度が低下する可能性があります。 その場合、選択肢は2つあります。推奨される方法は、テキストデータを varbinary(max) 列に保存し、ドキュメントタイプを指定してフィルタリングできるようにすることです。 もしその方法が難しい場合は、ニュートラルワードブレーカーを使い、可能であればノイズワードリストにマークアップデータ(例えばHTMLの「br」)を追加することも検討してください。
注
ニュートラル言語を指定した場合、言語ベースのステミングは行われません。
全文クエリでデフォルトでないカラムレベルの言語を指定する
デフォルトでは、データベース エンジンでは、Full-Text Searchは全文節の各列に指定された言語を用いてクエリ用語を解析します。 この動作をオーバーライドするには、クエリ時に既定以外の言語を指定します。 リソースがインストールされているサポート対象言語では、LANGUAGE <language_term>、CONTAINSTABLE、FREETEXT、または FREETEXTTABLE クエリの 句を使用して、検索語の単語区切り、語幹処理、シソーラス、およびストップワード処理に使用される言語を指定できます。