1. グローバリゼーション・サポート・ガイド
  2. 言語ソートと照合

5 言語ソートと照合

この章では、Oracle Databaseでの文字データまたは文字列の言語ソートおよび検索のメカニズムについて説明します。文字列(文字値)間の相互の順序を決定するプロセスを照合と言います。2つの文字列があるときに、並び順がどちらも同じなのか、前後に分かれるのかは照合によって決まります。Oracleのドキュメントでは、照合のかわりにソートという用語がよく使用されます。

表の列のような文字列のセットが、指定の検索条件と等しい値なのか、検索パターンと一致する値なのかを調べる際に、値を等しいと判定する基準が特に重要になります。検索で使用されるSQLの演算子と関数は、'='、LIKE、REGEXP_LIKE、INSTR、およびREGEXP_INSTRです。この章では、一致という言葉は、等価演算子=を使用して文字列全体が等しいと判定できる場合、あるいはLIKE、REGEXP_LIKE、またはREGEXP_INSTRを使用して文字列がパターンと一致するため、部分文字列が等しいと判定できる場合を意味するものとします。Oracle Textにより、Oracle Databaseの高度なフルテキスト検索機能が提供されます。

1つのセットの中にある文字列を並べ替えることをソートと言います。たとえば、ORDER BY句の場合は、問合せ結果をソートするために、文字列の順序の決定に照合が使用され、PL/SQLの場合は、VARCHAR2値で索引付けられた結合配列の中の文字列をソートするために照合が使用され、また、MIN、MAX、GREATEST、およびLEASTの各関数の場合は、最も短い文字値または最も長い文字値を探すために照合が使用されます。

文字列の並び順の決定に適用できる照合は様々です。標準的、慣習的な話し言葉を考慮に入れた照合のことを言語照合と言います。文字列の順序は、ある言語で書かれた辞書、電話帳などの文字で構成される一覧と同様です。対照的に、バイナリ照合の場合は、それぞれの文字列が単純なバイトの並びとして扱われ、バイナリ表現(文字コード)に基づいて文字列が並べ替えられます。

関連項目:

次のトピックでは、言語ソートと照合について説明します。

5.1 Oracle Databaseの照合機能の概要

照合は言語によって異なります。さらに、同じアルファベットを使用している文化または国の間でも、文字のソート方法が異なる場合があります。たとえば、デンマークのÆは、Zの後にきます。また、YとÜは同じ文字の変形とみなされます。

照合では、大/小文字区別の有無を指定できます。ケースは、大文字であるか小文字であるかの条件を指します。たとえばラテン・アルファベットの場合、Aが大文字で、それに対する小文字がaです。

照合では、発音区別記号を無視するか考慮するかを指定できます。発音区別記号は、文字または文字列の上または下にある記号で、それが付いていない場合の文字とは発音が異なることを示します。たとえば、façadeの場合、セディラ(,)は発音区別記号です。セディラが付いている場合は、cの発音が変化します。

表音的な照合順序や、文字の外観に基づいた照合順序も指定できます。たとえば、東南アジアの表意文字の場合は、画数に基づいた照合を指定できます。照合の一般的な問題となるものに、結合文字があります。たとえば、伝統的なスペイン語のchは1つの独立した文字であり、ソート順序ではcの後にきます。つまり、正しいソート順序は、cerveza、colorado、cheremoyaのようになります。したがって、文字cは、次にくる文字がhであるかどうかが確認されるまで、ソートされません。

Oracle Databaseには、次のタイプの照合があります。

  • バイナリ

  • 単一言語

  • 多言語

  • Unicode照合アルゴリズム(UCA)

単一照合はその言語固有の文字の順序に従って並べ替えるようになっていますが、多言語照合とUCA照合は、様々な言語をまとめて処理できるようになっています。さらに、UCA照合は、Unicode規格で、国際照合標準ISO 14651と完全な互換性があるUnicode照合アルゴリズム(UCA)の仕様をすべて満たしています。UCA規格は、Unicodeのすべての文字、したがって世界中のすべての言語のすべての文字の、完全な言語的順序付けを提供しています。Unicodeアプリケーションは広くデプロイされているため、UCA照合は、多言語データのソートに最適です。

5.2 バイナリ照合の使用

文字データをソートする方法の1つは、文字コード体系によって定義された文字の数値に基づいています。このようなソートをバイナリ照合と呼びます。バイナリ照合は最も高速なソート・タイプです。ASCIIやEBCDICの規格では、文字AからZを昇順の数値で定義しているため、英語のアルファベットについてはこのタイプで正しいソート結果が得られます。

ノート:

ASCII規格では、大文字はすべて小文字の前にきます。逆に、EBCDIC規格では、小文字はすべて大文字の前にきます。

他の言語で使用されている文字が存在すると、通常、バイナリ照合では正しい結果が得られません。たとえば、文字コード体系で、Äの数値がBの数値より高い場合、昇順のORDER BY問合せでは、ABC、ABZ、BCD、ÄBCの順で文字列が戻ります。表意文字を使用するアジア言語の場合、通常、バイナリ照合に言語的な意味はありません。

5.3 言語照合の使用

文字のアルファベット順に一致する照合基準を得るには、文字コード体系内の数値に依存せずに文字をソートする別のソート方法を使用する必要があります。この方法を言語照合と呼びます。言語照合では、各文字を、その文字の言語的に適切な順序を反映した数値に置き換えることによって処理が行われます。

この項には次のトピックが含まれます:

5.3.1 単一言語照合

Oracle Databaseでは、単一言語照合の場合、文字列は2つのステップで比較されます。最初のステップでは、メジャー値テーブルにある文字列全体のメジャー値が比較されます。通常、同じ外観の文字には、同じメジャー値があります。第2のステップでは、マイナー値テーブルにあるマイナー値が比較されます。メジャー値とマイナー値はOracleデータベースによって定義されます。Oracleデータベースでは、マイナー値が異なる同じメジャー値を使用して、発音区別記号を持つ文字と大/小文字区別を定義します。

各メジャー・テーブル・エントリには、1文字のUnicodeコード・ポイントとメジャー値が含まれています。Unicodeコード・ポイントは、1文字を表す16ビットのバイナリ値です。

次の表に、a、A、ä、Äおよびbのソートに使用するサンプルの値を示します。

表5-1 絵文字のサンプルとそのソートのメジャー値とマイナー値

絵文字 メジャー値 マイナー値

a

15

5

A

15

10

ä

15

15

Ä

15

20

b

20

5

ノート:

単一言語照合は、Unicode以外のマルチバイト・データベース文字セットには使用できません。文字セットがUnicode以外のマルチバイトの場合、単一言語照合を指定すると、デフォルトのソート順はデータベース文字セットのバイナリ・ソート順となります。例外の1つに、UNICODE_BINARYがあります。この照合は、すべての文字セットに使用できます。

関連項目:

「Unicode規格とは」

5.3.2 多言語照合

Oracle Databaseには多言語照合が用意されているため、複数言語のデータを1つのソートとしてソートできます。この機能は、複雑なソート・ルールや多言語データベースを持つ地域または言語に有効です。Oracle Database 12cの時点で、Oracle Databaseは、以前のリリースによって定義された照合のすべてをサポートしています。

アジア諸国の言語データや多言語データに対しては、ISO 14651規格に基づいたソート・メカニズムが用意されています。たとえば、漢字は、画数、ピンイン(中国語の発音記号)または部首で順序付けできます。

また、多言語照合では、標準的な同値化および補助文字を処理できます。標準的な同値化は、文字間または文字列間での基本的な同値化です。たとえば、çは、cと,の組合せと同じです。補助文字 はUnicodeでのユーザー定義文字または事前定義済の文字であり、特定のコード範囲内の2つのコード・ポイントを必要とします。1つの多言語ソートに最大110万のコード・ポイントを定義できます。

たとえば、Oracle Databaseではフランス語の単一言語ソート(FRENCH)がサポートされていますが、フランス語の多言語照合(FRENCH_M)を指定できます。_Mは、多言語ソートに対するISO 14651規格を表します。このソート順では、GENERIC_Mソート順に基づき、発音区別記号を右から左へとソートできます。多言語ソートは、通常、表に多言語データが含まれる場合に使用されます。表にフランス語のみが含まれている場合は、メモリーの使用量が少ないフランス語の単一言語ソートを使用すると、パフォーマンスが向上する可能性があります。メモリー使用量が少ないのは、フランス語の単一言語ソートの方が、フランス語の多言語ソートよりも定義されている文字が少ないためです。どの方法を使用するかは、ソートの範囲とパフォーマンスのトレードオフになります。

関連項目:

5.3.2.1 多言語照合レベル

Oracle Databaseでは、多言語照合を次の3つの精度レベルで評価します。

5.3.2.1.1 1次レベル照合

1次レベル照合では、文字aと文字bの相違など、ベース文字間の相違を識別します。aがbの前にくるか、bがaの前にくるか、あるいは同等かの定義は、個々のロケールに準じます。文字をバイナリで表現することは、意味のないことです。無視可能な文字には、0 (ゼロ)の1次レベルの順序(重み)を割り当てます。その結果、その文字は1次レベルで無視されます。他のレベルでの無視可能文字には、そのレベルで順序0(ゼロ)が割り当てられます。

たとえば、1次レベルでは、batのすべてのバリエーションが、betのすべてのバリエーションより前にきます。どちらの場合も、それぞれのバリエーションは次のように様々な順序で表示されます。 

Bat
bat
BAT
BET
Bet
bet

関連項目:

「無視可能文字」

5.3.2.1.2 2次レベル照合

2次レベル照合では、ベース文字(1次レベル照合)を識別してから、特定のベース文字に付いている様々な発音区別記号を識別します。たとえば、文字Äと文字Aの相違は、発音区別記号の有無のみです。したがって、ÄとAはベース文字(A)が同じであるため1次レベルでは同じ文字になりますが、2次レベルでは異なる文字になります。

次のリストは、1次レベル(resumeがresumesの前)と2次レベル(発音区別記号なしの文字列が発音区別記号付きの文字列の前)でソートされています。 

resume
résumé
Résumé
Resumes
resumes
résumés
5.3.2.1.3 3次レベル照合

3次レベル照合では、ベース文字(1次レベル照合)、発音区別記号(2次レベル照合)およびケース(大文字と小文字)が識別されます。さらに、+、-および*などの特殊文字も識別できます

次に3次レベル照合の例を示します。

  • 文字aとAは、1次レベルと2次レベルでは同じ文字ですが、3次レベルでは異なる文字です。これは、ケースが異なるためです。

  • 文字äとAは、1次レベルでは同じ文字ですが、2次レベルと3次レベルでは異なる文字です。

  • ダッシュ文字-の1次レベルと2次レベルでの順序は、0(ゼロ)です。つまり、この文字は、1次と2次のレベルでは無視されます。ダッシュを1次レベルの重みが0(ゼロ)以外の別の文字、たとえば、uと比較しても、1次レベルでの結果は取得できません。これは、uと比較する対象の文字がないためです。この場合は、3次レベルでのみ-とuの相違が検索されます。

次のリストは、1次レベル(resumeがresumesの前)、2次レベル(発音区別記号なしの文字列が発音区別記号付きの文字列の前)および3次レベル(小文字が大文字の前)でソートされています。 

resume
Resume
résumé
Résumé
resumes
Resumes
résumés
Résumés

5.3.3 UCA照合

Unicode照合アルゴリズム(UCA)は、照合に関する国際的な規格であるISO 14651の仕様をすべて満たすUnicode規格です。それぞれに特徴を持った言語すべてを対象にした合理的なデフォルトの順序になるように、UCAに基づいてDefault Unicode Collation Element Table (DUCET)が定義されています。特定言語で正しい順序付けができるようにするために、その言語の言語要件を満たすようにDUCETを調整できます。各種言語に応じたDUCETの調整版が、Unicode Common Locale Data Repositoryに公開されています。

Oracleデータベースは、Oracle Database 12cリリース2 (12.2)の時点で、UCA 7.0完全準拠のUCA照合を提供しています。DUCETに基づいて照合できるだけでなく、よく使用されている様々な言語の特性に合せて照合することができます。たとえば、UCA照合UCA0700_SCHINESEを指定して、簡体字中国語を含む多言語データをソートできます。この照合は、簡体字中国語のデータをピンイン(中国語の発音記号)の順に表示します。

多言語データのソートには、サポートされている最新バージョンのUCA照合をお薦めします。

この節では、以下のトピックについて説明します。

関連項目:

Unicode照合アルゴリズムおよび関連する用語の詳細は、Unicode ConsortiumのWebサイトを参照してください

5.3.3.1 UCA比較レベル

多言語照合と同様に、UCA照合では、マルチレベルの比較アルゴリズムを使用して文字を評価します。そのレベルは次の4レベルまであります。

5.3.3.1.1 1次レベル

1次レベルはベース文字を区別するために使用されます。多言語照合の1次レベル照合において使用される比較に類似しています。

関連項目:

ベース文字の違いの例は、「1次レベル照合」を参照してください

5.3.3.1.2 2次レベル

2次レベルは、ベース文字が同じである場合に、発音区別記号を区別するために使用されます。多言語照合の2次レベル照合において発音区別記号を区別するために使用される比較に類似しています。

関連項目:

発音区別記号の違いの例は、「2次レベル照合」を参照してください

5.3.3.1.3 3次レベル

3次レベルは、発音区別記号が同じであるベース文字でケースを区別するために使用されます。多言語照合の3次レベル照合においてケースを区別するために使用される比較に類似しています。さらに、UCA DUCET照合は、可変文字の重み付けに基づいて、句読点を1次または4次の重要性で処理します。これは、句読点を3次レベルの重要性で処理する、多言語照合の3次レベル照合とは異なります。

関連項目:

大/小文字が違う文字の例は、「3次レベル照合」を参照してください

5.3.3.1.4 4次レベル

4次レベル照合は、可変文字の重み付けがshiftedになっている場合に、可変文字とそれ以外の文字の間の区別に使用されます。これは、ベース文字と大/小文字の違いがない平仮名とカタカナの区別にも使用されます。次の図に、例を示します。

図5-1 平仮名とカタカナとの照合

図5-1の説明が続きます
「図5-1 平仮名とカタカナとの照合」の説明

関連項目:

「UCA照合パラメータ」

5.3.3.2 UCA照合パラメータ

次の表に、Oracle Database 12cリリース2 (12.2)のUCA照合でサポートされている照合パラメータと照合オプションを示します。

表5-2 UCA照合パラメータ

属性 オプション 照合修飾子

strength

primary

secondary

tertiary

quaternary

_AIまたは_S1

_CIまたは_S2

_S3

_S4 (alternate属性をshiftedに設定した場合にのみ適用)

alternate

non-ignorable

shifted

blanked

_VN

_VS

_VB

backwards

on

off

_BY

_BN

normalization

on

_NY

caseLevel

off

_EN

caseFirst

upper

off

_FU (デンマーク語にのみ有効)

_FN (他の言語にのみ有効)

hiraganaQuaternary

(UCA 7.0では非推奨)

on

off

_HY

_HN

numeric

off

_DN

match-style

minimal

_MN

パラメータstrengthは、UCA比較レベルを表します。

パラメータalternateは、可変文字の重み付けを制御します。

パラメータbackwardsは、発音区別記号を逆順ソートするかどうかを制御します。

パラメータhiraganaQuaternaryは、日本語のUCA照合にのみ適用できます。他の照合には影響を与えません。これを"on" (_HY)に設定すると、対応するひらがなとカタカナに異なる4次重み付けが割り当てられます。それ以外の場合は、これらの重みは同じです。hiraganaQuaternaryパラメータは、UCA 7.0で非推奨になりました。

表5-2に示したオプションを使用して、前述の4つのUCAパラメータを構成できます。表5-2に記載の他のパラメータのオプションは、調整された言語に基づいて現在固定されており、Oracle Database 12cの時点では構成できません。

関連項目:

5.4 言語照合の特徴

この項では、次の言語照合機能の違いについて説明します。

言語照合は、必要な特性を含むようにカスタマイズできます。

関連項目:

ロケール・データのカスタマイズ

5.4.1 ベース文字

ベース文字はベース文字表に定義されています。この表によって、各文字がベース文字にマップされます。たとえば、a、A、äおよびÄはすべて、ベース文字であるaにマップされます。この概念は、Oracle Textで作業する場合に特に重要です。

関連項目:

Oracle Textリファレンス

5.4.2 無視可能文字

多言語照合とUCA照合では、いくつかの文字が無視可能とみなされる場合があります。ソート操作または照合操作で無視可能文字を含む2つの値(文字列)を比較する際、無視可能文字はスキップされ、存在しないものとして処理されます。無視可能文字には、1次無視可能文字、2次無視可能文字、および3次無視可能文字の3種類があります。

5.4.2.1 1次無視可能文字

1次無視可能文字は、任意の比較に適用される多言語照合またはUCA照合の定義にアクセントを区別しない修飾子_AIがある場合(GENERIC_M_AI、UCA0700_DUCET_AIなど)に無視されます。

1次無視可能文字は各種アルファベット(ラテン、キリル、ギリシャ、デーバナーガリ、カタカナなど)の発音区別記号(アクセント)で構成されており、Enclosing CircleやEnclosing Squareなどの装飾修飾子も含まれます。これらの文字は分音結合文字で、前の文字と結合して1つのアクセント付き文字または装飾付き文字になります(分音とは、画面上あるいは紙面上の前の文字と重なる文字のことです)。たとえば、英小文字eの後ろにCombining Grave Accentを付けると1文字のèになり、英大文字Aの後ろにCombining Enclosing Circleを付けると1文字の(A)になります。分音文字がアクセントを区別しないソートで無視可能と定義されているため、このソートでは、たとえばrôleとrole、naïveとnaive、および(A)(B)(C)とABCを同値として処理できます。

Oracle Locale Builderユーティリティの多言語照合の定義では、1次無視可能文字は分音文字と呼ばれます。

5.4.2.2 2次無視可能文字

2次無視可能文字は、適用される定義にアクセントを区別しない修飾子_AIまたは大/小文字を区別しない修飾子_CIがある場合に無視されます。

多言語照合の2次無視可能文字には、句読点(たとえば空白文字、改行制御コード、ダッシュ、様々な引用符形式、数学演算子、点、カンマ、感嘆符、様々な括弧形式など)が含まれます。アクセントを区別しない(_AI)ソートや、大/小文字を区別しない(_CI)ソートでは、このような句読点は無視されるため、multi-lingualとmulti-lingual、およびe-mailとemailをそれぞれ同じ文字として処理できます。

Oracle Locale Builderユーティリティの多言語照合の定義では、2次無視可能文字は句読点と呼ばれます。

しかし、UCA DUCETでは2次無視可能文字は定義されていません。UCAでは句読点は可変文字として処理されます。

5.4.2.3 3次無視可能文字

言語比較では、3次無視可能文字は通常、無視されます。これらは主に制御コード、書式文字、異体字セレクタなどで構成されます。

標準的な大/小文字を区別するソートやアクセントを区別するソートが使用されている場合に、1次無視可能文字と2次無視可能文字は無視されません。ただし、文字列の順序を決定する際、無視可能文字は優先順位が低くなります。たとえば、GENERIC_Mソートではmulti-lingualはmultilingualの後にソートされますが、依然としてmultidimensionalとmultinationalの間にソートされます。順序を決定する際、ベース文字の比較d < l < nの方が、2次無視可能文字であるハイフン(U+002D)の有無よりも高い優先順位が付けられます。

多言語照合の定義における分音文字、句読点の完全なリストは、Oracle Locale Builderで定義を表示すると示されます。一般に、単一言語照合の定義には句読点も分音文字も含まれません。一部の単一言語照合の定義には、空白文字とタブ文字が含まれることがあります。比較アルゴリズムでは、マイナー値が各未定義文字に自動的に割り当てられます。これにより、句読点は無視できなくなりますが、多言語照合の場合と同様に、比較する文字列の順序を決定する際の優先順位は低くなります。単一言語照合での句読点間の順序はUnicodeコード・ポイントに基づいているため、ユーザーの予想とは一致しないことがあります。

関連項目:

「大/小文字区別およびアクセント区別なしの言語照合」

5.4.3 可変文字と可変重み付け

UCAには、可変的な照合要素として定義されている文字があります。このような文字は可変文字と呼ばれ、空白文字、句読点、および特定の記号で構成されます。

UCA照合では、可変文字に異なる重み付けをして、ソートまたは比較でのそれらの文字の効果を調整することができます。これを可変重み付けと呼びます。その動作は、照合パラメータalternateで制御されます。Oracle Database 12cのUCA照合では、可変重み付けのオプションとして次のものがサポートされています。

  • blanked

    可変文字が無視可能文字として扱われます。たとえば、比較時に空白(U+0020)は無視されます。

  • non-ignorable

    可変文字が、無視可能文字ではない文字として扱われます。たとえば、比較の1次レベルで空白(U+0020)は無視されません。

  • shifted

    可変文字は、1次、2次および3次レベルで、無視可能文字とみなされます。さらに、新しい4次レベルが、すべての文字に対して使用されます。文字の4次重み付けは、文字が可変、無視可能、その他のいずれであるかに依存します。たとえば、4次レベルで空白文字(U+0020)にはA(U+0041)とは違う重み付けが割り当てられますが、これは、空白文字は可変文字であっても、Aは可変文字でも無視可能文字でもないからです。

関連項目:

「UCA照合パラメータ」

可変重み付けの例

この項では様々な可変重み付けの例を示します。

例5-1 可変重み付けがBlankedに設定されている場合のUCA DUCETの順序

次の例は、UCA0700_DUCET_VBを使用してソートしたときの例です。 

blackbird
Blackbird
Black-bird
Black bird
BlackBird

空白文字(U+0020)とハイフン(U+002D)は無視可能文字として扱われるため、Blackbird、Black-bird、およびBlack birdは、照合時の重み付けが同じになります。区別されるエントリのみを選択すると、この動作がよくわかります(結果にBlackbirdだけが現れることに注意してください)。 

blackbird
Blackbird
BlackBird

1番目のB(U+0042)の大/小文字の違いにより、Blackbird、Black-bird、およびBlack birdは、blackbirdの後にソートされますが、2番目のb(U+0062)の大/小文字の違いにより、BlackBirdの前にソートされます。

例5-2 可変重み付けがNon-Ignorableに設定されている場合のUCA DUCETの順序

次の例は、UCA0700_DUCET_VNを使用してソートしたときの例です。 

Black bird
Black-bird
blackbird
Blackbird
BlackBird

SPACE(U+0020)とHYPHEN(U+002D)は、無視可能文字とみなされず、1次レベルでb(U+0062)より小さいため、Black birdとBlack-birdはblackbirdより前にソートされます。1次レベルでは空白文字(U+0020)はハイフン(U+002D)よりも小さいため、Black birdはBlack-birdの前にソートされます。

例5-3 可変文字がshiftedと重み付けされている場合のUCA DUCET順序

次の例は、UCA0700_DUCETを使用してソートしたときの例です。 

blackbird
Black bird
Black-bird
Blackbird
BlackBird

SPACE(U+0020)とHYPHEN(U+002D)が最初の3つのレベルで無視され、最初のb(U+0062)に大文字/小文字の相違があるため、blackbirdはBlack birdとBlack-birdの前にソートされます。HYPHEN(U+002D)の4次重み付けがBlackbirdの文字b(U+0062)より小さいため、Black-birdはBlackbirdより前にソートされます。

5.4.4 短縮文字

照合要素は、通常、単一文字で構成されていますが、一部のロケールでは、1つの文字列に2つ以上の文字がある場合があります。その場合、その文字列はソート時にも単一の照合要素とみなす必要があります。たとえば、伝統的なスペイン語の文字列chは、2つの文字で構成されています。これらの文字は、多言語照合では短縮文字と呼ばれ、単一言語照合では、特殊組合せ文字と呼ばれます。

合成文字を短縮文字と混同しないでください。áなどの合成文字は、それぞれ独自のエンコーディングを持つaと'に分解できます。合成文字と短縮文字の違いは、合成文字が端末に1文字として表示できるのに対して、短縮文字はソートにのみ使用され、それを構成する文字はそれぞれ個別に表示される必要があることです。

5.4.5 拡張文字

一部のロケールでは、特定の文字を文字列であるかのようにソートする必要があります。ドイツ語の文字ß(強調のs)がその例です。この文字は、文字列SSと同じようにソートされます。別の例では、öは、odの後、ofの前にoeのようにソートされます。これらの文字は、多言語照合では拡張文字と呼ばれ、単一言語照合では、特殊文字と呼ばれます。短縮文字の場合と同様、拡張文字に対する置換文字列は、ソート目的の場合のみ意味があります。

5.4.6 状況依存文字

日本語では、全角のダッシュ—に似た長母音記号は、先行する文字の母音を長く伸ばすことを示す長音記号を表しています。ソート順序は、長音記号の前にある母音に応じて異なります。この方法は、状況依存照合と呼ばれます。たとえば、文字kaの後にくる長音記号—は、aを長く伸ばすことを示し、aと同じように処理されます。一方、文字kiの後にくる長音記号—は、iを長く伸ばすことを示し、iと同じように処理されます。これをラテン文字に変換すると、ソートは次のようになります。 

kaa   
ka—   -- kaa and ka— are the same
kai   -- kai follows ka- because i is after a
kia   -- kia follows kai because i is after a
kii   -- kii follows kia because i is after a
ki—   -- kii and ki— are the same

5.4.7 標準的な同値化

標準的な同値化は多言語照合の属性であり、同値のコード・ポイント順序のソート方法を記述したものです。標準的な同値化が特定の多言語照合に適用される場合、標準的に同値の文字列は同等とみなされます。

1つのUnicodeのコード・ポイントが、一連のベース文字のコード・ポイントに発音区別記号のコード・ポイントを加えたものと同じ値である場合があります。これは、Unicodeの標準的な同値化と呼ばれます。たとえば、äはウムラウト付きのベース文字aと同じです。言語フラグCANONICAL_EQUIVALENCE = TRUEは、特定の多言語照合にUnicodeに定義されている標準的な同値化規則をすべて適用する必要があることを示します。Oracle Database定義の多言語照合には、標準的な同値化フラグ用の適切な設定が含まれています。すべてのデータが合成された形式の場合は、このフラグをFALSEに設定すると、比較と順序付け機能が高速になります。

たとえば、次の文字列を考えてみます。

  • äa(aウムラウトの後にa)

  • a¨b(aの後にウムラウトとb)

  • äc(aウムラウトの後にc)

CANONICAL_EQUIVALENCE=FALSEの場合、文字列のソート順序は次のようになります。 

a¨b
äa
äc

これは、標準的な同値化が適用されない場合は、aがäの前にくるためです。

CANONICAL_EQUIVALENCE=TRUEの場合、文字列のソート順序は次のようになります。 

äa
a¨b
äc

これは、äとa¨が標準的に同値として処理されるためです。

Oracle Locale Builderを使用すると、既存の多言語照合で標準的な同値化フラグの設定を表示できます。Oracle Locale Builderを使用してカスタマイズした多言語照合を作成する場合は、標準的な同値化フラグを必要に応じて設定できます。

関連項目:

標準的な同値化フラグの設定の詳細は、「Oracle Locale Builderを使用した新規言語ソートの作成」を参照してください

5.4.8 逆2次ソート

フランス語では、発音区別記号付き文字を含む文字列をソートする場合、最初にベース文字が左から右の順に比較されますが、発音区別記号付き文字自体は右から左の順に比較されます。たとえば、デフォルトでは、発音区別記号付き文字は、発音区別記号が付かない文字の後に置かれます。そのため、フランス語ソートでは、ÈditはEdítの前にきます。この2つの文字列は1次レベルでは同値です。2次レベルの順序は、発音区別記号付き文字を右から左へ調べてから決定されます。個別のロケールでは、発音区別記号付き文字を右から左のルールでソートするように要求できます。逆2次ソートを使用可能にするには、REVERSE_SECONDARY言語フラグをTRUEに設定します。

関連項目:

逆2次フラグの設定の詳細は、「Oracle Locale Builderを使用した新規言語ソートの作成」を参照してください

5.4.9 タイ語/ラオ語文字に対する文字の再配列

タイ語とラオ語の場合は、ソート前に一部の文字を後続の文字と最初に入れ替える必要があります。通常、この種の文字は、母音を表す記号であるため、次にくる文字は子音になります。子音と母音は、ソート前に入れ替える必要があります。ソート前に入れ替える必要があるすべての文字について、SWAP_WITH_NEXT語フラグを設定してください。

関連項目:

SWAP_WITH_NEXTフラグの詳細は、「Oracle Locale Builderを使用した新規言語ソートの作成」を参照してください

5.4.10 特殊文字

特殊文字とは、単一言語照合で使用する用語です。この文字は、多言語照合では、拡張文字と呼ばれます。

関連項目:

「拡張文字」

5.4.11 特殊組合せ文字

特殊組合せ文字とは、単一言語照合で使用する用語です。この文字は、多言語照合では、短縮文字と呼ばれます。

関連項目:

「短縮文字」

5.4.12 特殊な大文字

1つの小文字が複数の大文字にマップされる場合があります。たとえば、伝統的なドイツ語では、ßの大文字は、SSです。

このような大/小文字の変換は、NLS_UPPER、NLS_LOWERおよびNLS_INITCAPのSQL関数によって、言語照合で設定された規則に従って処理されます。SQL関数UPPER、LOWERおよびINITCAPでは、これらの特殊文字を処理できません。これは、大/小文字区別の操作が、言語に依存しない基礎となる文字セットに定義されたバイナリ・マッピングに基づいているためです。

NLS_UPPER SQL関数は、その最初の引数文字列を、すべての小文字を対応する大文字にマップして戻します。次の例に、NLS_SORTがXGERMANに設定されている場合のNLS_UPPER関数の結果を示します。 

SELECT NLS_UPPER ('große') "Uppercase" FROM DUAL;

Upper
-----
GROSSE

関連項目:

『Oracle Database SQL言語リファレンス』

5.4.13 特殊な小文字

Oracle Databaseは、特殊な小文字をサポートしています。1つの大文字が複数の小文字にマップされる場合があります。たとえば、トルコ語の大文字Iは、小文字のiのドットなしになります。

5.5 大/小文字区別およびアクセント区別なしの言語照合

Oracle Database内のSQL操作では、常に、大/小文字およびアクセント(発音区別記号)が区別されます。ただし、大/小文字およびアクセントを区別しない比較または照合の実行が必要になる場合があります。

以前のバージョンのデータベースでは、NLS_UPPERおよびNLS_LOWERSQL関数を使用して大/小文字区別なしの問合せを実行できました。この2つの関数は、特定の言語照合定義に基づいて文字列の大/小文字を変更します。これにより、使用言語に関係なく大/小文字を区別しない検索を実行できます。たとえば、次のようにtest1表を作成します。 

SQL> CREATE TABLE test1(word VARCHAR2(12));
SQL> INSERT INTO test1 VALUES('GROSSE');
SQL> INSERT INTO test1 VALUES('Große');
SQL> INSERT INTO test1 VALUES('große');
SQL> SELECT * FROM test1;

WORD
------------
GROSSE
Große
große

GROSSEに対して、次のように大/小文字を区別した検索を実行します。 

SQL> SELECT word FROM test1 WHERE word='GROSSE';

WORD
------------
GROSSE

NLS_UPPER関数を使用し、GROSSEに対して大/小文字を区別しない検索を実行します。 

SELECT word FROM test1
WHERE NLS_UPPER(word, 'NLS_SORT = XGERMAN') = 'GROSSE';

WORD
------------
GROSSE
Große
große

Oracle Databaseの照合には、大/小文字の区別がなく、アクセントの区別のないオプションが用意されています。次のタイプの言語照合があります。

  • ベース文字、発音区別記号、句読点およびケースに関する情報を使用する言語照合。これらは、「言語照合の使用」で説明した標準的な言語照合です。

  • ベース文字、発音区別記号、句読点に関する情報を使用するが大/小文字に関する情報を使用しない単一言語の照合と、ベース文字、発音区別記号に関する情報を使用するが句読点、大/小文字に関する情報を使用しない多言語照合およびUCA照合。このタイプのソートを、大/小文字を区別しないソートと呼びます。

  • ベース文字と句読点に関する情報のみを使用する単一言語照合、およびベース文字に関する情報のみを使用する多言語照合とUCA照合。このタイプのソートを、アクセントを区別しないソートと呼びます。(アクセントは発音区別記号と同義です。)大/小文字を区別しないソートと同様、アクセントを区別しないソートでもケースに関する情報は使用しません。

アクセントおよび大/小文字を区別しない多言語照合では、「無視可能文字」に記載されているように、句読点は無視されます。

この項の残りの部分は、次のトピックで構成されます。

5.5.1 例: 大/小文字およびアクセントを区別しない照合

後述の例は、次のソートを示しています。

  • ベース文字、発音区別記号、句読点およびケースに関する情報を使用する照合

  • 大/小文字を区別しない照合

  • アクセントを区別しない照合

例5-4 ベース文字、発音区別記号、句読点およびケース情報を使用した言語照合

次のリストは、ベース文字、発音区別記号、句読点およびケース情報を使用してソートされています。

blackbird
black bird
black-bird
Blackbird
Black-bird
blackbîrd
bläckbird

例5-5 大/小文字を区別しない言語照合

次のリストは、ベース文字、発音区別記号および句読点情報を使用し、ケースを無視してソートされています。

black bird
black-bird
Black-bird
blackbird
Blackbird
blackbîrd
bläckbird

black-birdとBlack-birdの違いはケースのみのため、照合では同じ値となります。この2つの値は、リストでどちらが前にきてもかまいません。Blackbirdとblackbirdの値も照合では同じ値となり、リストでどちらが前にきてもかまいません。

例5-6 アクセントを区別しない言語照合

次のリストは、ベース文字情報のみを使用してソートされています。発音区別記号、句読点およびケース情報は使用されていません。

blackbird
bläckbird
blackbîrd
Blackbird
BlackBird
Black-bird
Black bird

5.5.2 大/小文字またはアクセントを区別しない照合の指定

NLS_SORTセッション・パラメータを使用して、大/小文字またはアクセントを区別しない照合を指定します。

  • 大/小文字を区別しない照合の場合は、Oracle照合名に_CIを追加します。

  • アクセントも大/小文字も区別しない照合の場合は、Oracle照合名に_AIを追加します。

たとえば、NLS_SORTを次のタイプの値に設定できます。 

UCA0700_SPANISH_AI
FRENCH_M_AI
XGERMAN_CI

バイナリ照合でも、大/小文字またはアクセントを区別しないように指定できます。NLS_SORTの値としてBINARY_CIを指定すると、アクセントを区別するが大/小文字は区別しない照合を指定したことになります。BINARY_AIは、アクセントも大/小文字も区別しないバイナリ照合を指定します。文字セットのバイナリ照合順序が使用中の文字セットに適している場合は、バイナリ照合を使用します。

たとえば、NLS_LANG環境変数をAMERICAN_AMERICA.WE8ISO8859P1に設定し、次のようにtest2という表を作成して移入します。 

SQL> CREATE TABLE test2 (letter VARCHAR2(10));
SQL> INSERT INTO test2 VALUES('ä');
SQL> INSERT INTO test2 VALUES('a');
SQL> INSERT INTO test2 VALUES('A');
SQL> INSERT INTO test2 VALUES('Z');
SQL> SELECT * FROM test2;

LETTER
-----------
ä 
a
A
Z

NLS_SORTのデフォルト値はBINARYです。次の文を使用して、test2表内の文字のバイナリ照合を実行します。 

SELECT * FROM test2 ORDER BY letter;

NLS_SORTの値を変更するには、次のような文を入力します。 

ALTER SESSION SET NLS_SORT=BINARY_CI;

次の表に、NLS_SORTをBINARY、BINARY_CIおよびBINARY_AIに設定した結果得られる照合順を示します。

BINARY BINARY_CI BINARY_AI

A

a

ä

Z

A

a

a

Z

A

ä

ä

Z

NLS_SORT=BINARYの場合は、大文字が小文字の前にきます。発音区別記号付きの文字は最後に表示されます。

照合で発音区別記号は考慮されるが大/小文字は区別されない場合(BINARY_CI)は、発音区別記号付きの文字が最後に表示されます。

大/小文字区別と発音区別記号がどちらも無視される場合(BINARY_AI)、äはベース文字aを持つ他の文字でソートされます。ベース文字aを持つ文字はすべて、zの前にきます。

文字セットがUS7ASCIIまたはバイナリ照合と同じ照合順序を持つ文字セットの場合は、パフォーマンスを改善するためにバイナリ照合を使用できます。

次の表に、表のドイツ語照合の結果得られる照合順序を示します。

GERMAN GERMAN_CI GERMAN_AI

a

a

ä

A

A

a

ä

ä

A

Z

Z

Z

ドイツ語照合では、小文字が大文字の前にきて、äがZの前にきます。この照合で大/小文字区別と発音区別記号の両方が無視される場合(GERMAN_AI)、äはベース文字aを持つ他の文字を使用して表示されます。

5.5.3 例: 言語照合

この項の例は、バイナリ照合、単一言語照合および多言語照合を示しています。例を使用する準備として、表test3を作成して移入します。次の文を入力します。 

SQL> CREATE TABLE test3 (name VARCHAR2(20));
SQL> INSERT INTO test3 VALUES('Diet');
SQL> INSERT INTO test3 VALUES('À voir');
SQL> INSERT INTO test3 VALUES('Freizeit');

例5-7 バイナリ照合

ORDER BY句でバイナリ照合を使用します。 

SQL> SELECT * FROM test3 ORDER BY name;

次の出力が表示されるはずです。

Diet
Freizeit
À voir

バイナリ照合の結果、À voirがリストの最後に表示されることに注意してください。

例5-8 ドイツ語の単一言語照合

NLS_SORTパラメータをgermanに設定してNLSSORT関数を使用し、ドイツ語照合を取得します。 

SQL> SELECT * FROM test3 ORDER BY NLSSORT(name, 'NLS_SORT=german');

次の出力が表示されるはずです。

À voir
Diet
Freizeit

ドイツ語照合では、À voirがリストの先頭になることに注意してください。

例5-9 ドイツ語の単一言語照合とUCA照合の比較

次の図に示した文字列をtestに挿入します。この場合、横棒付きのDの後にñがきます。

図5-2 文字列の例

図5-2の説明が続きます
「図5-2 文字列の例」の説明

NLS_SORTパラメータをgermanに設定してNLSSORT関数を使用し、ドイツ語の単一言語照合を実行します。 

SELECT * FROM test2 ORDER BY NLSSORT(name, 'NLS_SORT=german');

ドイツ語照合からの出力では、新しい文字列がエントリ・リストの最後に表示されます。これは、その文字がドイツ語照合では認識されないためです。

次の文を入力してUCA照合を実行します。

SELECT * FROM test2
ORDER BY NLSSORT(name, 'NLS_SORT=UCA0700_DUCET');

出力では、UCAの順序に従って新しい文字列がDietの後に表示されます。

関連項目:

5.6 言語比較の実行

Oracle Database 12cリリース2 (12.2)以降、照合依存の操作では、その引数に関連付けられた照合から、使用する照合が決定されます。

照合は、表列またはビュー列の作成時にその列に対して宣言できます。関連付けられた照合では、列を処理する操作に列値が渡されます。操作では、一連の優先ルールを適用して、引数の照合に基づいて使用する照合が決定されます。同様に、文字値を戻す操作では、引数の照合から戻り値の照合が導出されます。

関連項目:

Oracle Databaseの照合アーキテクチャの詳細は、「列レベルの照合および大/小文字の区別」を参照してください。

照合依存の操作で、適用する照合が疑似照合USING_NLS_COMPであると決定された場合、NLS_COMPおよびNLS_SORTパラメータの値を参照して、使用する実際の名前付き照合が決定されます。この場合、照合はOracle Database 12cリリース1 (12.1)以前のリリースの場合と同様に決定されます。

NLS_COMPの設定によって、SQL操作でNLS_SORTを処理する方法が決定されます。NLS_COMPの有効値は次の3つです。

  • BINARY

    ほとんどのSQL操作では、NLS_SORTに設定された値に関係なく、バイナリ照合を使用して文字値が比較されます。これがデフォルトの設定です。

  • LINGUISTIC

    すべてのSQL操作では、NLS_SORTに指定された照合を使用して文字値が比較されます。たとえば、NLS_COMP=LINGUISTICおよびNLS_SORT=BINARY_CIの場合、照合依存のSQL操作ではバイナリ比較が使用されますが、文字の大/小文字は無視されます。

  • ANSI

    NLS_SORT設定に従うのは、一連の限られたSQL操作です。ANSIには下位互換性があります。

次の表に、これらの異なる設定を使用した場合のSQLまたはPL/SQL操作の動作の違いを示します。

表5-3 NLS_COMP設定を使用した言語比較の動作

SQLまたはPL/SQL操作 BINARY LINGUISTIC ANSI

集合演算子

-

-

-

UNION、INTERSECT、MINUS

バイナリ

NLS_SORTに従います

バイナリ

スカラー関数

-

-

-

DECODE

バイナリ

NLS_SORTに従います

バイナリ

INSTRx

バイナリ

NLS_SORTに従います

バイナリ

LEAST、GREATEST

バイナリ

NLS_SORTに従います

バイナリ

MAX、MIN

バイナリ

NLS_SORTに従います

バイナリ

NLS_INITCAP

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

NLS_LOWER

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

NLS_UPPER

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

NLSSORT

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

NULLIF

バイナリ

NLS_SORTに従います

バイナリ

REGEXP_COUNT

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

REGEXP_INSTR

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

REGEXP_REPLACE

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

REGEXP_SUBSTR

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

REPLACE

バイナリ

NLS_SORTに従います

バイナリ

RTRIM、TRIM、LTRIM

バイナリ

NLS_SORTに従います

バイナリ

TRANSLATE

バイナリ

NLS_SORTに従います

バイナリ

条件

-

-

-

=, !=, >, <, >=, <=

バイナリ

NLS_SORTに従います

NLS_SORTに従います

BETWEEN、NOT BETWEEN

バイナリ

NLS_SORTに従います

NLS_SORTに従います

IN、NOT IN

バイナリ

NLS_SORTに従います

NLS_SORTに従います

LIKE

バイナリ

NLS_SORTに従います

バイナリ

REGEXP_LIKE

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

CASE式

-

-

-

CASE

バイナリ

NLS_SORTに従います

バイナリ

分析関数句

-

-

-

DISTINCT

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

OVER(ORDER BY)

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

OVER(PARTITION BY)

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

副問合せ句

-

-

-

DISTINCT、UNIQUE

バイナリ

NLS_SORTに従います

バイナリ

GROUP BY

バイナリ

NLS_SORTに従います

バイナリ

ORDER BY

NLS_SORTに従います

NLS_SORTに従います

NLS_SORTに従います

関連項目:

各パラメータの詳細は、「NLS_COMP」および「NLS_SORT」を参照してください。

5.6.1 照合キー

比較条件が=、!=、>、<、>=、<=、BETWEEN、NOT BETWEEN、IN、NOT INの場合、問合せ句ORDER BYまたはGROUP BY、または集計関数COUNT(DISTINCT)は言語ルールに従って評価され、比較される引数値は、RAW値のような、照合キーと呼ばれるバイナリ値に変換されてからバイト単位で比較されます。

単一言語照合が適用されると、照合キーには、ソース値の文字の連結メジャー値の後に、これらの文字の連結マイナー値が続いて格納されます。多言語照合が適用されると、照合キーには、1次、2次および3次値が連結されて格納されます。UCA照合が適用されると、照合キーには、1次、2次、3次、および場合によっては4次値が連結されて格納されます。大/小文字を区別せず、アクセントを区別しない多言語照合およびUCA照合では、4次、3次および2次値が省略される場合があります。

照合キーは、NLSSORT関数で戻される値と同じ値になります。つまり、これらのSQL操作の言語動作を有効にすることは、それらの引数をNLSSORT関数のコールに含めるのと同じです。

関連項目:

「NLSSORT関数」

5.6.2 言語比較の精度の制限

照合キーはデータ型がRAWの値で、RAW値の最大長は初期化パラメータMAX_STRING_SIZEの値に応じて変わるため、照合キーの最大長もそのパラメータに従って制御されます。

MAX_STRING_SIZEがSTANDARDに設定されている場合は、照合キーの最大長は2000バイトに制限されます。ソース文字列全体から生成される照合キーの長さが最大長を超える場合、この文字列用に生成される照合キーは、値の最大接頭辞(先頭の部分文字列)に合せて計算されるため、計算結果が2000バイトを超えることはありません。

単一言語照合では、接頭辞は一般的に1000文字になります。複数言語照合では、接頭辞は一般的に500文字になります。UCA照合では、接頭辞は一般的に300文字になります。接頭辞の正確な長さは、特定の照合およびソース文字列に含まれる特定の文字によって増減する場合があります。照合キーの生成でこの方法を使用すると、照合キーを使用して言語動作を実行するSQL操作で、長い引数の終了部分が無視される場合があります。たとえば、先頭の1000文字が同じで、それ以降の任意の位置の値が異なる2つの文字列は、GROUP BY句で一緒にグループ化されます。

MAX_STRING_SIZEがEXTENDEDに設定されている場合、照合キーの最大長は32767バイトに制限されます。この設定では、照合キー生成は正確モードに切り換わります。ソース文字列全体から生成される照合キーの長さが最大長を超える場合、データベースでは、切り捨てられたキーを生成するのではなくORA-12742エラー・メッセージが生成されます。

5.6.3 ORA-12742エラーの回避

初期化パラメータMAX_STRING_SIZEがEXTENDEDに設定される正確モードでは、照合キー用に予約されたバッファが小さすぎる場合、ORA-12742エラーが発生して照合キーの生成は失敗します。これは、次の2つのケースで発生します。

  • 生成されるキーの長さが32767バイトを超える場合

  • ソース文字列の長さから照合キーの長さを計算するために使用される拡大比が、指定された照合とソース文字列の組合せに対して低すぎる場合

最初のケースは、すべての言語照合においてソース文字列が長い場合に発生することがあり、これは、照合キーのほとんどがその作成元となるソース文字列よりも長くなるためです。この場合にORA-12742エラーを回避するには、照合される値の長さが次の制限を超えないようにします。

  • 照合BINARY_CIの場合は、21844バイト

  • 単一言語照合または多言語照合の場合は、4094バイト

  • UCA照合の場合は、1560バイト

2番目のケースは、すべてのUCA0610およびUCA0620照合とUCA0700_DUCETおよびUCA0700_ROOT照合のすべての長さの文字列に対して発生する場合があります。このケースは、前述のUCA照合のペシミスティック拡大比が非常に高いために発生します。ペシミスティック照合キーの計算にペシミスティック拡大比を使用すると、言語索引付けが可能な列の最大長が大幅に短くなります。そのため、これらの照合には低い比率が使用され、これは4つの特定の互換文字(日本語1文字、韓国語1文字、アラビア語2文字)のうちの1つ以上を含む文字列を除く、すべてのソース文字列で機能します。文字列にこれらの特定の文字が含まれていると、文字列の照合キー生成がORA-12742エラーによって失敗する可能性があります。

選択した拡大比より長い照合キーが生成されないように、UCA0700_DUCETおよびUCA0700_ROOT以外のUCA0700照合がカスタマイズされています。具体的には、UCA0700_ORADUCETおよびUCA0700_ORAROOT照合は、対応するUCA0700_DUCETおよびUCA0700_ROOT照合とほとんど同じバージョンであり、これらの照合では、問題となる4文字に対する照合の重み付けが軽くなっています。

ノート:

UCA照合を使用する場合は、UCA0700_DUCETおよびUCA0700_ROOTを除くUCA0700照合のみを使用することをお薦めします。

特定の照合に対して照合キーを生成できない文字値を列に挿入した場合、その照合を使用してその文字値を比較またはソートする問合せはすべて、ORA-12742エラーが発生して失敗します。特定のアプリケーション構成では、これはサービス拒否(DoS)攻撃に対する脆弱性につながる可能性があります。そのため、次のガイドラインに従うことが重要です。

  • 前述のように問題のあるUCA照合を使用せずに、限られた長さの列値のみを照合します

  • または、安全な値のみが表に挿入されることを動的に検証します

  • または、あるユーザーが入力した値によって別のユーザーが発行した問合せが中断されることのないように、アプリケーションを設計します

列にCHECK制約を作成することにより、その列に挿入される値の安全性を動的に検証できます。たとえば、次のような表を作成するとします。 

CREATE TABLE translation_string
(
   id NUMBER, 
   string VARCHAR2(32767), 
   CONSTRAINT check_string CHECK (VSIZE(NLSSORT(string COLLATE UCA0700_DUCET)) != -1) 
);

この場合、文字列の列で文字値の挿入または更新が行われると、チェック制約条件で照合キー生成がトリガーされます。問題のある値は、DMLでORA-12742エラーを引き起こし、この操作が失敗する原因となります。しかし、いったん正常に挿入または更新された後には、この値によってその後の問合せでORA-12742エラーが発生することはありません。

前述の例のcheck_string制約は、すべての照合に対してペシミスティック・チェックを実行します。これは、多くの照合にとってはペシミスティックすぎる場合があります。列で1つまたは2つの特定の照合が使用されることがわかっている場合は、それらの照合に対してのみ照合キーの生成を強制するようにチェック制約を変更できます。ただし、その場合には、アプリケーションで使用できる照合を制限する必要があります。

5.6.4 例: 言語比較

次に、異なるNLS_COMP設定を使用した動作の例を示します。

例5-10 バイナリ比較バイナリ照合

次に、バイナリ設定を使用した動作を示します。

SQL> ALTER SESSION SET NLS_COMP=BINARY;
SQL> ALTER SESSION SET NLS_SORT=BINARY;
SQL> SELECT ename FROM emp1;

ENAME
----------------------
Mc Calla
MCAfee
McCoye
Mccathye
McCafeé

5 rows selected

SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

ENAME
----------------------
McCoye

1 row selected

例5-11 言語比較の大/小文字区別なしのバイナリ照合

次に、大/小文字を区別しない設定を使用した動作を示します。

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=BINARY_CI;
SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

ENAME
----------------------
McCoye
Mccathye

2 rows selected

例5-12 言語比較のアクセント区別なしのバイナリ照合

次に、アクセントを区別しない設定を使用した動作を示します。

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=BINARY_AI;
SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

ENAME
----------------------
McCoye
Mccathye
McCafeé

3 rows selected

例5-13 戻す行が少なくなる言語比較

一部の操作では、言語ルールを適用すると、戻される行が少なくなる場合があります。たとえば、バイナリ設定の場合、次のようにMcAfeeとMcafeeは異なります。 

SQL> ALTER SESSION SET NLS_COMP=BINARY;
SQL> ALTER SESSION SET NLS_SORT=BINARY;
SQL> SELECT DISTINCT ename FROM emp2;

ENAME
----------------------
McAfee
Mcafee
McCoy

3 rows selected

ただし、大/小文字の区別なし設定の場合、McAfeeとMcafeeは同じです。 

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=BINARY_CI;
SQL> SELECT DISTINCT ename FROM emp2;

ENAME
----------------------
McAfee
McCoy

2 rows selected

この例では、McAfeeまたはMcafeeのいずれかがDISTINCT操作で戻される可能性があります。どちらが選択されるかを正確に保証することはできません。

例5-14 XSPANISHを使用した言語比較

バイナリ比較を使用した場合は文字が同じで、言語比較を使用した場合は文字が異なるケースがあります。たとえば、バイナリ設定では、Cindy、ChadおよびClaraの文字Cは、次のように、同じ文字Cを表します。 

SQL> ALTER SESSION SET NLS_COMP=BINARY;
SQL> ALTER SESSION SET NLS_SORT=BINARY;
SQL> SELECT ename FROM emp3 WHERE ename LIKE 'C%';

ENAME
----------------------
Cindy
Chad
Clara

3 rows selected

言語ルールが伝統的なスペイン語のXSPANISHに設定されているデータベース・セッションでは、chは、1文字として処理されます。この場合、Chadの文字cは、CindyやClaraの文字Cとは異なります。 

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=XSPANISH;
SQL> SELECT ename FROM emp3 WHERE ename LIKE 'C%';

ENAME
----------------------
Cindy
Clara

2 rows selected

またchという組合せの場合の文字cは、単独の文字cとは異なります。 

SQL> SELECT REPLACE ('character', 'c', 't') "Changes" FROM DUAL;

Changes
---------------------
charatter

例5-15 UCA0700_TSPANISHを使用した言語比較

文字chは、XSPANISHの場合と同様に、UCA照合の伝統的なスペイン語の順序に従って処理されます。 

SQL> ALTER SESSION SET NLS_COMP = LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT = UCA0700_TSPANISH;
SQL> SELECT ename FROM emp3 WHERE ename LIKE 'C%';

ENAME
--------------
Cindy
Clara

SQL> SELECT REPLACE ('character', 'c', 't') "Changes" FROM DUAL;

Changes
-----------
charatter

5.7 言語索引の使用

言語照合は言語固有であるため、バイナリ照合よりもデータ処理が増えます。ASCII文字のバイナリ・コードには文字の順序が反映されているため、言語ASCIIのバイナリ照合を使用すると正確で高速です。

複数言語のデータがデータベースに格納されている場合、アプリケーションでは、言語に応じて異なる照合基準に従い、SELECT...ORDER BY文から戻されたデータを照合できます。このようなソートは、言語索引を使用すると、パフォーマンスを低下させずに実現できます。列の言語索引によって、挿入と更新の操作速度が低下しますが、ORDER BY句およびWHEREを使用した言語照合のパフォーマンスは大幅に向上します。

英語以外の言語を使用する関数索引を作成できます。この索引は、NLS_SORTで決められている言語照合順序を変更しません。言語索引は単にパフォーマンスを向上させるためのものです。

次の文では、ドイツ語照合に基づいて索引が作成されます。

CREATE TABLE my_table(name VARCHAR(20) NOT NULL);
CREATE INDEX nls_index ON my_table (NLSSORT(name, 'NLS_SORT = German'));

CREATE TABLE文にNOT NULLを指定すると、索引が使用されるようになります。

索引の作成後に、次の例ようなSELECT文を入力します。 

SELECT * FROM my_table WHERE name LIKE 'Hein%' ORDER BY name;

この文は、言語索引を使用しない場合の同じSELECT文より速く結果が戻されます。

BINARY以外の名前付き照合collationを使用して列columnに標準索引を作成する場合、作成される索引は暗黙的に、次の式で作成されるファンクション言語索引になります。 

NLSSORT(column,'NLS_SORT=collation')

関連項目:

索引への列レベルの照合の影響の詳細は、「その他のデータベース・オブジェクトに対するデータ・バインドされた照合の影響」の「標準索引」を参照してください

この項の残りの部分は、次のトピックで構成されます。

5.7.1 言語索引でサポートされるSQL操作および機能

言語索引サポートは、次の照合依存のSQL操作およびSQL機能で使用できます。

  • 比較条件: =、!=、>、<、>=、<=

  • 範囲条件: BETWEEN | NOT BETWEEN

  • IN | NOT IN

  • ORDER BY

  • GROUP BY

  • LIKE(LIKE、LIKE2、LIKE4、LIKEC)

  • DISTINCT

  • UNIQUE

  • UNION

  • INTERSECT

  • MINUS

次のリストのSQL関数では、言語索引を使用できません。

  • INSTR(INSTR、INSTRB、INSTR2、INSTR4、INSTRC)

  • MAX

  • MIN

  • REPLACE

  • TRIM

  • LTRIM

  • RTRIM

  • TRANSLATE

5.7.2 複数言語の言語索引

複数言語のデータに言語索引を作成する方法には、次の4通りがあります。

  • アプリケーションでサポートされている各言語の言語索引を作成します。このアプローチは単純ですが、大量のディスク領域が必要になります。索引ごとに、その索引が作成されている言語以外の言語の複数行が、順番の最後にまとめて照合されます。次の例では、フランス語とドイツ語の言語索引を作成しています。 

    CREATE INDEX french_index ON employees (NLSSORT(employee_id, 'NLS_SORT=FRENCH'));
CREATE INDEX german_index ON employees (NLSSORT(employee_id, 'NLS_SORT=GERMAN'));

    使用する索引は、ORDER BY句で指定したNLS_SORTセッション・パラメータまたはNLSSORT関数の引数によって決定されます。たとえば、NLS_SORTセッション・パラメータがFRENCHに設定されている場合、Oracle Databaseではfrench_indexが使用されます。GERMANに設定されている場合は、german_indexが使用されます。

  • すべての言語に対して単一言語索引を作成します。そのためには、NLSSORT関数のパラメータとして言語列(「例: フランス語の言語索引の設定」のLANG_COL)を使用する必要があります。この言語列には、索引の作成対象となる列のデータのNLS_LANGUAGE値が含まれます。次の例では、複数言語に対する単一言語索引を作成しています。の索引では、NLS_LANGUAGEに対して同じ値を持つ行がまとめてソートされます。 

    CREATE INDEX i ON t (LANG_COL, NLSSORT(col, 'NLS_SORT=' || LANG_COL));

    問合せでは、ORDER BY句で指定したNLSSORT関数の引数に基づいて索引が選択されます。

  • GENERIC_MやFRENCH_Mなどの多言語照合のいずれかを使用して、すべての言語に単一言語索引を作成します。この索引は、ISO 14651に定義されている規則に従って文字をソートします。たとえば、次のようにします。 

    CREATE INDEX i ON t (NLSSORT(col, 'NLS_SORT=GENERIC_M'));

    関連項目:

    詳細は、「多言語照合」を参照してください

  • UCA0700_ORADUCETやUCA0700_CFRENCHなどのUCA照合のいずれかを使用して、すべての言語に単一言語索引を作成します。これらの索引では、ISO 14651とUCA 7.0に準拠した順序で文字がソートされます。たとえば、次のようにします。 

    CREATE INDEX i
  ON t (NLSSORT(col, 'NLS_SORT=UCA0700_ORADUCET'));

    関連項目:

    詳細は、「UCA照合」を参照してください

5.7.3 言語索引の使用要件

言語索引を使用するための要件は、次のとおりです。

この項では、次の例についても説明します。

5.7.3.1 NLS_SORTを適切に設定

NLS_SORTパラメータで、言語照合に使用する言語定義を指定する必要があります。たとえば、フランス語の言語照合順序を使用する場合は、NLS_SORTをFRENCHに設定する必要があります。たとえば、フランス語の言語照合順序を使用する場合は、NLS_SORTをGERMANに設定する必要があります。

NLS_SORTを設定するには、複数の方法があります。すべての言語に同じSQL文を使用できるように、NLS_SORTをクライアントの環境変数として設定する必要があります。クライアント環境でNLS_SORTを設定すると、様々な言語索引を使用できます。

関連項目:

「NLS_SORT」

5.7.3.2 列がNOT NULLとして宣言されていない場合にWHERE句でNOT NULLを指定する方法

言語索引を持つ列でORDER BY column_name句を使用する必要がある場合は、次の例のようにWHERE句を含めます。 

WHERE NLSSORT(column_name) IS NOT NULL

列がスキーマ内でNOT NULL列として定義されていれば、このWHERE句は必要ありません。

5.7.3.3 適切なブロック・サイズでの表領域の使用

文字値から作成された照合キーの長さは、通常はこの値の数倍です。実際の長さの拡張は、使用する特定の照合およびソース値の内容に応じて異なり、ほとんどがUCAベースの照合により拡張されます。

言語索引を作成する場合、Oracle Databaseは、索引キーを形成する文字の列ごとに、照合キー(NLSSORT結果)の推定最大サイズを集計して、最初に索引キーの推定最大サイズを計算します。この計算では、最大バイト長nの文字の列の照合キーの最大サイズは、n*21+5(UCAベースの照合)およびn*8+10(その他の照合)と推定されます。

拡大比が大きいと、特にコンポジット(複数列)キーの場合に、最大索引キーのサイズが大きくなる可能性があります。同時に、索引の最大キー・サイズは、索引を含む表領域のブロック・サイズの約70%を超えることはできません。この場合は、ORA-1450エラーがレポートされます。このエラーを回避するには、言語索引を適切なブロック・サイズの表領域に格納してください(データベースのデフォルトのブロック・サイズより大きくなる場合があります)。必要なブロック・サイズnに対応する初期化パラメータDB_nK_CACHE_SIZEが適切に設定されている場合は、最適なデータベースをCREATE TABLESPACE文で作成できます。

関連項目:

5.7.3.4 例: フランス語の言語索引の設定

次の例では、フランス語の言語索引の設定方法を示します。ALTER SESSION文を使用するかわりに、NLS_SORTをクライアントの環境変数として設定することもできます。 

ALTER SESSION SET NLS_SORT='FRENCH';
CREATE INDEX test_idx ON test4(NLSSORT(name, 'NLS_SORT=FRENCH'));
SELECT * FROM test4 ORDER BY col;
ALTER SESSION SET NLS_COMP=LINGUISTIC;
SELECT * FROM test4 WHERE name > 'Henri';

ノート:

NLS_COMPがLINGUISTICに設定されている場合、SQL関数MAX()およびMIN()では、言語索引を使用できません。

5.8 言語の文字列検索

検索と照合は関連するタスクです。業務を適切に行うには、言語的に意味のある順序でデータを編成して処理する必要があります。言語的に意味のある方法によるデータの検索と照合は、適用される照合順序に依存します。

たとえば、cより後でfより前の文字列すべてを検索すると、NLS_SORTの値に応じて異なる結果が生成されます。ASCIIバイナリ照合では、dまたはeで始まる文字列が検出されますが、大文字のDまたはEまたはêのような発音区別記号付きeなどで始まる項目は除外されます。アクセントを区別しないバイナリ照合を適用すると、d、DおよびÊやêなどのアクセント付きeで始まる文字列がすべて戻されます。NLS_SORTをXSPANISHに設定して同じ検索を適用した場合は、chで始まる文字列も戻されます。これは、従来のスペイン語ではchがcとdの間を照合する複合文字として扱われるためです。この章では、Oracle Databaseの照合の種類と、各照合がSQLおよびSQL正規表現による文字列検索に与える影響について説明します。

関連項目:

5.9 多言語環境でのSQL正規表現

正規表現は、テキスト本体に含まれる文字列のパターンを識別する強力な方法を提供します。正規表現の用途には、San Franciscoのような文字列の単純検索や、すべてのURLを抽出する複雑なタスク、さらに2文字目に母音を含むすべての単語の検索などのタスクがあります。SQLとPL/SQLは、Oracle Databaseの正規表現をサポートしています。

従来の正規表現エンジンは、英語のテキストのみを処理するように設計されていました。ただし、正規表現の実装には、西欧のテキストとはまったく異なる特性を持った多様な言語を含めることができます。Oracle Databaseの正規表現の実装は、Unicode正規表現ガイドラインに基づいています。REGEXP SQL関数は、データベース文字セットおよび各国語文字セットとしてサポートされる文字セットをすべて処理します。さらに、Oracle Databaseでは、多言語データの照合に関する固有の言語要件を処理するために、POSIXの正規表現構成メンバーの照合機能が拡張されます。

次の項では、言語依存演算子のOracle拡張について説明します。

5.9.1 正規表現での文字範囲'[x-y]'

POSIX規格では、正規表現での範囲には、現行ロケールの言語定義による範囲の始点から終点までの照合要素がすべて含まれます。したがって、正規表現の範囲はバイト値の範囲ではなく言語上の範囲を意味します。これは、バイト値の範囲はプラットフォームに依存し、エンド・ユーザーが文字のバイト値の順序を知っているとは思われないためです。範囲式のセマンティクスは、文字セットから独立させる必要があります。これは、[a-d]などの範囲には、aからdのすべての文字、これらの文字に発音区別記号が付いたもの、伝統的なスペイン語におけるchのように1文字としてソートされる特殊ケースの照合要素が含まれる可能性があることを意味します。

Oracle Databaseでは、NLS_SORTパラメータで指定された範囲式が解析され、指定の範囲に含まれる照合要素が判別されます。たとえば、次のようにします。 

Expression:     [a-d]e
NLS_SORT:       BINARY
Does not match: cheremoya
NLS_SORT:       XSPANISH
Matches:        >>che<<remoya

5.9.2 正規表現での照合要素デリミタ'[. .]'

この構成メンバーは、照合要素を区切るためにPOSIX規格により導入されています。照合要素とは照合単位であり、ほとんどの場合は1文字に相当します。ただし、言語によっては、照合順序により2文字以上が1つの照合要素として定義される場合があります。従来の正規表現構文では、ユーザーは複数文字による照合要素が関係する範囲を定義できません。たとえば、chは2つの異なる文字として解析されるため、aからchは範囲として定義できません。

照合要素デリミタ[. .]を使用すると、複数文字による照合要素と他の要素を区切ることができます。たとえば、範囲aからchは、[a-[.ch.]]として記述できます。また、1文字の照合要素を区切る場合にも使用できます。定義済の照合要素でない複数言語による順序を[. .]で囲むと、正規表現ではセマンティック・エラーとみなされます。たとえば、abが定義済の複数文字による照合要素でない場合、[.ab.]は無効とみなされます。

5.9.3 正規表現での文字クラス'[: :]'

英語の正規表現では、範囲式を使用して文字クラスを示すことができます。たとえば、[a-z]を使用すると任意の小文字を指定できます。ただし、英語以外の正規表現では、その言語の照合順序でaが最初の小文字でzが最後の小文字でなければ、このアプローチを使用すると不正確になります。

POSIX規格では、明示的な文字クラスを移植性のある方法で指定できるように、新しい構文要素が導入されています。[: :]構文は、特定の文字クラスに属している文字セットを示します。文字クラス定義は、文字セットの分類データに基づきます。

5.9.4 正規表現での同値化クラス'[= =]'

Oracle Databaseは、POSIX規格で推奨される[= =]構文を介して同値化クラスもサポートしています。同値化クラスは、ベース文字とそのすべてのアクセント付きバージョンで構成されます。たとえば、同値化クラス[=a=]は、âおよびäと一致します。パフォーマンス上の理由で、現行の実装ではUnicodeの複合形式と分解形式の照合はサポートされません。たとえば、ä(aウムラウト)は、ウムラウトが続くaとは一致しません。

5.9.5 例: 正規表現

次の例に、正規表現の一致を示します。

例5-16 NLS_SORT値を使用した大/小文字を区別しない一致

Oracle Databaseの正規表現の一致では、大/小文字区別の有無は、NLS_SORT初期化パラメータとランタイム照合オプションの2つのレベルで決定されます。REGEXP関数は、デフォルトでNLS_SORTの値から大/小文字区別の動作を継承します。値は、ランタイム照合オプション'c' (大/小文字区別あり)または'i' (大/小文字区別なし)によって明示的に上書きすることもできます。 

Expression: catalog(ue)?
NLS_SORT: GENERIC_M_CI
Matches: 
>>Catalog<<
>>catalogue<<
>>CATALOG<<

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> ALTER SESSION SET NLS_SORT='GENERIC_M_CI';
SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'catalog(ue)?');

例5-17 ランタイム照合オプションで上書きされた大/小文字区別の有無

Expression: catalog(ue)?
NLS_SORT: GENERIC_M_CI
Match option: 'c'
Matches:
>>catalogue<<
Does not match: 
Catalog
CATALOG

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> ALTER SESSION SET NLS_SORT='GENERIC_M_CI';
SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'catalog(ue)?','c');

例5-18 照合要素演算子[..]を使用した照合

Expression: [^-a-[.ch.]]+  /*with NLS_SORT set to xspanish*/
Matches: 
>>driver<<
Does not match:
cab

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'[^-a-[.ch.]]+');

例5-19 文字クラス演算子[::]を使用した照合

この式では、小文字6文字からなる文字列が検索されます。アクセント付き文字は、小文字として一致することに注意してください。

Expression: [[:lower:]]{6}
Database character set: WE8ISO8859P1
Matches:
>>maître<<
>>mòbile<<
>>pájaro<<
>>zurück<<

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'[[:lower:]]{6}');

例5-20 ベース文字演算子[==]を使用した照合

Expression: r[[=e=]]sum[[=e=]]
Matches:
>>resume<<
>>résumé<<
>>résume<<
>>resumé<<

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'r[[=e=]]sum[[=e=]]');

関連項目:

  • 正規表現の構文の詳細は、『Oracle Database開発ガイド』を参照してください

  • REGEX SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

5.10 列レベルの照合および大/小文字の区別

列レベルの照合機能は、文字列の照合をその定義に指定します。この機能は、必要な場合にのみ言語処理を適用し、すべてのSQL文における特定の列データの一貫した処理を実現します。Oracleは、大/小文字およびアクセントを区別しない照合をサポートしています。このような照合を列に割り当てることにより、列値のすべての比較を大/小文字区別なしまたはアクセント区別なし、あるいはこれら両方で行うように容易に強制できます。

列レベルで宣言される照合は、より一般的なデータ・バインドされた照合アーキテクチャの一部であり、このアーキテクチャでは、照合はデータの属性(データ型に類似したもの)になります。宣言された照合では、列がSQL操作に渡され、他の操作の引数の照合とともに使用されて、操作で使用される照合が決定されます。

列レベルの照合機能はISO SQL標準に基づいており、この機能をサポートする他のデータベース・システムからOracle Databaseへのアプリケーションの移行が簡略化されます。この機能は、セッション・パラメータNLS_COMPおよびNLS_SORTを使用してSQLおよびPL/SQL操作の言語動作を制御するメカニズムと下位互換性があります。

この項では、次の項目について説明します。

5.10.1 データ・バインドされた照合について

Oracle Database 12cリリース1 (12.1)以前では、文字型のデータの比較および照合ルールは、2つのセッション・パラメータNLS_SORTおよびNLS_COMPによって決定されていました。これら2つのセッション・パラメータを使用して指定される照合は、セッション照合と呼ばれます。NLS_COMPの値は、NLS_SORTの値に指定された照合によって制御される操作と、BINARY照合を使用する操作を決定します。セッションで実行されるすべてのSQLおよびPL/SQL文のNLS_COMPの値によって選択される照合依存の操作では、すべて同じ照合が使用されます。

関連項目:

表5-3に、NLS_SORTの値に指定された照合を使用するSQLおよびPL/SQL操作を、NLS_COMPの値別に示しています。

Oracle Database 12cリリース2 (12.2)以降では、SQL操作への照合の適用をさらに細かく行うための新しいメカニズムが追加されました。照合は、データ型に類似したデータの属性です。照合は、表列などの文字データ・コンテナに対して宣言でき、その列を操作するすべてのSQL操作に渡されます。各照合依存の操作では、引数の宣言された照合を組み合せて、操作の処理に使用する照合が決定されます。さらに、文字値を戻す操作では、その引数の照合を組み合せて、結果に対する照合が導出されます。演算子COLLATEを使用すると、式の任意の場所に指定されている照合を上書きできます。

特定のデータに関連付けられるこのタイプの照合を、データ・バインドされた照合と呼びます。データ・バインドされた照合は、文字データ型VARCHAR2、CHAR、LONG、NVARCHAR2、NCHAR、CLOBおよびNCLOBの値にのみ適用できます。

ノート:

CLOBおよびNCLOB列に対して許可される照合は、後述の擬似照合USING_NLS_COMPのみです。

データ・バインドされた照合には次の2つのタイプがあります。

  • 名前付き照合: この照合は、照合名で指定された照合ルールの特定のセットです。名前付き照合は、NLS_SORTパラメータの値として指定される照合と同じです。名前付き照合として、バイナリ照合または言語照合を使用できます。

    • 名前付きバイナリ照合の例として、BINARY、BINARY_CI (大/小文字を区別しないバイナリ照合)およびBINARY_AI (アクセントおよび大/小文字を区別しないバイナリ照合)があります。

      関連項目:

      「バイナリ照合の使用」

    • 名前付き言語照合の例として、GENERIC_M、GENERIC_M_AI、FRENCH、POLISH、UCA0700_CFRENCHなどがあります。

      関連項目:

  • 疑似照合: この照合では、文字データ型の照合ルールを直接指定しません。かわりに、使用する実際の名前付き照合に対するセッション・パラメータNLS_SORTおよびNLS_COMPの値を確認する照合依存操作を指示します。疑似照合は、新しい宣言的な照合指定方法とセッション・パラメータを使用する古い方法の橋渡しとなります。

    サポートされている擬似照合は次のとおりです。

    • USING_NLS_COMP: USING_NLS_COMP擬似照合を使用する操作は、Oracle Database 12c (12.1)以前のリリースの場合と同様に動作します。すなわち、セッション照合を使用します。SQLまたはPL/SQL操作によって適用される特定の名前付き照合は、BINARYか、またはNLS_SORT、NLS_COMPの値および操作自体によって決定されます。

    • USING_NLS_SORT、USING_NLS_SORT_CI、USING_NLS_SORT_AIおよびUSING_NLS_SORT_CS: 操作で使用する照合として、これらの照合のいずれかが決定されると、その操作では、NLS_COMPパラメータの値を考慮せずに、NLS_SORTパラメータの値に指定された照合が適用されます。さらに、次のようになります。

      • 擬似照合がUSING_NLS_SORT_CIであり、NLS_SORTの値が_CIまたは_AIで終わらない場合、適用される照合の名前は、NLS_SORTの値の後に_CIを付加して構成されます。

      • 擬似照合がUSING_NLS_SORT_AIであり、NLS_SORTの値が_CIまたは_AIで終わらない場合、適用される照合の名前は、NLS_SORTの値の後に_AIを付加して構成されます。NLS_SORTの値が_CIで終わる場合は、接尾辞_CIが_AIに変更されます。

      • 擬似照合がUSING_NLS_SORT_CSであり、NLS_SORTの値が_CIまたは_AIで終わる場合、適用される照合の名前は、NLS_SORTの値からこの接尾辞を削除して構成されます。

      • それ以外の場合は、適用される照合の名前はNLS_SORTの値になります。

    ノート:

    • 接尾辞_CIは、大/小文字を区別しないことを表します。接尾辞_AIは、大/小文字およびアクセントを区別しないことを表します。接尾辞_CSは、大/小文字およびアクセントを区別することを表します。

    • 擬似照合USING_NLS_SORT_CIでは、NLS_SORTパラメータ値に指定された照合の、大/小文字を区別しないバージョンの使用が強制されます。

    • 擬似照合USING_NLS_SORT_AIでは、NLS_SORTパラメータ値に指定された照合の、大/小文字およびアクセントを区別しないバージョンの使用が強制されます。

    • 擬似照合USING_NLS_SORT_CSでは、NLS_SORTパラメータ値に指定された照合の、大/小文字およびアクセントを区別するバージョンの使用が強制されます。

5.10.2 デフォルトの照合

Oracle Database 12cリリース2 (12.2)以降、文字データ型の各表列には、宣言されたデータ・バインドされた照合が指定されます。(CREATE TABLE文またはALTER TABLE ADD文で)列を作成するDDL文に、列の照合が明示的に指定されていない場合、包含する表のデフォルトの照合が列に対して使用されます。表を作成するDDL文にデフォルトの照合が指定されていない場合、その表を所有するスキーマのデフォルトの照合が表のデフォルトの照合として使用されます。スキーマの所有者を作成するCREATE USER文に、スキーマのデフォルトの照合を指定します。CREATE USER文でスキーマのデフォルトの照合が指定されない場合は、照合USING_NLS_COMPが使用されます。

照合は、データベース・オブジェクトを作成するときにのみ継承されます。たとえば、表のデフォルトの照合を変更しても、表の既存の文字列の照合は変更されません。変更後に表に追加された新しい列のみが、新しいデフォルトの照合を継承します。同様に、スキーマのデフォルトの照合を変更しても、スキーマ内の表のデフォルトの照合は変更されません。変更後にスキーマ内に作成された新しい表のみが、新しいデフォルトの照合を継承します。

セッション・パラメータDEFAULT_COLLATIONは、「有効なスキーマのデフォルトの照合」で説明しているように、スキーマのデフォルトの照合を上書きします。

ノート:

Oracle Database 12cリリース2 (12.2)にアップグレードした後には、アップグレードされたデータベース内のすべての列、表およびスキーマにはUSING_NLS_COMP照合が指定されます。これにより、データベース内のすべての照合依存の操作がアップグレード前と同様に動作するようになります。すなわち、セッション照合を使用します。

5.10.3 データ・バインドされた照合の有効化

データ・バインドされた照合機能を有効にするには、次のデータベース初期化パラメータ値を設定します。

  • MAX_STRING_SIZE=EXTENDED

  • COMPATIBLE>=12.2

ノート:

  • データ・バインドされた照合機能を有効にしない場合、データベース・オブジェクトに対して照合を指定できず、DEFAULT_COLLATIONセッション・パラメータの値を設定できません。

  • データ・バインドされた照合機能を有効にするまでは、すべてのユーザー定義データベース・オブジェクトにはデータ・バインドされた照合USING_NLS_COMPが指定されます。ただし、Oracleが提供するデータベース・オブジェクトは、この照合のみを使用することが保証されていません。

  • データ・バインドされた照合機能を有効にしない場合でも、SQL文でCOLLATE演算子とCOLLATION()、NLS_COLLATION_ID()およびNLS_COLLATION_NAME()関数を使用できます。

  • データ・バインドされた照合機能をいったん有効にすると、無効にはできなくなるため、MAX_STRING_SIZEパラメータの値をSTANDARDに戻すことも、COMPATIBLEパラメータの値をOracle Databaseの以前のリリースに戻すこともできなくなります。

  • マルチテナント・コンテナ・データベース・ルート(CDBルート)では、MAX_STRING_SIZE初期化パラメータの実際の値が無視され、その値は常にSTANDARDであると想定されるため、データ・バイントされた照合機能は使用できません。ただし、PDBに対してMAX_STRING_SIZEパラメータ値が指定されていない場合は、PDBではCDBルートに対して指定されたMAX_STRING_SIZEが使用されます。

5.10.4 データ・バインドされた照合の指定

データ・バインドされた照合は、次のものに対して指定できます。

  • 表の列

  • クラスタ列

  • 表

  • スキーマ(所有ユーザーを通じて)

  • ビューおよびマテリアライズド・ビュー

  • プロシージャ、ファンクション、パッケージ、タイプ、トリガーなどのPL/SQLユニット

  • SQL式

ノート:

  • 照合は、クラスタには指定できませんが、クラスタのキー列には指定できます。

  • 照合は、データベース全体には指定できません。

この項では、次の項目について説明します。

5.10.4.1 有効なスキーマのデフォルトの照合

有効なスキーマのデフォルトの照合は、オブジェクトのデフォルトの照合がDDL文で明示的に宣言されていない場合に、特定のユーザー・セッションでDDL文を使用して特定のスキーマに作成されたデータベース・オブジェクトに割り当てられるデフォルトの照合です。有効なスキーマのデフォルトの照合は、対応するスキーマのデフォルトの照合と、セッションのDEFAULT_COLLATIONパラメータの値の組合せです。

セッションでDEFAULT_COLLATIONパラメータに値が指定されている場合、スキーマのそのセッションの有効なスキーマのデフォルトの照合は、DEFAULT_COLLATIONパラメータの値になります。セッションでDEFAULT_COLLATIONパラメータに値が指定されていない場合、そのセッションの有効なスキーマのデフォルトの照合は、対応するスキーマのデフォルトの照合の値になります。

パラメータDEFAULT_COLLATIONの値は、ALTER SESSION文を使用して指定できます。 

SQL> ALTER SESSION SET DEFAULT_COLLATION=collation_name;

collation_nameの値として、名前付き照合と擬似照合の両方を指定できます。

DEFAULT_COLLATIONパラメータに割り当てられた照合は、値NONEを割り当てることによって削除できます。 

SQL> ALTER SESSION SET DEFAULT_COLLATION=NONE;

DEFAULT_COLLATIONパラメータの現在の値は、セッションで次の文を使用してチェックできます。 

SQL> SELECT SYS_CONTEXT('USERENV', 'SESSION_DEFAULT_COLLATION') FROM DUAL;

ノート:

  • オブジェクトのデフォルトの照合が包含するスキーマのデフォルトの照合に依存しないようにする場合は、データベース・オブジェクトの作成中にDDL文を使用してそのデフォルトの照合を指定することをお薦めします。パラメータDEFAULT_COLLATIONは、照合を明示的に指定しないレガシー・スクリプトを処理する場合にのみ使用してください。

  • DEFAULT_COLLATIONパラメータによって指定されたセッションのデフォルト照合は、DBリンクを使用して現行のセッションに接続されているリモート・セッションには伝播されません。

5.10.4.2 スキーマへのデータ・バインドされた照合の指定

CREATE USER文およびALTER USER文でDEFAULT COLLATION句を使用して、スキーマのデフォルトのデータ・バインドされた照合を指定できます。スキーマのデフォルトの照合により、そのスキーマで作成される表、ビュー、マテリアライズド・ビュー、PL/SQLユニットおよびユーザー定義型(UDT)に明示的に宣言されたデフォルトの照合がない場合、これらのすべてのデータベース・オブジェクトにデフォルトとして割り当てられる、有効なスキーマのデフォルトの照合が決定されます。

スキーマのデフォルトの照合がCREATE USER文で明示的に指定されていない場合、これはUSING_NLS_COMP照合に設定されます。スキーマのデフォルトの照合は、ALTER USER文を使用して変更できます。この変更は、既存のデータベース・オブジェクトには影響せず、そのスキーマでその後に作成、置換またはコンパイルされるデータベース・オブジェクトにのみ影響します。

ノート:

  • セッションでDEFAULT_COLLATIONパラメータが指定されると、このパラメータによって、そのセッションで参照されるスキーマのデフォルトの照合が上書きされます。

  • スキーマにUSING_NLS_COMP以外のデフォルトの照合の宣言がある場合、そのスキーマにPL/SQLユニット(ユーザー定義型を含む)を作成できるのは、セッション・パラメータDEFAULT_COLLATIONがUSING_NLS_COMPに設定されているか、PL/SQLユニット作成のDDLにDEFAULT COLLATION USING_NLS_COMP句が含まれている場合のみです。

  • Oracleが提供するデータベース・ユーザーについては、スキーマのデフォルトの照合は変更できません。

例: スキーマへのデフォルトの照合の適用

CREATE USER hrsys
  IDENTIFIED BY password
  DEFAULT TABLESPACE hr_ts_1
  DEFAULT COLLATION BINARY
  ACCOUNT LOCK
-- the clauses after password can be in any order
/

この文は、新しいデータベース・ユーザーhrsysとそのスキーマを作成します。このスキーマのデフォルトの照合は、BINARYに設定されます。DEFAULT COLLATION句を含まない、スキーマで作成されたすべてのデータベース・オブジェクトでは、セッション・パラメータDEFAULT_COLLATIONによってデフォルトの照合が上書きされないかぎり、デフォルトの照合はBINARYに設定されます。

例: スキーマのデフォルトの照合の変更

ALTER USER hrsys DEFAULT COLLATION USING_NLS_COMP
/

この文は、hrsysスキーマのデフォルトの照合を擬似照合USING_NLS_COMPに変更します。この文が実行されると、DEFAULT COLLATION句を含まない、スキーマで作成されたすべてのデータベース・オブジェクトでは、セッション・パラメータDEFAULT_COLLATIONによってデフォルトの照合が上書きされないかぎり、デフォルトの照合はUSING_NLS_COMPに設定されます。既存のデータベース・オブジェクトのデフォルトの照合は、影響を受けません。

スキーマのデフォルトの照合は、いつでも変更できます。

関連項目:

5.10.4.3 表へのデータ・バインドされた照合の指定

CREATE TABLE文およびALTER TABLE文でDEFAULT COLLATION句を使用して、表のデフォルトのデータ・バインドされた照合を指定できます。表の文字の列に対して照合が明示的に宣言されていない場合、表のデフォルトの照合がその列に割り当てられます。CREATE TABLE文で表のデフォルトの照合が明示的に宣言されていない場合は、表の照合は有効なスキーマのデフォルトの照合に設定されます。

表のデフォルトの照合は、ALTER TABLE文を使用して変更できます。この変更は、既存の表列には影響せず、その後にALTER TABLE文を使用して表に追加される列または更新される列にのみ影響します。

例: 表の作成時における表へのデフォルトの照合の適用

CREATE TABLE employees 
( 
  emp_code   VARCHAR2(10) PRIMARY KEY, 
  first_name VARCHAR2(100), 
  last_name  VARCHAR2(200), 
  job_code   VARCHAR2(5) COLLATE BINARY, 
  dep_code   NUMBER
)
DEFAULT COLLATION BINARY_CI
-- other CREATE TABLE clauses
/

列emp_code、first_nameおよびlast_nameは、表のデフォルトの照合BINARY_CIを継承します。列job_codeは、照合BINARYで明示的に宣言されます。列emp_codeで宣言された主キー制約により、表内の行はemp_codeの値としてabcde123とABCDE123を同時に持つことを許可されません。

例: 表のデフォルトの照合の変更

ALTER TABLE employees DEFAULT COLLATION USING_NLS_COMP
/

この文は、表employeesのデフォルトの照合を擬似照合USING_NLS_COMPに変更します。ALTER TABLE文の実行後に表に追加される新しいVARCHAR2、CHAR、NVARCHAR2、NCHARおよびLONG列は、これらの列が明示的な照合を指定して宣言されているか、または外部キーに属している場合を除き、新しい照合を継承します。既存の列の照合は影響を受けません。

表のデフォルトの照合は、いつでも変更できます。

関連項目:

5.10.4.4 ビューおよびマテリアライズド・ビューへのデータ・バインドされた照合の指定

CREATE VIEW文およびCREATE MATERIALIZED VIEW文でDEFAULT COLLATION句を使用して、ビューおよびマテリアライズド・ビューのデフォルトのデータ・バインドされた照合を指定できます。

ビューまたはマテリアライズド・ビューのデフォルトの照合は、そのビューまたはマテリアライズド・ビューを定義する問合せに含まれているすべての文字リテラルの導出された照合として使用されます。ビューまたはマテリアライズド・ビューのデフォルトの照合は、そのビューまたはマテリアライズド・ビューの再作成によってのみ変更できます。

ノート:

  • ビューまたはマテリアライズド・ビューにデフォルトの照合が指定されていない場合は、これは有効なスキーマのデフォルトの照合に設定されます。

  • ビューまたはマテリアライズド・ビューのデフォルトの照合は、ビュー列では使用されません。ビュー列の照合は、そのビューの定義副問合せから導出されます。CREATE VIEWまたはCREATE MATERIALIZED VIEW文は、そのビューまたはマテリアライズド・ビューの文字の列のいずれかが、導出された照合がない定義副問合せの式に基づいている場合、エラーが発生して失敗するか、無効な状態で作成されます。

  • CREATE VIEWまたはCREATE MATERIALIZED VIEW文は、デフォルトの照合がUSING_NLS_COMP以外で、定義副問合せでWITH plsql_declarations句が使用されている場合、エラーが発生して失敗します。

例: ビューへの照合の適用

CREATE VIEW employees_j_polish_sort
 ( emp_code, first_name, last_name, job_code, dep_code )
 DEFAULT COLLATION BINARY
AS
 SELECT * FROM employees
 WHERE last_name LIKE 'j%'
 ORDER BY last_name COLLATE POLISH
/

表employeesの定義は前述のCREATE TABLEの例と同じであり、ビューemployees_j_polish_sortは姓が小文字または大文字のjで始まるすべての従業員を選択して、名前付き照合POLISHを使用してそれらをソートすると想定します。この照合は、ポーランド語のアクセント付き文字を正しく順序付けます。たとえば、óの順序はoとpの間になります。BINARYおよびBINARY_CI照合では、この順序はzの後になります。演算子COLLATEを指定しない場合、ORDER BY句は列last_nameの照合(BINARY_CI)に基づいて問合せ結果を順序付けします。

ビューのデフォルトの照合(BINARY照合)は、文字リテラル'j%'の照合を導出するためにのみ使用されます。ただし、リテラルの照合は、列の照合よりも優先順位が低くなります。列last_nameの照合(BINARY_CI)は、優先順位が高く、演算子LIKEによって使用されます。

関連項目:

5.10.4.5 列へのデータ・バインドされた照合の指定

次のものを使用して、文字データ型VARCHAR2、CHAR、LONG、CLOB、NVARCHAR2、NCHARおよびNCLOBの列に対して、データ・バインドされた照合を明示的に指定できます。

  • CREATE TABLEまたはALTER TABLE文の標準または仮想列定義のCOLLATE句。

    • 列に対してCOLLATE句を使用して列の照合が明示的に指定されていない場合、後述のケースを除いて、表のデフォルトの照合が列で使用されます。

    • 列にCLOBまたはNCLOBのデータ型がある場合は、その指定された照合をUSING_NLS_COMPにする必要があります。CLOB列およびNCLOB列のデフォルトの照合は、常にUSING_NLS_COMPであり、表のデフォルトの照合には依存しません。

    • SQLのLONGデータ型値では、CLOBデータ型への変換以外の演算子は許可されません。このため、LONG列の照合はSQL文で使用されません。ただし、LONGデータ型はPL/SQLのVARCHAR2(32767)と同じであるため、PL/SQLでは照合指定が必要です。したがって、Oracleは、%TYPEおよび%ROWTYPE属性を使用して照合指定をPL/SQLユニットに渡せるように、LONG列の照合指定をサポートしています。

      ノート:

      Oracle Database 12cリリース2 (12.2)では、PL/SQLユニットの%TYPEおよび%ROWTYPE属性を使用して参照される列については、USING_NLS_COMP照合のみをサポートしています。

    • 仮想列に対して照合もデータ型も明示的に指定されていない場合、または列がCREATE TABLE AS SELECT文によって作成された場合は、列が外部キーに属している場合を除き、列の定義式から照合が導出されます。列の定義式に導出された照合がない場合は、エラーがレポートされます。

    • 列が外部キーに属している場合、その明示的な照合指定では、参照先の主キーまたは一意制約の対応する列に対して宣言されたものと同じ照合を指定する必要があります。列が外部キーに属しており、明示的な照合指定がない場合、その照合は参照先の主キーまたは一意制約の対応する列から割り当てられます。列が、異なる照合指定を含む主キー制約または一意制約を参照する、複数の外部キー制約に属している場合は、エラーがレポートされます。

    例: 照合宣言のある列の追加

    ALTER TABLE employees ADD gender VARCHAR2(1) COLLATE BINARY_CI
/

    この文は、genderという名前の新しい列を表employeesに追加し、照合BINARY_CIを使用してそれを照合するように要求します。COLLATE句を指定しない場合、列employees.genderは表のデフォルトの照合を継承します。

    例: 列の照合の変更

    ALTER TABLE employees MODIFY job_code COLLATE BINARY_CI
/

    この文は、列employees.job_codeの照合をBINARY_CIに変更します。列が索引キー、パーティション化キー、外部キーまたは仮想列式に含まれる場合、この文は失敗します。

  • CREATE CLUSTER文のキー列定義のCOLLATE句。

    • クラスタ列に対してCOLLATE句を使用して列の照合が明示的に指定されていない場合、その列には、CREATE CLUSTER文に対する有効なスキーマのデフォルトの照合が使用されます。

    • クラスタ・キー列の照合は、クラスタ内で作成された表の対応する列の照合と一致する必要があります。

    例: クラスタの列への照合の適用

    CREATE CLUSTER clu1
( 
  id        VARCHAR2(10) COLLATE BINARY_CI,
  category  VARCHAR2(20)
)
SIZE 8192 HASHKEYS 1000000
-- other CREATE CLUSTER clauses
/

    列categoryの照合は、CREATE CLUSTERの実行時に有効なスキーマのデフォルトの照合から継承されます。クラスタclu1を含むスキーマが異なる明示的な照合が指定されて定義されているか、DEFAULT_COLLATIONセッション・パラメータに異なる照合が設定されている場合を除き、この有効なスキーマのデフォルトの照合は擬似照合USING_NLS_COMPです。

    ハッシュ・クラスタclu1に追加される表を定義するCREATE TABLE文では、CLUSTER句に表の2つの列を指定する必要があります。最初の列はデータ型VARCHAR2(10)で、照合BINARY_CIを使用して宣言される必要があり、2番目の列はデータ型VARCHAR2(20)で、クラスタ列clu1.categoryによって有効なスキーマのデフォルトの照合から継承される照合を使用して宣言される必要があります。2つの照合は、ハッシュ・クラスタ自体では使用されません。

ノート:

5.10.4.6 PL/SQLユニットへのデータ・バインドされた照合の指定

CREATE [OR REPLACE]文でDEFAULT COLLATION句を使用して、次のPL/SQLユニットに対してデータ・バインドされた照合を指定できます。

  • プロシージャ

  • ファンクション

  • パッケージ

  • タイプ

  • トリガー

VARRAYおよびネストした表タイプは、デフォルトの照合を適用するPL/SQLメソッドまたは複数の属性がないため、明示的に宣言されたデフォルトの照合はありません。パッケージ本体および型本体は、独自の照合がなく、対応する仕様部のデフォルトの照合を使用します。

Oracle Database 12cリリース2 (12.2)以降、CREATE [OR REPLACE] PROCEDURE | FUNCTION | PACKAGE | TYPE | TRIGGER文が正常に実行されるのは、有効なスキーマのデフォルトの照合が擬似照合USING_NLS_COMPであるか、CREATE文のDEFAULT COLLATION USING_NLS_COMP句によって有効なスキーマのデフォルトの照合が上書きされる場合のみです。この制限には、文字データ型のスカラー要素を含むVARRAYおよびネストした表が含まれます。

REUSE SETTINGS句を指定したALTER COMPILE文が発行されると、コンパイルするデータベース・オブジェクトについて、格納されたデフォルトの照合は変更されません。「PL/SQLタイプおよびユーザー定義型に対するデータ・バインドされた照合の影響」で説明している要件をオブジェクトが満たさない場合、データベース・オブジェクトのコンパイルは失敗します。たとえば、格納されたデフォルトの照合がUSING_NLS_COMPでない場合、またはPL/SQLコードで名前付き照合のある列に%TYPE属性が適用される場合は、データベース・オブジェクトのコンパイルは失敗します。

REUSE SETTINGS句なしでALTER COMPILE文が発行されると、コンパイルするデータベース・オブジェクトについて、格納されたデフォルトの照合は、文の実行時のオブジェクト所有者の有効なスキーマのデフォルトの照合と比較されます。それらが一致せず、PL/SQLユニットにDEFAULT COLLATION句が含まれていない場合は、エラーがレポートされ、文はオブジェクトをコンパイルせずに失敗します。それらが一致する場合は、コンパイルが続行されます。「PL/SQLタイプおよびユーザー定義型に対するデータ・バインドされた照合の影響」で説明している要件をオブジェクトが満たさない場合、コンパイルは失敗します。

Oracle Database 12cリリース2 (12.2)以降、プロシージャ、ファンクションおよびメソッドの文字データ・コンテナ(変数、パラメータ、戻り値など)はすべて、そのデータ・バインドされた照合が疑似照合USING_NLS_COMPであるかのように動作します。また、すべての文字属性は、そのデータ・バインドされた照合が擬似照合USING_NLS_COMPであるかのように動作し、オブジェクト属性を格納するリレーショナル表の列には擬似照合USING_NLS_COMPが割り当てられます。

ノート:

PL/SQLユニットにデフォルトの照合が指定されていない場合は、これは有効なスキーマのデフォルトの照合に設定されます。

関連項目:

5.10.4.7 SQL式へのデータ・バインドされた照合の指定

SQL式の評価中に、演算子の各文字引数と演算子の各文字結果には、関連するデータ・バインドされた照合があります。演算子が照合依存である場合、演算子の引数の照合により、その演算子によって使用される照合が決定されます。SQL式結果の導出照合は、式ツリー内の別のSQL演算子や最上位コンシューマ(たとえば、SELECT文のSQL文の句)など、結果のコンシューマに関連します。単純式や演算子結果などの式ノードの導出照合は、COLLATE演算子を使用して上書きできます。SQL式の評価中には、照合導出および照合決定ルールが使用されます。

この項では、次の項目について説明します。

5.10.4.7.1 照合導出

SQL操作の文字結果の照合を決定するプロセスを照合導出と言います。このような操作として、演算子、列参照、文字リテラル、バインド変数参照、関数コール、CASE式または問合せ句があります。

関連項目:

照合導出の詳細は、「SQL操作の照合導出および決定ルール」を参照してください。

5.10.4.7.2 照合決定

照合決定とは、照合依存操作の実行中に、適用する正しい照合を選択するプロセスです。照合依存操作には、SQL演算子、条件、組込み関数コール、CASE式または問合せ句などがあります。

関連項目:

照合決定の詳細は、「SQL操作の照合導出および決定ルール」を参照してください。

5.10.4.7.3 式評価とCOLLATE演算子

単純式や演算子結果などのすべての式ノードの導出照合は、COLLATE演算子を使用して上書きできます。COLLATE演算子は、CAST演算子がデータ型に対して行う処理を照合に対して行います。COLLATE演算子は、照合または擬似照合を名前で指定する必要があります。式の形式での動的照合指定は許可されません。これは、SQL関数NLSSORT、NLS_UPPER、NLS_LOWERおよびNLS_INITCAPに対する照合の指定方法とは異なります。

Oracle Database 12cリリース2 (12.2)以降では、SELECT文およびDML文で使用するSQL式の構文で、文字値式の照合を変更できるようになりました。複合式句の構文は、次のとおりです。 

{ (expr)
| { + | - | PRIOR } expr
| expr { * | / | + | - | || } expr
| expr COLLATE collation_name
}

collation_nameは、式exprの値に割り当てられる照合の名前です。名前に空白文字が含まれている場合は、名前を二重引用符で囲む必要があります。COLLATE演算子は、exprに対する標準照合導出ルールを使用してデータベースが導出した照合を上書きします。COLLATE演算子は、データ型VARCHAR2、CHAR、LONG、NVARCHAR2およびNCHARの式にのみ適用できます。文字データ型へのCOLLATEの引数の暗黙的な変換は行われません。COLLATE演算子の優先順位は他の単項演算子と同じですが、これは後置演算子であるため、すべての前置演算子が評価された後に評価されます。

関連項目:

5.10.4.7.4 COLLATION関数

Oracle Database 12cリリース2 (12.2)以降、関数COLLATIONは、文字式の導出された、データ・バインドされた照合を戻します。 

COLLATION( expr );

exprは文字データ型の式です。COLLATION関数は、exprの導出照合の名前をVARCHAR2の値として戻します。この関数は、疑似照合も戻します。UCA照合の名前は長い標準形式で戻され、照合名にすべての照合パラメータが含まれています。式ツリーの照合の競合により、式の照合が未定義の場合、この関数はNULLを戻します。

ノート:

  • COLLATION関数は、NLS_SORTパラメータによって設定される動的な照合ではなく、データ・バインドされた照合のみを戻します。このため、COLLATE USING_NLS_SORTとして宣言された列については、この関数は、セッション・パラメータNLS_SORTの実際の値ではなく、文字値USING_NLS_SORTを戻します。組込み関数SYS_CONTEXT('USERENV','NLS_SORT')を使用すると、セッション・パラメータNLS_SORTの実際の値を取得できます。

  • SQLで使用されるCOLLATION関数は、SQL文のコンパイル時に評価されます。

5.10.4.7.5 NLS_COLLATION_IDおよびNLS_COLLATION_NAME関数

Oracle Database 12cリリース2 (12.2)以降、2つの関数NLS_COLLATION_IDおよびNLS_COLLATION_NAMEを使用して、データ・ディクショナリに格納されている数値の照合IDを照合名に変換したり、照合名を照合IDに変換したりできます。

NLS_COLLATION_ID関数の構文は、次のとおりです。 

NLS_COLLATION_ID( expr );

exprは、VARCHAR2値として評価される必要のある式です。exprの値が照合名または擬似照合名として取得され、関数によって対応する照合IDが戻されます。照合名が無効な場合は、NULL値が戻されます。

NLS_COLLATION_NAME関数の構文は、次のとおりです。 

NLS_COLLATION_NAME( expr [,flag] );

exprは、NUMBER値として評価される必要のある式です。exprの値が照合IDとして取得され、関数によって対応する照合名または擬似照合名が戻されます。照合IDが無効な場合は、NULL値が戻されます。

オプションのパラメータflagは、VARCHAR2値として評価される必要があります。flagパラメータの値は、S、s、Lまたはlである必要があります。flagパラメータのデフォルト値はLです。このパラメータは、UCA照合に対する関数の動作を決定します。flagパラメータ値Sおよびsは、UCA照合名が短い形式(つまり、デフォルト値が指定されているすべてのUCA照合が省略された形式)で戻されることを意味します。flagパラメータ値Lおよびlは、UCA照合名が長い標準形式(つまり、デフォルト値が指定されているものも含め、すべてのUCA照合パラメータが含まれる形式)で戻されることを意味します。たとえば、UCA0610_DUCETとUCA0610_DUCET_S4_VS_BN_NY_EN_FN_HN_DN_MNは、それぞれ同じ照合の短い名前と長い名前です。

関連項目:

「UCA照合」

5.10.5 大/小文字を区別しないデータベース

Oracle Databaseは、BINARY_CI、BINARY_AI、GENERIC_M_CI、GENERIC_M_AI、UCA0700_DUCET_CI、UCA0700_DUCET_AIなどの大/小文字を区別しない照合をサポートしています。このような照合をSQL操作に適用することによって、アプリケーションは、大/小文字を区別しない方法で、文字列の比較および照合を実行できます。

Oracle Database 12cリリース2 (12.2)以降、大/小文字を区別しないデータ・バインドされた照合(接尾辞_CIまたは_AIの付いた照合)を列定義で指定することにより、常に大/小文字区別なしで比較されるように列を宣言できます。列照合は、明示的に指定されていない場合、表のデフォルト照合から継承され、その場合、表のデフォルト照合はスキーマのデフォルト照合から継承されます。この方法により、データベース内のすべての文字の列を、デフォルトで大/小文字を区別しないものとして簡単に宣言でき、大/小文字を区別した照合が必要な列についてのみ明示的な照合宣言を使用できます。

関連項目:

5.10.6 その他のデータベース・オブジェクトに対するデータ・バインドされた照合の影響

この項では、次のデータベース・オブジェクトに対する、データ・バインドされた照合を実装する列を参照した場合の影響を説明します。

永続オブジェクト

索引、パーティション、主キー、一意キー、参照制約、クラスタ、ゾーンマップなど、内容がデータベースに永続的に格納されるデータベース・オブジェクトは、一時的で変更されることもあるセッション・パラメータNLS_COMPおよびNLS_SORTの値に基づいてその内容を永続的に照合することはできません。このため、このようなオブジェクトのキー列に対して擬似照合が宣言されると、列の値は次に示すように照合され、グループ化されます。

照合グループ キー列の照合 使用する照合

グループ1

USING_NLS_COMP

USING_NLS_SORT

USING_NLS_SORT_CS

BINARY

グループ2

USING_NLS_SORT_CI

BINARY_CI

グループ3

USING_NLS_SORT_AI

BINARY_AI

標準索引

標準索引、つまり、グループ1以外の照合を使用して宣言された列に定義されたBツリー索引は、自動的にファンクションNLSSORTに基づいたファンクション索引になります。この機能は、ビットマップ索引にも適用されます。NLSSORTファンクションは、索引キー列の照合が名前付き照合である場合はその照合を、または「永続オブジェクト」で定義されているように、照合BINARY_CIまたはBINARY_AIを使用します。

ノート:

グループ1の照合を使用して宣言された列に基づいて定義された索引は、標準バイナリ索引として作成されます。

たとえば、次のようなSQL文があるとします。

CREATE TABLE my_table
( 
  my_column VARCHAR2(100) COLLATE POLISH,
  ...
);

CREATE [UNIQUE|BITMAP] INDEX my_index ON my_table(my_column);

これは、次と同じになります。

CREATE TABLE my_table
( 
  my_column VARCHAR2(100) COLLATE POLISH,
  ...
);

CREATE [UNIQUE|BITMAP] INDEX my_index ON my_table(NLSSORT(my_column,'NLS_SORT=POLISH'));

グループ1の照合が指定された列とグループ1以外の照合が指定された列で構成される複合索引キーには、NLSSORTベースの式とプレーン列の両方が含まれます。

たとえば、次のようなSQL文があるとします。

CREATE TABLE my_table
( 
  id          VARCHAR2(20)  COLLATE USING_NLS_COMP,
  my_column   VARCHAR2(100) COLLATE POLISH,
  ...
);

CREATE [UNIQUE|BITMAP] INDEX my_index ON my_table(id, my_column);

これは、次と同じになります。

CREATE TABLE my_table
( 
  id         VARCHAR2(20)   COLLATE USING_NLS_COMP,
  my_column  VARCHAR2(100)  COLLATE POLISH,
  ...
);

CREATE [UNIQUE|BITMAP] INDEX my_index ON my_table(id, NLSSORT(my_column,'NLS_SORT=POLISH'));

ALTER TABLE MODIFY文を使用した索引キー列の照合の変更は、「永続オブジェクト」で定義されているグループと同じグループの照合間でのみ可能です。たとえば、照合BINARYをUSING_NLS_SORTに変更することはできますが、USING_NLS_SORT_CIまたはその他の名前付き照合には変更できません。照合を別の値に変更するには、最初に索引を削除する必要があります。

ビットマップ結合索引

ビットマップ結合索引定義では、照合BINARY、USING_NLS_COMP、USING_NLS_SORTおよびUSING_NLS_SORT_CSを含む列のみを参照できます。これらのいずれかの照合について索引キーが照合され、結合条件がBINARY照合を使用して評価されます。

ビットマップ結合索引キー列またはビットマップ索引結合条件で参照される列の照合は、索引定義で許可されている照合間でのみ、ALTER TABLE MODIFY文を使用して変更できます。

主制約および一意制約

名前付き照合を使用して宣言された列に定義された主制約および一意制約は、その照合を使用して、その列に挿入される値の一意性を決定します。この場合、主制約または一意制約は、バイナリ一意索引ではなく一意のファンクション索引を使用して実装されます。擬似照合を使用して宣言された列の主制約および一意制約は、「永続オブジェクト」で説明されているバイナリ照合のバリアントを使用します。

主キー列または一意キー列の照合は、外部キー制約が主キーまたは一意キーを参照していない場合にのみ、ALTER TABLE MODIFY文を使用して、前述の項で定義されている同じグループの照合間でのみ変更できます。照合を別の値に変更するには、最初に制約を削除する必要があります。

外部キー制約

外部キー制約は、キー値を比較する際に、参照先の主キー列または一意キー列の照合を使用します。外部キー値と参照先の主キー値の比較は、バイナリでなくてもかまいません。擬似照合を使用して宣言された列の外部制約は、「永続オブジェクト」で説明されているバイナリ照合のバリアントを使用します。外部キー列の照合は、ALTER TABLE MODIFY文を使用して変更できません。照合を変更するには、最初に制約を削除する必要があります。

ノート:

外部キー列の照合は、参照先の列の照合と同じである必要があります。この要件は、外部キー制約が定義されるときにチェックされます。

パーティション化

レンジ、リストおよび参照パーティション化では、パーティション化キーを構成する列の照合を使用して、適切なパーティションおよびサブパーティションに値を割り当てるための値の順序とパーティション・プルーニングのための値の順序を決定します。

Oracle Database 12cリリース2 (12.2)以降、レンジ、リストおよび参照パーティション化のパーティション化キー列には、照合BINARY、USING_NLS_COMP、USING_NLS_SORTまたはUSING_NLS_SORT_CSを指定する必要があります。これらすべての照合では、BINARY照合を使用してパーティション間で値が配布されます。

パーティション化キー列の照合は、許可されている照合間でのみ、ALTER TABLE MODIFY文を使用して変更できます。

ノート:

ハッシュ・パーティション化とシステム・パーティション化は照合依存ではないため、これらにはデータ・バインドされた照合は適用できません。

索引構成表(IOT)

索引構成表は、主キーの列および0個以上の追加の列を主キー索引に格納し、残りの列をヒープ構成オーバーフロー・セグメントに格納します。

Oracle Database 12cリリース2 (12.2)以降、IOTの主キー列には、照合BINARY、USING_NLS_COMP、USING_NLS_SORTまたはUSING_NLS_SORT_CSを指定する必要があります。これらすべての照合では、BINARY照合を使用して索引キー値が照合されます。

IOTの主キー列の照合は、許可されている照合間でのみ、ALTER TABLE MODIFY文を使用して変更できます。

クラスタ

Oracle Databaseは、ハッシュ・クラスタと索引クラスタをサポートしています。索引クラスタには索引があり、この索引内の文字キー列のキー値の順序は、照合に依存します。ハッシュ・クラスタは、表の行が数値のハッシュ関数に基づいてグループ化されるため、通常は照合依存ではありません。ただし、ユーザー定義ハッシュ関数の値は、関数が参照するキー列の照合に依存する場合があります。

また、ハッシュ・クラスタ列でSORT句を指定すると、DML操作を実行するときに、Oracle Databaseに対して、ハッシュ関数を適用した後でこれらの列でクラスタの行をソートするように指示できます。クラスタのすべての表に対して一貫性のあるハッシュおよび索引処理を行うには、宣言された照合を含むハッシュ・クラスタと索引クラスタの両方のキー列が、そのクラスタに格納されている表の対応する列の照合と一致する必要があります。

ノート:

  • Oracle Database 12cリリース2 (12.2)以降、BINARY、USING_NLS_COMP、USING_NLS_SORTまたはUSING_NLS_SORT_CS以外の照合を使用して宣言されたキー列を含む索引クラスタの作成はサポートされません。これと同じ制限は、SORT句が指定されているハッシュ・クラスタの列にも適用されます。SORT句が指定されていないハッシュ・クラスタのキー列では、任意の照合を使用できます。

  • ハッシュ・クラスタと索引クラスタには、デフォルトの照合はありません。通常、クラスタ・キーには少数の列しかなく、ALTER CLUSTERコマンドを使用してクラスタに新しい列を追加することはできません。このため、デフォルトの照合は、クラスタには適していません。クラスタの列のデフォルトの照合は、常に、有効なスキーマのデフォルトの照合から導出されます。

  • クラスタ・キーに対応する表の列の照合は、ALTER TABLE MODIFY文を使用して変更できません。

関連項目:

「有効なスキーマのデフォルトの照合」

表のクラスタリングおよびゾーンマップ

表のクラスタリングおよびゾーンマップでは、データ・バインドされた照合機能はサポートされません。クラスタリングとゾーンマップは、BINARYまたはUSING_NLS_COMP照合を使用して宣言された表の列にのみ適用できます。これらすべての照合では、BINARY照合に基づいて列値がクラスタ化されます。

Oracle Text索引および他のドメイン索引

Oracle Text索引およびその他のドメイン索引では、データ・バインドされた照合機能はサポートされません。ドメイン索引は、照合BINARY、USING_NLS_COMP、USING_NLS_SORTまたはUSING_NLS_SORT_CSを使用して宣言された表の列に対してのみ作成できます。Oracle Textでは、その処理にデータ・バインドされた照合は使用しません。Oracle Textには、照合動作を指定するための独自のメカニズムがあります。

その他の特定の表タイプ

デフォルトの表照合および列照合は、一時表および外部表に対しても指定できます。

ノート:

Oracle Database 12cリリース2 (12.2)では、ユーザー定義型(UDT)は疑似照合USING_NLS_COMPのみをサポートします。このため、常にユーザー定義照合タイプに基づいているネストされた表も、USING_NLS_COMP照合のみをサポートします。

関連項目:

5.10.7 分散問合せおよびDML操作に対するデータ・バインドされた照合の影響

分散問合せとDML操作には、12.2、12.1、およびそれ以前など、Oracle Databaseの異なるリリースの1つ以上のデータベース・ノードが関連する場合があります。問合せの各部分の評価がそれぞれ異なるノードで行われる可能性があり、特定の演算子を評価する特定のノードの決定は、オプティマイザの決定に従います。さらに、ローカル・ノードは通常、データベース・リンクを介して直接アクセスするノードのみを認識します。問合せで参照されるシノニムを介してアクセスされ、直接接続しているノードで定義されているリモート・ノードである間接ノードまたはマルチホップ・ノードは、ローカル・ノードには認識されません。

前述のシナリオ、および問合せ結果は決定的でなければならず、オプティマイザの決定に依存できないという要件を考慮して、Oracleでは問合せおよび副問合せに対して次の動作を定義しています。

  • データ・バインドされた照合機能が有効なOracle Database 12.2のノードを、データ・バインドされた照合機能が有効なOracle Database 12.2の別のノードに接続すると、データ・バインドされた照合に関連するすべての動作がサポートされます。

  • Oracle Database 12.1のノードまたはそれ以前のOracle DatabaseリリースのノードをOracle Database 12.2のノードに接続する場合、Oracle Database 12.2のノードは、問合せが以前のOracle Databaseリリースからのものであると認識します。このような問合せがUSING_NLS_COMP以外の照合が宣言されている列を参照すると、エラーがレポートされます。ただし、Oracle Database 12.2のリモート・ノードがDML文を受け取った場合は、その文は、USING_NLS_COMP以外の照合が宣言されている列を参照する場合でも評価されます。

  • Oracle Database 12.2のローカル・ノードをそれ以前のOracle Databaseリリースのリモート・データベース・ノードに接続すると、ローカル・データベース・ノードには、リモート・データベース・ノードからのすべての文字データには宣言された照合USING_NLS_COMPが指定されていると想定します。ローカル・データベース・ノードでは、COLLATEおよびNLS_COLLATION_NAMEなどの新しいSQL演算子がリモート・データベース・ノードに送信されないようにします。SQL文をリモート・ノード上で実行する必要があり(たとえば、リモート表でのDML操作など)、その文に新しいSQL演算子、またはUSING_NLS_COMP以外の照合を使用するローカル列への参照が含まれている場合は、エラーがレポートされます。

ノート:

前述のルールは、追加のデータベースがリモート・ノードで定義されたデータベース・リンクを介してアクセスされ、シノニムを介して参照されるときに再帰的に適用されます。

5.10.8 PL/SQLタイプおよびユーザー定義型に対するデータ・バインドされた照合の影響

Oracle Database 12cリリース2 (12.2)では、PL/SQLタイプとユーザー定義型(UDT)に対して、データ・バインドされた照合の限定的なサポートを提供します。Oracle Database 12cリリース2 (12.2)には、将来、新しい照合機能を使用するデータベース・オブジェクトでのPL/SQLの使用を制限することなく、データ・バインドされた照合のアーキテクチャをPL/SQLまで拡張する場合に備えて、PL/SQLコードの上位互換性を保つために必要な新機能のみが追加されています。

Oracle Database 12cリリース2 (12.2)では、データ・バインドされた照合をサポートするために、PL/SQLユニットおよびUDTに対する次の変更が実装されています。

  • PL/SQLプロシージャ、ファンクション、パッケージ、トリガーまたはUDTは、その作成時における有効なスキーマのデフォルトの照合がUSING_NLS_COMPであるか、その定義に明示的なDEFAULT COLLATION USING_NLS_COMP句が含まれている場合にのみ、有効なオブジェクトとして作成できます。結果的にデフォルトのオブジェクト照合がUSING_NLS_COMPと異なる場合、データベース・オブジェクトはコンパイル・エラーのため無効として作成されます。

    関連項目:

    「有効なスキーマのデフォルトの照合」

  • 埋込みSQLで使用される新しいSQL演算子COLLATE、COLLATION、NLS_COLLATION_IDおよびNLS_COLLATION_NAMEは、受け入れられてSQLエンジンに渡されますが、その機能をPL/SQLコードで使用することはできません。

  • USING_NLS_COMP以外の照合が宣言されているデータベース列は、埋込みSQLでは参照できますが、PL/SQL式では参照できません。

  • DMLの行レベルのトリガーは、USING_NLS_COMP以外の宣言された照合が含まれる列に対応する、OLD、NEWまたはPARENT疑似レコードまたは相関名のフィールドを参照できません。

  • 埋込みSQL文で参照されるPL/SQL変数には、擬似照合USING_NLS_COMPと照合順序強制性レベル2が指定されます。

  • %TYPE属性は、疑似照合USING_NLS_COMP以外の照合が宣言されている文字の列では使用できません。同様に、ROWTYPE属性は、USING_NLS_COMP以外の照合が宣言されている文字の列を少なくとも1つ含む表、ビュー、カーソルまたはカーソル変数では使用できません。USING_NLS_COMP以外の照合が指定された列は、これらの属性なしで宣言されたINTO句に対して選択できます。Oracle Database 12cリリース2 (12.2)では、PL/SQL変数には常にデフォルトの照合USING_NLS_COMPが指定されます。このため、選択した列の照合が何であっても、PL/SQL処理のために常に擬似照合USING_NLS_COMPで上書きされます。

  • カーソルのFOR LOOP文は、擬似照合USING_NLS_COMP以外の照合を含む結果セット列を戻すカーソルでは使用できません。

  • オブジェクト列またはオブジェクト表のいずれにおいても、UDT属性を格納するために作成された関係列は、属性の照合プロパティを継承します。ただし、Oracle Database 12cリリース2 (12.2)のUDTはすべて擬似照合USING_NLS_COMPを使用して作成されるため、UDT属性に関連するすべての列も擬似照合USING_NLS_COMPを使用して作成されます。

  • トリガーのWHEN条件は、SQLエンジンによって評価されるため、データ・バインドされた照合機能をサポートします。WHEN条件は、USING_NLS_COMP以外の照合が宣言されている列を参照でき、新しい演算子と関数を使用できます。

5.10.9 Oracle XML DBに対するデータ・バインドされた照合の影響

XML Query標準のXQueryは、XML Query式の照合依存演算子に対して照合を指定する機能を定義します。XQuery照合は、Oracle SQL関数NLS_UPPERの2番目のパラメータに照合を指定する方法と同様に、またはXQuery式の静的コンテキストのデフォルトの照合として、特定の演算子に対して指定できます。XQueryでは、データ・コンテナまたはデータ・ソースに対して照合を宣言するためのメカニズムは提供されません。このため、XMLQuery、XMLExistsまたはXMLTable演算子のPASSING句で引数として渡された、すべてのリレーショナル・データベース列の宣言された照合は、Oracle XML DBでは無視されます。