| Oracle® Databaseグローバリゼーション・サポート・ガイド 12cリリース1 (12.1) B71319-06 |
|
 前へ |
 次 |
この章では、Oracle Database環境でのUnicode規格の使用方法について説明します。この章の内容は、次のとおりです。
Unicode規格は、世界中で話されているほとんどの言語のあらゆる文字を定義する文字コード・システムです。
既存の文字エンコーディングの制約を克服するために、1980年代の後半、複数の組織がグローバル・キャラクタ・セットの作成に着手しました。グローバル・キャラクタ・セットの必要性は、1990年代中頃に入り、World Wide Webの発展とともにますます大きくなりました。インターネットの普及によってビジネスの形態が変化し、グローバル・マーケットに重点が置かれるようになったため、ユニバーサル・キャラクタ・セットが重要な必要条件になってきました。
このグローバル・キャラクタ・セットは、次の条件を満たす必要があります。
現在使用されているすべての主要文字を網羅していること。
レガシー・データや実装をサポートしていること。
1つのアプリケーションの1つの実装で、世界中で使用できるような単純なキャラクタ・セットであること。
また、グローバル・キャラクタ・セットには次の機能も必要です。
多言語ユーザーや組織のサポート
国際規格への準拠
世界規模でのデータ交換
現在幅広く使用されているUnicode規格は、グローバルなキャラクタ・セットの要件と機能のすべてを満たします。プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。文字プロパティと処理ルールもいくつか定義されており、複雑な多言語テキスト処理を正しく整合的に実装します。そのような複雑な処理の例には、双方向動作、単語分割、改行があります。
多くのソフトウェアおよびハードウェア・ベンダーがUnicode規格を採用しており、多くのオペレーティング・システムやブラウザがこの規格をサポートしています。Unicode規格は、XML、Java、JavaScript、LDAPおよびWMLなど他の規格には必須です。ISO/IEC 10646規格とも同期化されています。
Oracle Databaseでは、Oracle Database 7でデータベース・キャラクタ・セットAL24UTFFSS (現在では使用されません)として、Unicode規格の文字コードが導入されました。それ以来、各リリースで逐次的な改善が行われ、新しく公開されたバージョンの規格と同期するようにサポートされてきました。Oracle Database 12c (12.1.0.2)では、Unicode規格バージョン6.2のサポートを拡張し、Unicode照合アルゴリズム(UCA)準拠の新しい言語照合を導入しています。
関連項目:
Unicode規格の詳細は、http://www.unicode.orgを参照してください
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コード・ポイントからコード単位へのマッピングであるいくつかのエンコード形式を定義します。コード単位は、アプリケーションで処理される整数値です。コード単位は、8、16、32ビットのいずれかです。標準のエンコーディング形式は、UTF-8、UTF-16およびUTF-32です。また、規格および関連のテクニカル・レポートで言及されている、2つの互換エンコーディングもあります(UCS-2とCESU-8)。Unicodeエンコーディング間の変換は、規格に定義されている単純なビット単位操作です。
この項の内容は、次のとおりです。
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の利点は、次のとおりです。
ASCIIの完全なスーパーセットであるため、ヨーロッパ言語の記憶要件が小規模です。
ASCIIベースのキャラクタ・セットとUTF-8の間の移行が容易です。
関連項目:
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の利点は、次のとおりです。
一般に使用されるアジア言語の文字のほとんどは2バイトで表されるため、アジア言語の場合は記憶要件がさらに小規模です。
JavaおよびMicrosoftクライアントとの優れた互換性があります。
関連項目:
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は、Unicodeの32ビット・エンコード形式です。各Unicodeコード・ポイントは、32ビット、固定幅の単一の整数値によって表されます。最も単純なエンコード形式ですが、容量の点では非常に非効率です。英語テキストの場合、記憶域要件は、UTF-8の4倍、UTF16の2倍です。このため、UTF-32は、内部テキスト処理の中間形式として使用されることはありますが、通常、情報交換のためには使用されません。
Javaでは、バージョンJ2SE 5.0以降、32ビット形式で文字を操作し、int値として格納するように一部のAPIが拡張されました。
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エンコード形式は、可能なかぎり使用しないようにします。
Oracle Databaseのキャラクタ・セットとして、リリース7のときにUnicodeキャラクタ・セットのサポートを開始しました。表6-1に、Oracle DatabaseでサポートされているUnicodeキャラクタ・セットを示します。
表6-1 Oracle DatabaseでサポートされているUnicodeキャラクタ・セット
| キャラクタ・セット | サポートしているRDBMSのリリース | Unicodeエンコード形式 | Unicodeのバージョン | データベース・キャラクタ・セット | 各国語キャラクタ・セット |
|---|---|---|---|---|---|
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以上のみ) |
8.0 - 12c |
UTF-EBCDIC |
Oracle8i Databaseリリース8.0から8.1.6の場合: 2.1 Oracle8i Databaseリリース8.1.7以上の場合: 3.0 |
はい(「注意1」を参照) |
不可 |
|
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.2 |
可能 |
不可 |
|
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.2 |
不可 |
可能 |
注意1: UTF-EBCDICは、EBCDICベースのシステム(たとえばIBM z/OSまたはFujitsu BS2000)に固有の互換エンコード形式です。Unicodeテクニカル・レポート#16に記述されています。Oracleキャラクタ・セットUTFEは、エンコード形式UTF-EBCDICの部分的な実装で、ECBDICベースのプラットフォーム上でのみサポートされます。Oracle Databaseでは、このエンコーディング形式の5バイト・シーケンスはサポートされず、サポート対象のコード・ポイント範囲はU+000からU+3FFFFに制限されます。UTFEキャラクタ・セットは使用しないことをお薦めします。
次の2つの方法でUnicode文字をOracle Databaseに格納できます。
データベースを作成すると、UTF-8エンコードされた文字をSQL CHARデータ型(CHAR、VARCHAR2、CLOBおよびLONG)として格納できます。
Unicodeデータを、UTF-16またはCESU-8エンコード形式でSQL NCHARデータ型(NCHAR、NVARCHAR2とNCLOB)に格納できます。SQL NCHARデータ型は、Unicodeデータの格納専用に使用されるため、Unicodeデータ型と呼ばれます。
注意:
単一のデータベースで動作している異なるアプリケーションで必要とされる場合、両方の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データを格納する代替方法は、SQL NCHARデータ型(NCHAR、NVARCHAR2、NCLOB)を使用することです。データベース・キャラクタ・セットの定義方法に関係なく、これらのデータ型の列にUnicode文字を格納できます。NCHARデータ型はUnicodeデータ型専用です。つまり、このデータ型は、Unicodeエンコード形式でエンコードされたデータを格納します。
Unicode文字データを格納する場合は、AL32UTF8データベースでCHAR、VARCHAR2、およびCLOBの各SQLデータ型を使用することをお薦めします。一部のデータベース機能は、SQL NCHAR、NVARCHAR2およびNCLOBの各データ型をサポートしていません。とりわけ、Oracle TextとXML DBは、これらのデータ型をサポートしていません。
NVARCHAR2とNCHARのデータ型を使用すると、表を作成できます。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';
新しいOracle Databaseをすべてデータベース・キャラクタ・セットAL32UTF8でデプロイし、SQL VARCHAR2、CHARとCLOBデータ型を使用してキャラクタ・データを格納することをお薦めします。SQL NVARCHAR2、NCHARおよびNCLOBの各データ型は、次の場合のみ検討してください。
データベース・キャラクタ・セットがUnicodeでない既存のデータベースとレガシー・アプリケーションがあって、Unicodeに移行するとビジネス・コストが過大になり、データベースを別々にしても意味がないようなアプリケーションのごく一部または小さな新規モジュールに対して、多言語データ・サポートを追加する必要がある場合、または
多言語データをサポートし、顧客によってデプロイされた任意のOracle Databaseにインストールできる必要があるアプリケーションを作成する必要がある場合。
Unicode規格対応データベースのデータベース・キャラクタ・セットとしては、常にAL32UTF8を選択します。各国語キャラクタ・セットには、AL16UTF16を選択します。英語文字データの記憶域要件が低いため、非推奨のUTF8の選択を検討する場合、まず他のオプション(データ圧縮やディスク・ストレージの追加など)を検討します。データベースに多くのデータが蓄積される場合、後からAL16UTF16に移行しようとするとコストが高くつく場合があります。
この項では、Unicode文字をOracle Databaseに格納する場合の代表的な使用例を説明します。
例6-3 Unicode規格対応データベースを使用したUnicodeソリューション
Javaアプリケーションを実行しているある米国の企業では、アプリケーションの次のリリースでドイツ語とフランス語のサポートを追加しようとしています。その後、日本語のサポートを追加する予定です。この会社には、現在次のようなシステム構成があります。
既存のデータベースは、US7ASCIIのデータベース・キャラクタ・セットです。
既存のデータベースの全文字データは、ASCII文字で構成されています。
データベースでは、PL/SQLストアド・プロシージャが使用されています。
CLOB列にごくわずかなデータしか格納しない場合で、データベースはおよそ300GBです。
夜間の停止時間は4時間です。
この場合、代表的なソリューションでは、次の理由により、データベース・キャラクタ・セットにAL32UTF8を選択します。
データベースが非常に大規模で、予定されている停止時間が短いこと。Unicodeキャラクタ・セットへのデータベースの移行の高速化が不可欠です。データベースがUS7ASCIIなので、データベースのUnicode規格のサポートを有効化する最も簡単で迅速な方法は、Database Migration Assistant for Unicode (DMU)を使用して、データベース・キャラクタ・セットをAL32UTF8に切り替えることです。US7ASCIIはAL32UTF8のサブセットなので、CLOB以外の列のデータ変換は不要です。
コードの大部分がJavaとPL/SQLで記述されているため、データベース・キャラクタ・セットのAL32UTF8への変更によって、既存のコードが無駄になることはないこと。Unicodeサポートはアプリケーションで自動的に有効化されます。
例6-4 Unicodeデータ型を使用したUnicodeソリューション
主としてWindowsプラットフォームでレガシー・アプリケーションを実行しているあるヨーロッパの企業で、Visual C/C++で作成された小さな新しいWindowsアプリケーションを追加する必要があります。このアプリケーションでは、日本語と中国語の顧客名をサポートするために、既存のデータベースが使用されます。この会社には、現在次のようなシステム構成があります。
既存のデータベースには、WE8MSWIN1252のデータベース・キャラクタ・セットがあります。
既存のデータベースの全文字データは、西ヨーロッパの文字で構成されています。
多数のCLOB列がある場合で、データベースはおよそ500GBです。
新しいアプリケーションでは、フルテキスト検索とXML記憶域のサポートは必要ありません。
代表的なソリューションでは、次のアクションが実行されます。
NCHARおよびNVARCHAR2データ型を使用してUnicode文字が格納されます。
WE8MSWIN1252がデータベース・キャラクタ・セットとして維持されます。
AL16UTF16が各国語キャラクタ・セットとして使用されます。
このソリューションを選択する理由は、次のとおりです。
データベース・キャラクタ・セットのWE8MSWIN1252(Windows Latin-1キャラクタ・セット)はAL32UTF8のサブセットでないため、既存のデータベースをUnicodeデータベースに移行するには、データ変換が必要になること。また、多くのデータがCLOB列に格納されます。1バイト・データベース・キャラクタ・セットから移行する場合は(たとえばUS7ASCIIまたはWE8MSWIN1252からAL32UTF8へ)、ASCII文字のみを含む場合でも、データベースのすべてのCLOB値を変換する必要があります。その結果、データをAL32UTF8に変換するときに大きなオーバーヘッドが発生します。
追加した言語は、新しいアプリケーションでのみサポートされること。既存のアプリケーションまたはスキーマに依存しません。Unicodeデータ型は新しいスキーマで使用し、既存のスキーマは変更しないままのほうが簡単です。
Unicodeキャラクタ・セットのサポートが必要なのは、顧客名の列のみであること。1つのNCHAR列のみを使用することで、データベース全体を移行せずに顧客の要件を満たすことができます。
新しいアプリケーションでは、SQL NCHARデータ型をサポートしないデータベース機能は必要ありません。
SQL NCHARデータ型の長さは文字数として定義されること。この処理方法は、Windows C/C++プログラムでwchar_t文字列を使用する場合と同じです。この方法は、プログラミングの複雑さを軽減します。
既存のスキーマを使用している既存のアプリケーションに対する影響はないこと。
多言語データの格納に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_SIZEがSTANDARDに設定されている場合は4000バイト、初期化パラメータMAX_STRING_SIZEがEXTENDEDに設定されている場合は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のデータ型を使用する場合、各列に指定する最大長は、デフォルトではバイト数で指定します。データベースで、タイ語、アラビア語、あるいは中国語や日本語などのマルチバイトの言語をサポートする必要がある場合は、CHAR、VARCHARおよび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値とその略称のリストは、「ロケール・データ」を参照してください
ビューを作成して、現在の言語のデータを選択することもできます。次に例を示します。
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開発ガイドを参照してください
複数言語によるドキュメントをCLOB、NCLOBまたは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文字列操作関数(LENGTHやSUBSTRなど)と照合関数(NLS_SORTやORDER BYなど)は、BLOBデータ型に適用できません。
表6-3に、ドキュメント格納時のCLOB、NCLOBおよびBLOBデータ型のメリットとデメリットを示します。
表6-3 ドキュメント格納に関するLOBデータ型の比較
| データ型 | メリット | デメリット |
|---|---|---|
|
|
|
|
|
|
|
|
|
Oracle Textでは、索引を作成して、CLOB形式およびBLOB形式で格納されている多言語ドキュメントの内容を検索できます。言語固有のレクサーを使用して、CLOBやBLOBのデータを解析し、検索可能なキーワードのリストを生成します。
多言語ドキュメントを検索するには、マルチレクサーを作成します。マルチレクサーは、言語列に基づいて、行ごとに言語固有のレクサーを選択します。この項では、複数言語のドキュメントに対して索引を作成するための高度な手順を説明します。内容は次のとおりです。
関連項目:
『Oracle Textリファレンス』
マルチレクサーを作成する最初の手順は、サポート対象言語ごとに言語固有のレクサー・プリファレンスを作成することです。次の例では、英語、ドイツ語および日本語のレクサーを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を使用して、それ以外のすべてのドキュメントを処理するように指名されます。
マルチレクサーによって、表の言語列に基づいて、行ごとに使用するレクサーが決定されます。これは、テキスト列内のドキュメントの言語が格納されているキャラクタ列です。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');
言語列の他に、キャラクタ・セットと書式列を、ドキュメントが格納されている表に追加する必要があります。キャラクタ・セット列には、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列で指定されたキャラクタ・セットからデータベース・キャラクタ・セットに変換されます。
