ヘッダーをスキップ
Oracle® Databaseグローバリゼーション・サポート・ガイド
12cリリース1 (12.1)
B71319-01
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

6 Unicodeを使用した多言語データベースのサポート

この章では、Oracle Database環境でのUnicode規格の使用方法について説明します。この章の内容は、次のとおりです。

Unicode規格とは

Unicode規格は、世界中で話されているほとんどの言語のあらゆる文字を定義する文字コード・システムです。

既存の文字エンコーディングの制約を克服するために、1980年代の後半、複数の組織がグローバル・キャラクタ・セットの作成に着手しました。グローバル・キャラクタ・セットの必要性は、1990年代中頃に入り、World Wide Webの発展とともにますます大きくなりました。インターネットの普及によってビジネスの形態が変化し、グローバル・マーケットに重点が置かれるようになったため、ユニバーサル・キャラクタ・セットが重要な必要条件になってきました。

このグローバル・キャラクタ・セットは、次の条件を満たす必要があります。

また、グローバル・キャラクタ・セットには次の機能も必要です。

現在幅広く使用されているUnicode規格は、グローバルなキャラクタ・セットの要件と機能のすべてを満たします。プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。文字プロパティと処理ルールもいくつか定義されており、複雑な多言語テキスト処理を正しく整合的に実装します。そのような複雑な処理の例には、双方向動作、単語分割、改行があります。

多くのソフトウェアおよびハードウェア・ベンダーがUnicode規格を採用しており、多くのオペレーティング・システムやブラウザがこの規格をサポートしています。Unicode規格は、XML、Java、JavaScript、LDAPおよびWMLなど他の規格には必須です。ISO/IEC 10646規格とも同期化されています。

Oracle Databaseでは、Oracle Database 7でデータベース・キャラクタ・セットAL24UTFFSS (現在では使用されません)として、Unicode規格の文字コードが導入されました。それ以来、各リリースで逐次的な改善が行われ、新しく公開されたバージョンの規格と同期するようにサポートされてきました。Oracle Database 12cでは、Unicode規格バージョン6.1のサポートを拡張し、Unicode照合アルゴリズム(UCA)準拠の新しい言語照合を導入しています。


関連項目:


Unicode規格の特長

この項の内容は、次のとおりです。

コード・ポイントと補助文字

Unicode規格の最初のバージョンは16ビットの固定幅エンコーディングで、各文字のエンコーディングに2バイトを使用していました。このため、65,536文字を表現できました。しかし、サポートを必要とする文字数が増え、特に中国語、日本語および韓国語市場では、追加のCJK表意文字のサポートが必要となりました。

Unicode規格の現在の定義では、規格で定義される各文字に番号が割り当てられています。この番号はコード・ポイントと呼ばれ、範囲0から10FFFFの16進数です。文字コード・ポイントを表すUnicode記法では、接頭辞「U+」に、16進数のコード・ポイント値を続けます。コード・ポイント値では、最小長の4になるまで、意味を持たない0を左側に追加します。コード・ポイントU+0000からU+FFFFの文字は、Basic Multilingual Plane文字と呼ばれます。コード・ポイントU+10000からU+10FFFFの文字は、補足文字と呼ばれます。

補足文字を追加したため、固定幅エンコード形式であるUnicode 16ビットは複雑化しました。しかし、Unicode以前に使用されていた何百ものレガシー・エンコーディングを管理するよりはるかに簡素です。

Unicodeエンコード形式

Unicode規格は、Unicodeコード・ポイントからコード単位へのマッピングであるいくつかのエンコード形式を定義します。コード単位は、アプリケーションで処理される整数値です。コード単位は、8、16、32ビットのいずれかです。標準のエンコーディング形式は、UTF-8、UTF-16およびUTF-32です。また、規格および関連のテクニカル・レポートで言及されている、2つの互換エンコーディングもあります(UCS-2とCESU-8)。Unicodeエンコーディング間の変換は、規格に定義されている単純なビット単位操作です。

この項の内容は、次のとおりです。

UTF-8エンコード形式

UTF-8は、Unicodeの8ビット・エンコード形式です。これは可変幅エンコーディングであり、ASCIIの完全なスーパーセットです。これは、ASCIIキャラクタ・セットの各文字を、UTF-8でも、同じバイト表現で使用できることを意味します。UTF-8エンコード形式では、1つのUnicode文字を、1バイト、2バイト、3バイトまたは4バイトで表現することができます。ヨーロッパおよび中東のスクリプトの文字は、1バイトまたは2バイトで表します。ほとんどのアジア言語の文字は、3バイトで表します。補助文字は、4バイトで表します。

UTF-8は、HTMLやほとんどのインターネット・ブラウザで使用されるUnicodeエンコーディングです。

UTF-8の利点は、次のとおりです。

UTF-16エンコード形式

UTF-16は、Unicodeの16ビット・エンコード形式です。UTF-16では、1つの文字を、1つの16ビット整数値(2バイト)と、2つの16ビット整数値(4バイト)のいずれかで表すことができます。Basic Multilingual Planeの文字(日常的なテキストで使用される文字の大部分)はすべて、2バイトで表されます。補助文字は、4バイトで表します。単一の補助文字をエンコードしている2つのコード単位(整数値)は、サロゲート・ペアと呼ばれます。

UTF-16は、バージョンJ2SE 5.0以降のJavaおよびバージョン2000以降のMicrosoft Windowsで内部処理に使用されているメインのUnicodeエンコーディングです。

UTF-8と比較したUTF-16の利点は、次のとおりです。

UCS-2エンコード形式

UCS-2は、公式のUnicodeエンコード形式ではありません。もともとの名前の由来は、補助文字が導入される前の、ISO/IEC 10646標準の以前のバージョンです。このため、現在では、補助文字とサロゲート・ペアのサポートから抽出された、UTF-16エンコード形式を指すために使用されています。つまり、サロゲート・ペアは、UCS-2では2つの別々の文字として処理されます。UCS-2はサポートしているがUTF-16はサポートしていないアプリケーションは、補助文字を含むテキストを処理しないようにします。テキストを分割する場合に場合サロゲート・ペアを不正確に分割する場合があるためです。通常は、そのようなテキストを表示することもできません。

UCS-2は、バージョンJ2SE 5.0より前のJavaおよびMicrosoft Windows NTで内部処理に使用されているUnicodeエンコーディングです。

UTF-32エンコード形式

UTF-32は、Unicodeの32ビット・エンコード形式です。各Unicodeコード・ポイントは、32ビット、固定幅の単一の整数値によって表されます。最も単純なエンコード形式ですが、容量の点では非常に非効率です。英語テキストの場合、記憶域要件は、UTF-8の4倍、UTF16の2倍です。このため、UTF-32は、内部テキスト処理の中間形式として使用されることはありますが、通常、情報交換のためには使用されません。

Javaでは、バージョンJ2SE 5.0以降、32ビット形式で文字を操作し、int値として格納するように一部のAPIが拡張されました。

CESU-8エンコード形式

CESU-8は、Unicode規格の中核には含まれていません。Unicodeテクニカル・レポート#26に記述されています。CESU-8は、補助文字の表現を除き、UTF-8と同一の互換エンコード形式です。CESU-8では、UTF-16と同様に、補助文字は、サロゲート・ペアとして表されます。補助文字のCESU-8エンコーディングを取得するには、まず文字をUTF-16にエンコードし、サロゲート・コード単位の各々を、同じ値を持つコード・ポイントとみなします。その後で、UTF-8エンコード規則(ビット変換)を各コード・ポイントに適用します。これにより、2つの3バイト表現(計6バイト)が得られます。

CESU-8の利点は2つのみです。

  • バイナリ・ソート順がUTF-16と同じです。

  • 1文字当たり、同じ数のコードを使用します(1または2)。これは、文字列処理の文字長セマンティクスにとって重要です。

一般に、CESU-8エンコード形式は、可能なかぎり使用しないようにします。

例: UTF-16、UTF-8およびUCS-2エンコーディング

図6-1に、UTF-16、UTF-8およびUCS-2の各エンコーディングの文字とその文字コードを示します。最後の文字はト音記号(音楽記号)で、補助文字です。

図6-1 UTF-16、UTF-8およびUCS-2エンコーディングの例

図6-1の説明は次にあります。
「図6-1 UTF-16、UTF-8およびUCS-2エンコーディングの例」の説明

Oracle DatabaseでのUnicode規格のサポート

Oracle Databaseのキャラクタ・セットとして、リリース7のときにUnicodeキャラクタ・セットのサポートを開始しました。表6-1に、Oracle DatabaseでサポートされているUnicodeキャラクタ・セットを示します。

表6-1 Oracle DatabaseでサポートされているUnicodeキャラクタ・セット

キャラクタ・セット サポートしているRDBMSのリリース Unicodeエンコード形式 Unicodeのバージョン データベース・キャラクタ・セット 各国語キャラクタ・セット

AL24UTFFSS

7.2 - 8i

UTF-8

1.1

可能

不可

UTF8

8.0 - 12c

CESU-8

Oracle Databaseリリース8.0からOracle8iリリース8.1.6の場合: 2.1

Oracle8i Databaseリリース8.1.7以上の場合: 3.0

可能

可能(Oracle9i Database以上のみ)

UTFE

8.0 - 12c

UTF-EBCDIC

Oracle8i Databaseリリース8.0から8.1.6の場合: 2.1

Oracle8i Databaseリリース8.1.7以上の場合: 3.0

はい(「注意1」を参照)

不可

AL32UTF8

9i - 12c

UTF-8

Oracle9i Databaseリリース1の場合: 3.0

Oracle9i Databaseリリース2の場合: 3.1

Oracle Database 10gリリース1の場合: 3.2

Oracle Database 10gリリース2の場合: 4.0

Oracle Database 11gの場合: 5.0

Oracle Database 12c: 6.1

可能

不可

AL16UTF16

9i - 12c

UTF-16

Oracle9i Databaseリリース1の場合: 3.0

Oracle9i Databaseリリース2の場合: 3.1

Oracle Database 10gリリース1の場合: 3.2

Oracle Database 10gリリース2の場合: 4.0

Oracle Database 11gの場合: 5.0

Oracle Database 12c: 6.1

不可

可能


注意1: UTF-EBCDICは、EBCDICベースのシステム(たとえばIBM z/OSまたはFujitsu BS2000)に固有の互換エンコード形式です。Unicodeテクニカル・レポート#16に記述されています。Oracleキャラクタ・セットUTFEは、エンコード形式UTF-EBCDICの部分的な実装で、ECBDICベースのプラットフォーム上でのみサポートされます。Oracle Databaseでは、このエンコーディング形式の5バイト・シーケンスはサポートされず、サポート対象のコード・ポイント範囲はU+000からU+3FFFFに制限されます。UTFEキャラクタ・セットは使用しないことをお薦めします。

Unicodeソリューションのデータベースへの実装

次の2つの方法でUnicode文字をOracle Databaseに格納できます。


注意:

単一のデータベースで動作している異なるアプリケーションで必要とされる場合、両方のUnicodeソリューションを結合できます。

次の項で、2つのUnicodeソリューションの使用方法とその選択方法を説明します。

データベース全体に対する多言語サポートの有効化

データベース・キャラクタ・セットでは、SQL CHARデータ型の他に、表名、列名およびSQL文などのメタデータに使用するエンコーディングが指定されます。Unicode規格対応のデータベースとは、Unicode規格に準拠したキャラクタ・セットをデータベース・キャラクタ・セットとして持つデータベースのことです。Unicode規格を実装するデータベースOracleキャラクタ・セットは2つあります。

  • AL32UTF8

    AL32UTF8 キャラクタ・セットは、UTF-8エンコード形式を実装し、最新バージョンのUnicode規格をサポートしています。このキャラクタ・セットは、各文字を1バイト、2バイト、3バイトまたは4バイトでエンコードします。このキャラクタ・セットでは、各文字は1バイト、2バイトまたは3バイトでエンコードされ、 補助文字には4バイトが必要です。ASCIIベースのプラットフォーム用です。

    AL32UTF8は、多言語アプリケーション(たとえば多国籍企業のインターネットWebサイトやアプリケーション)に最適なサポートを提供するため、Oracle Databaseのあらゆる新しいデプロイメントに対する推奨データベース・キャラクタ・セットです。

  • UTF8

    UTF8キャラクタ・セットはCESU-8エンコード形式を実装し、各文字を1バイト、2バイトまたは3バイトでエンコードします。ASCIIベースのプラットフォーム用です。

    UTF8データベースに挿入された補助文字は、CESU-8エンコード形式で格納されます。各文字は2つの3バイト・コードで表され、計6バイトのメモリーを占有します。

    UTF8キャラクタ・セットの文字のプロパティは、Unicode規格バージョン3.0以降の更新に対して保証されません。

    補助文字と最新版のUnicode規格を全面的にサポートするAL32UTF8への切替えをお薦めします。

例6-1 Unicodeキャラクタ・セットを使用したデータベースの作成

AL32UTF8キャラクタ・セットを使用してデータベースを作成するには、CREATE DATABASE文にCHARACTER SET AL32UTF8句を使用します。次に例を示します。

CREATE DATABASE sample 
CONTROLFILE REUSE 
LOGFILE 
GROUP 1 ('diskx:log1.log', 'disky:log1.log') SIZE 50K, 
GROUP 2 ('diskx:log2.log', 'disky:log2.log') SIZE 50K 
MAXLOGFILES 5 
MAXLOGHISTORY 100 
MAXDATAFILES 10 
MAXINSTANCES 2 
ARCHIVELOG
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16 
DATAFILE 
'disk1:df1.dbf' AUTOEXTEND ON, 
'disk2:df2.dbf' AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED 
DEFAULT TEMPORARY TABLESPACE temp_ts 
UNDO TABLESPACE undo_ts 
SET TIME_ZONE = '+00:00';

注意:

データベース・キャラクタ・セットは、データベースの作成時に指定します。

Unicodeデータ型を使用した多言語サポートの有効化

データベースにUnicodeデータを格納する代替方法は、SQL NCHARデータ型(NCHARNVARCHAR2NCLOB)を使用することです。データベース・キャラクタ・セットの定義方法に関係なく、これらのデータ型の列にUnicode文字を格納できます。NCHARデータ型はUnicodeデータ型専用です。つまり、このデータ型は、Unicodeエンコード形式でエンコードされたデータを格納します。

Unicode文字データを格納する場合は、AL32UTF8データベースでCHARVARCHAR2、およびCLOBの各SQLデータ型を使用することをお薦めします。一部のデータベース機能は、SQL NCHARNVARCHAR2およびNCLOBの各データ型をサポートしていません。とりわけ、Oracle TextとXML DBは、これらのデータ型をサポートしていません。

NVARCHAR2NCHARのデータ型を使用すると、表を作成できます。NCHAR列とNVARCHAR2列に指定する列の長さは、次のように常にバイト数ではなく文字数です。

CREATE TABLE product_information 
    ( product_id          NUMBER(6) 
    , product_name        NVARCHAR2(100) 
    , product_description VARCHAR2(1000));

SQL NCHARデータ型で使用するエンコーディングは、データベース用に指定される各国語キャラクタ・セットです。次のOracleキャラクタ・セットのいずれかを、各国語キャラクタ・セットとして指定できます。

  • AL16UTF16

    これはデフォルトのキャラクタ・セットで、SQL NCHARデータ型に対して推奨されます。このキャラクタ・セットは、UnicodeデータをUTF-16エンコーディング形式でエンコードします。また、4バイトとして格納される補助文字をサポートします。

  • UTF8

    SQL NCHARデータ型にUTF8を指定すると、SQLデータ型で格納されているデータは、CESU-8エンコーディング形式になります。UTF8キャラクタ・セットは非推奨です。

NATIONAL CHARACTER SET句を指定したCREATE DATABASE文を使用してデータベースを作成する場合は、SQL NCHARデータ型に各国語キャラクタ・セットを指定できます。次の文では、データベース・キャラクタ・セットとしてWE8ISO8859P1を持ち、各国語キャラクタ・セットとしてAL16UTF16を持つデータベースを作成します。

例6-2 各国語キャラクタ・セットを使用したデータベースの作成

CREATE DATABASE sample 
CONTROLFILE REUSE 
LOGFILE 
GROUP 1 ('diskx:log1.log', 'disky:log1.log') SIZE 50K, 
GROUP 2 ('diskx:log2.log', 'disky:log2.log') SIZE 50K 
MAXLOGFILES 5 
MAXLOGHISTORY 100 
MAXDATAFILES 10 
MAXINSTANCES 2 
ARCHIVELOG
CHARACTER SET WE8ISO8859P1
NATIONAL CHARACTER SET AL16UTF16 
DATAFILE 
'disk1:df1.dbf' AUTOEXTEND ON, 
'disk2:df2.dbf' AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED 
DEFAULT TEMPORARY TABLESPACE temp_ts 
UNDO TABLESPACE undo_ts 
SET TIME_ZONE = '+00:00';

Unicodeソリューションの選択

新しいOracle Databaseをすべてデータベース・キャラクタ・セットAL32UTF8でデプロイし、SQL VARCHAR2CHARCLOBデータ型を使用してキャラクタ・データを格納することをお薦めします。SQL NVARCHAR2NCHARおよびNCLOBの各データ型は、次の場合のみ検討してください。

  • データベース・キャラクタ・セットがUnicodeでない既存のデータベースとレガシー・アプリケーションがあって、Unicodeに移行するとビジネス・コストが過大になり、データベースを別々にしても意味がないようなアプリケーションのごく一部または小さな新規モジュールに対して、多言語データ・サポートを追加する必要がある場合、または

  • 多言語データをサポートし、顧客によってデプロイされた任意のOracle Databaseにインストールできる必要があるアプリケーションを作成する必要がある場合。

Unicode規格対応データベースのデータベース・キャラクタ・セットとしては、常にAL32UTF8を選択します。各国語キャラクタ・セットには、AL16UTF16を選択します。英語文字データの記憶域要件が低いため、非推奨のUTF8の選択を検討する場合、まず他のオプション(データ圧縮やディスク・ストレージの追加など)を検討します。データベースに多くのデータが蓄積される場合、後からAL16UTF16に移行しようとするとコストが高くつく場合があります。

Unicodeの事例

この項では、Unicode文字をOracle Databaseに格納する場合の代表的な使用例を説明します。

例6-3 Unicode規格対応データベースを使用したUnicodeソリューション

Javaアプリケーションを実行しているある米国の企業では、アプリケーションの次のリリースでドイツ語とフランス語のサポートを追加しようとしています。その後、日本語のサポートを追加する予定です。この会社には、現在次のようなシステム構成があります。

この場合、代表的なソリューションでは、次の理由により、データベース・キャラクタ・セットにAL32UTF8を選択します。

例6-4 Unicodeデータ型を使用したUnicodeソリューション

主としてWindowsプラットフォームでレガシー・アプリケーションを実行しているあるヨーロッパの企業で、Visual C/C++で作成された小さな新しいWindowsアプリケーションを追加する必要があります。このアプリケーションでは、日本語と中国語の顧客名をサポートするために、既存のデータベースが使用されます。この会社には、現在次のようなシステム構成があります。

代表的なソリューションでは、次のアクションが実行されます。

このソリューションを選択する理由は、次のとおりです。

複数言語サポートのためのデータベース・スキーマ設計

複数言語をサポートするようにデータベース・スキーマを設計する場合は、Unicodeソリューションの選択に加えて、次の問題も考慮する必要があります。

多言語データに使用する列の長さの指定

多言語データの格納にNCHARおよびNVARCHAR2データ型を使用する場合、列に指定するサイズは文字数で定義します。(この文字数はエンコードされたUnicodeコード・ポイントの数を意味しますが、サロゲート・ペアで表現されたUnicode補助文字は2文字として数えます。)表6-2に、AL16UTF16およびUTF8の各国語キャラクタ・セットに対するNCHARおよびNVARCHAR2データ型の最大サイズを示します。

表6-2 データ型の最大サイズ

各国語キャラクタ・セット NCHARデータ型の最大列サイズ NVARCHAR2データ型の最大列サイズ(MAX_STRING_SIZE = STANDARDの場合) NVARCHAR2データ型の最大列サイズ(MAX_STRING_SIZE = EXTENDEDの場合)

AL16UTF16

1000文字

2000文字

16383文字

UTF8

2000文字

4000文字

32767文字


この最大文字数は制約であり、データ型の容量を保証するものではありません。最大容量は、バイトで表されます。NCHARデータ型の場合、最大容量は2000バイトです。NVARCHAR2の場合、初期化パラメータMAX_STRING_SIZESTANDARDに設定されている場合は4000バイト、初期化パラメータMAX_STRING_SIZEEXTENDEDに設定されている場合は32767バイトです。各国語キャラクタ・セットがAL16UTF16である場合、最大文字数が最大容量のバイト数より多くなることはありません。Oracleにおける意味合いでは、各文字が正確に2バイトを占めるためです。ただし、各国語キャラクタ・セットがUTF8である場合、最大文字数を格納できるのは、これらすべての文字が、ASCII規格に対応するUnicode Basic Latinの範囲にある場合のみです。他のUnicode文字はUTF8ではそれぞれ複数バイトを占めるため、4000文字の文字列にそのような文字があると、文字列の長さが上限の4000バイトより長くなります。各国語キャラクタ・セットの列が、任意の各国語キャラクタ・セットにおいて、宣言された数の文字数を保持できるようにする場合は、2000/3=666文字より長いNCHAR列や、4000/3=1333または32767/3=10922文字(MAX_STRING_SIZE初期化パラメータにより異なる)より長いNVARCHAR2列を宣言しないでください。

多言語データの格納にCHARおよびVARCHAR2のデータ型を使用する場合、各列に指定する最大長は、デフォルトではバイト数で指定します。データベースで、タイ語、アラビア語、あるいは中国語や日本語などのマルチバイトの言語をサポートする必要がある場合は、CHARVARCHARおよびVARCHAR2の各列の最大サイズを拡張する必要があります。これは、これらの言語をUTF8またはAL32UTF8でエンコードするためのバイト数が、英語や西ヨーロッパの言語に比較してかなり多いためです。たとえば、タイ語キャラクタ・セットの1つのタイ文字は、UTF8またはAL32UTF8で3バイト必要です。アプリケーション・デザイナは、4000バイトを超えるデータを格納する必要がある場合、拡張文字データ型またはCLOBデータ型を使用することを考慮する必要があります。


関連項目:

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

  • MAX_STRING_SIZEの値をEXTENDEDに設定することによる文字データ型の拡張の詳細は『Oracle Databaseリファレンス』を参照してください。


複数言語のデータの格納

Unicodeキャラクタ・セットには、世界中で使用されているほとんどの記述言語の文字が含まれます。ただし、特定の文字が所属している言語に関する情報は含まれません。たとえば、äという文字には、それがスウェーデン語の文字なのかドイツ語の文字なのかに関する情報は含まれません。情報をユーザーが望む言語で表示するには、Unicodeデータベースに格納されているデータに、そのデータが所属している言語の情報をタグ付けする必要があります。

データベース・スキーマがデータを言語に関連付ける方法は多数あります。この先の項では、この目標を達成するための手順例を説明します。

言語情報をデータとともに格納

製品説明や製品名などのデータの場合は、CHARまたはVARCHAR2のデータ型の言語列(language_id)を製品表に追加して、対応する製品情報の言語を識別できます。これによって、アプリケーションは、必要な言語による情報を取り出すことができます。この言語列に可能な値は、データベースの有効なNLS_LANGUAGE値の3文字の略称です。


関連項目:

NLS_LANGUAGE値とその略称のリストは、付録A「ロケール・データ」を参照してください。

ビューを作成して、現在の言語のデータを選択することもできます。次に例を示します。

ALTER TABLE scott.product_information ADD (language_id VARCHAR2(50)):

CREATE OR REPLACE VIEW product AS 
   SELECT product_id, product_name 
   FROM   product_information 
   WHERE  language_id = SYS_CONTEXT('USERENV','LANG');

ファイングレイン・アクセス・コントロールを使用した変換済データの選択

ファイングレイン・アクセス・コントロールを使用すると、表またはビューでユーザーが参照できる情報の程度を制限できます。これは一般に、WHERE句を追加して行います。WHERE句をファイングレイン・アクセス・ポリシーとして表またはビューに追加すると、表にあるすべてのSQL文にそのWHERE句が実行時に自動的に追加されます。その結果、WHERE句を満たす行のみがアクセス可能になります。

この機能を使用すると、アプリケーションのSELECT文ごとに、ユーザーの必要な言語をWHERE句で指定しなくてすみます。次のWHERE句は、表のビューをユーザーが必要な言語に対応している行に制限しています。

WHERE language_id = SYS_CONTEXT('userenv', 'LANG')

このWHERE句をファイングレイン・アクセス・ポリシーとしてproduct_informationに対して次のように指定します。

CREATE FUNCTION func1 (sch VARCHAR2 , obj VARCHAR2 )
RETURN VARCHAR2(100);
BEGIN
RETURN 'language_id = SYS_CONTEXT(''userenv'', ''LANG'')';
END
/

DBMS_RLS.ADD_POLICY ('scott', 'product_information', 'lang_policy', 'scott', 'func1', 'select');

その結果、product_information表にあるすべてのSELECT文は自動的にWHERE句を追加します。


関連項目:

ファイングレイン・アクセス制御の詳細は、Oracle Database開発ガイドを参照してください

LOBデータ型への複数言語によるドキュメントの格納

複数言語によるドキュメントをCLOBNCLOBまたはBLOBデータ型に格納してOracle Textを設定すると、そのドキュメントの内容検索を使用できます。

データベース・キャラクタ・セットがUTF8やAL32UTF8などのマルチバイトである場合、CLOB列のデータはAL16UTF16キャラクタ・セットで格納されます。つまり、データの変換時には、英語のドキュメントに必要な記憶領域は2倍になります。アジア言語のドキュメントをCLOB列に格納する場合は、同じドキュメントをAL32UTF8を使用してLONG列に格納する場合に比較して、必要な記憶領域が少なくなります。ドキュメントの内容にもよりますが、通常およそ30%少なくなります。

NCLOB形式のドキュメントも、データベース・キャラクタ・セットや各国語キャラクタ・セットに関係なく、AL16UTF16キャラクタ・セットで格納されます。記憶領域の必要量は、CLOBデータの場合と同じです。ドキュメントの内容は、NCLOB列への挿入時に、UTF-16に変換されます。非Unicodeデータベースに多言語ドキュメントを格納する場合は、NCLOBを選択してください。ただし、Oracle Textを使用するNCLOB上でのコンテンツ検索はサポートされません。

BLOB書式のドキュメントは、そのまま格納されます。挿入時および取得時にデータ変換は発生しません。ただし、SQL文字列操作関数(LENGTHSUBSTRなど)と照合関数(NLS_SORTORDER BYなど)は、BLOBデータ型に適用できません。

表6-3に、ドキュメント格納時のCLOBNCLOBおよびBLOBデータ型のメリットとデメリットを示します。

表6-3 ドキュメント格納に関するLOBデータ型の比較

データ型 メリット デメリット

CLOB

  • Oracle Textでのコンテンツ検索サポート

  • 文字列操作がサポートされています。

  • データベース・キャラクタ・セットに依存します。

  • 挿入時にデータ変換が必要です。

  • バイナリ・ドキュメントは格納できません。

NCLOB

  • データベース・キャラクタ・セットに依存していません。

  • 文字列操作がサポートされています。

  • 内容検索がサポートされていません。

  • 挿入時にデータ変換が必要です。

  • バイナリ・ドキュメントは格納できません。

BLOB

  • データベース・キャラクタ・セットに依存していません。

  • 内容検索がサポートされています。

  • データ変換がなく、データをそのまま格納できます。

  • Microsoft WordやMicrosoft Excelなどのバイナリ・ドキュメントを格納できます。

  • 文字列操作がサポートされていません。


多言語ドキュメントの内容検索に使用する索引の作成

Oracle Textでは、索引を作成して、CLOB形式およびBLOB形式で格納されている多言語ドキュメントの内容を検索できます。言語固有のレクサーを使用して、CLOBBLOBのデータを解析し、検索可能なキーワードのリストを生成します。

多言語ドキュメントを検索するには、マルチレクサーを作成します。マルチレクサーは、言語列に基づいて、行ごとに言語固有のレクサーを選択します。この項では、複数言語のドキュメントに対して索引を作成するための高度な手順を説明します。内容は次のとおりです。

マルチレクサーの作成

マルチレクサーを作成する最初の手順は、サポート対象言語ごとに言語固有のレクサー・プリファレンスを作成することです。次の例では、英語、ドイツ語および日本語のレクサーをPL/SQLプロシージャで作成しています。

ctx_ddl.create_preference('english_lexer', 'basic_lexer'); 
ctx_ddl.set_attribute('english_lexer','index_themes','yes'); 
ctx_ddl.create_preference('german_lexer', 'basic_lexer'); 
ctx_ddl.set_attribute('german_lexer','composite','german'); 
ctx_ddl.set_attribute('german_lexer','alternate_spelling','german'); 
ctx_ddl.set_attribute('german_lexer','mixed_case','yes'); 
ctx_ddl.create_preference('japanese_lexer', 'JAPANESE_VGRAM_LEXER'); 

作成された言語固有のレクサー・プリファレンスは、単一のマルチレクサー・プリファレンスの下に集める必要があります。最初に、MULTI_LEXERオブジェクトを使用して、次のようにマルチレクサー・プリファレンスを作成します。

ctx_ddl.create_preference('global_lexer','multi_lexer'); 

ここで、add_sub_lexerコールを使用して、言語固有のレクサーをマルチレクサー・プリファレンスに追加します。

ctx_ddl.add_sub_lexer('global_lexer', 'german', 'german_lexer'); 
ctx_ddl.add_sub_lexer('global_lexer', 'japanese', 'japanese_lexer'); 
ctx_ddl.add_sub_lexer('global_lexer', 'default','english_lexer'); 

これによって、german_lexerプリファレンスはドイツ語ドキュメントを処理し、japanese_lexerプリファレンスは日本語ドキュメントを処理し、english_lexerプリファレンスは、言語にDEFAULTを使用して、それ以外のすべてのドキュメントを処理するように指名されます。

CLOBデータ型で格納されたドキュメントに対する索引の作成

マルチレクサーによって、表の言語列に基づいて、行ごとに使用するレクサーが決定されます。これは、テキスト列内のドキュメントの言語が格納されているキャラクタ列です。Oracleの言語名を使用して、この列にあるドキュメントの言語を識別します。たとえば、CLOBデータ型を使用してドキュメントを格納する場合は、言語列をそのドキュメントが格納されている表に追加します。

CREATE TABLE globaldoc
  (doc_id    NUMBER       PRIMARY KEY, 
  language  VARCHAR2(30), 
  text      CLOB); 

この表に索引を作成するには、次のようにマルチレクサー・プリファレンスを使用して言語列名を指定します。

CREATE INDEX globalx ON globaldoc(text) 
  indextype IS ctxsys.context 
  parameters ('lexer 
               global_lexer 
               language 
               column 
               language'); 

BLOBデータ型で格納されたドキュメントに対する索引の作成

言語列の他に、キャラクタ・セットと書式列を、ドキュメントが格納されている表に追加する必要があります。キャラクタ・セット列には、Oracleキャラクタ・セット名を使用してドキュメントのキャラクタ・セットを格納します。書式列には、ドキュメントがテキスト・ドキュメントであるかバイナリ・ドキュメントであるかを指定します。たとえば、CREATE TABLE文では、次のように列charactersetおよびformatを指定できます。

CREATE TABLE globaldoc ( 
   doc_id       NUMBER       PRIMARY KEY, 
   language     VARCHAR2(30), 
   characterset VARCHAR2(30), 
   format       VARCHAR2(10), 
   text         BLOB 
  ); 

ワードプロセッシングまたはスプレッドシートのドキュメントを表に入力し、format列にbinaryを指定できます。HTML、XMLおよびテキスト・フォーマットのドキュメントの場合は、表にドキュメントを入力して、format列にtextを指定します。

キャラクタ・セットを指定する列があるため、様々なキャラクタ・セットによるテキスト・ドキュメントを格納できます。

索引の作成時に、書式列とキャラクタ・セット列の名前を指定します。

CREATE INDEX globalx ON globaldoc(text) 
  indextype is ctxsys.context 
  parameters ('filter inso_filter 
                lexer global_lexer 
                language column language 
                format  column format 
                charset column characterset'); 

全ドキュメントがテキスト・フォーマットの場合は、charset_filterを使用できます。このcharset_filterによって、データはcharset列で指定されたキャラクタ・セットからデータベース・キャラクタ・セットに変換されます。