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

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

• Unicode規格とは

• Unicode規格の特長

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

• Unicodeの事例

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

6.1 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リリース2 (12.2)では、Unicode規格バージョン7.0のサポートを拡張し、Unicode照合アルゴリズム(UCA)準拠の新しい言語照合を導入しています。

関連項目:

• Unicode規格の詳細は、Unicode ConsortiumのWebサイトを参照してください

• Unicode照合アルゴリズムのサポートの詳細は「言語ソートと照合」を参照してください

6.2 Unicode規格の特長

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

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

• Unicodeエンコード形式

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

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

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以前に使用されていた何百ものレガシー・エンコーディングを管理するよりはるかに簡素です。

6.2.2 Unicodeエンコード形式

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

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

• UTF-8エンコード形式

• UTF-16エンコード形式

• UCS-2エンコード形式

• UTF-32エンコード形式

• CESU-8エンコード形式

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

6.2.2.1 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の利点は、次のとおりです。

• ASCIIの完全なスーパーセットであるため、ヨーロッパ言語の記憶要件が小規模です。

• ASCIIベースの文字セットとUTF-8の間の移行が容易です。

  関連項目:

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

  • 表B-2

6.2.2.2 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の利点は、次のとおりです。

• 一般に使用されるアジア言語の文字のほとんどは2バイトで表されるため、アジア言語の場合は記憶要件がさらに小規模です。

• JavaおよびMicrosoftクライアントとの優れた互換性があります。

  関連項目:

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

  • 表B-1

6.2.2.3 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エンコーディングです。

6.2.2.4 UTF-32エンコード形式

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

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

6.2.2.5 CESU-8エンコード形式

CESU-8は、Unicode規格の中核には含まれていません。Unicode Consortiumによって公開されている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エンコード形式は、可能なかぎり使用しないようにします。

関連項目:

Unicode ConsortiumのWebサイトで公開されている、Unicodeテクニカル・レポート#26「Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)」

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

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

図nlspg031.epsの説明

6.2.3 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, リリース1: 6.2 Oracle Database 12c, リリース2: 7.0	可能	不可
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, リリース1: 6.2 Oracle Database 12c, リリース2: 7.0	不可	可能

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

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

次の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ソリューションの使用方法とその選択方法を説明します。

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

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

• Unicodeソリューションの選択

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

データベース文字セットでは、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への切替えをお薦めします。

ノート:

• データベース文字セットは、データベースの作成時に指定します。データベースの文字セットには、AL32UTF8を使用することをお薦めします。AL32UTF8は、UnicodeのUTF-8エンコーディングの適切な実装です。Oracle Database12cリリース2以降では、Oracle Universal Installer (OUI)およびOracle Database Configuration Assistant (DBCA)を使用してデータベースを作成する際、デフォルトのデータベース文字セットとしてAL32UTF8が使用されます。

• UTF8はUnicodeのUTF-8エンコーディングの適切な実装ではないため、データベース文字セットとしてUTF8を使用しないでください。UTF-8処理が予期されている場合にUTF8文字セットが使用されると、データの消失およびセキュリティの問題が発生する場合があります。このことは、XMLやURLアドレスなどのWeb関連データに特に該当します。

• AL32UTF8およびUTF8文字セットは、最大文字幅が異なるため、相互に互換性がありません。AL32UTF8は最大文字幅4バイト、UTF8は最大文字幅3バイトです。

• CREATE DATABASE文にCHARACTER SET句を明示的に指定しない場合、データベース文字セットは(EBCDICプラットフォームを除いて)デフォルトでUS7ASCIIに設定されます。

例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';

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

データベースに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';

6.3.3 Unicodeソリューションの選択

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

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

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

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

ノート:

• データベースの文字セットには、AL32UTF8を使用することをお薦めします。AL32UTF8は、UnicodeのUTF-8エンコーディングの適切な実装です。Oracle Database12cリリース2以降では、Oracle Universal Installer (OUI)およびOracle Database Configuration Assistant (DBCA)を使用してデータベースを作成する際、デフォルトのデータベース文字セットとしてAL32UTF8が使用されます。

• UTF8はUnicodeのUTF-8エンコーディングの適切な実装ではないため、データベース文字セットとしてUTF8を使用しないでください。UTF-8処理が予期されている場合にUTF8文字セットが使用されると、データの消失およびセキュリティの問題が発生する場合があります。このことは、XMLやURLアドレスなどのWeb関連データに特に該当します。

• AL32UTF8およびUTF8文字セットは、最大文字幅が異なるため、相互に互換性がありません。AL32UTF8は最大文字幅4バイト、UTF8は最大文字幅3バイトです。

6.4 Unicodeの事例

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

• 使用例1: Unicode規格対応データベースを使用したUnicodeソリューション

• 使用例2: Unicodeデータ型を使用したUnicodeソリューション

使用例1: 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サポートはアプリケーションで自動的に有効化されます。

使用例2: 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文字列を使用する場合と同じです。この方法は、プログラミングの複雑さを軽減します。

• 既存のスキーマを使用している既存のアプリケーションに対する影響はないこと。

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

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

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

• 複数言語のデータの格納

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

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

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

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

次の表に、AL16UTF16およびUTF8の各国語文字セットに対するNCHARおよびNVARCHAR2データ型の最大サイズを示します。

表6-2 AL16UTF16およびUTF8の各国語文字セットに対するデータ型の最大サイズ

各国語文字セット	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リファレンス』を参照してください。

6.5.2 複数言語のデータの格納

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開発ガイド』を参照してください

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

複数言語によるドキュメントを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データ型に適用できません。

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

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

データ型	メリット	デメリット
CLOB	Oracle Textでのコンテンツ検索サポート 文字列操作がサポートされています	データベース文字セットに依存します。 挿入時にデータ変換が必要です。 バイナリ・ドキュメントは格納できません。
NCLOB	データベース文字セットに依存していません。 文字列操作がサポートされています	内容検索がサポートされていません。 挿入時にデータ変換が必要です。 バイナリ・ドキュメントは格納できません。
BLOB	データベース文字セットに依存していません。 内容検索がサポートされています データ変換がなく、データをそのまま格納できます。 Microsoft WordやMicrosoft Excelなどのバイナリ・ドキュメントを格納できます。	文字列操作がサポートされていません。

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

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

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

• マルチレクサーの作成

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

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

  関連項目:

  Oracle Textリファレンス

6.5.4.1 マルチレクサーの作成

マルチレクサーを作成する最初のステップは、サポート対象言語ごとに言語固有のレクサー・プリファレンスを作成することです。次の例では、英語、ドイツ語および日本語のレクサーを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を使用して、それ以外のすべてのドキュメントを処理するように指名されます。

6.5.4.2 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'); 

6.5.4.3 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列で指定された文字セットからデータベース文字セットに変換されます。