JP2010128861A - 情報処理装置、データベース・システム、情報処理方法およびプログラム - Google Patents

Abstract

【課題】多言語対応可能な情報処理装置、データベース・システム、情報処理方法およびプログラムを提供する。
【解決手段】情報処理装置にアクセスするクライアントの言語環境を識別し、言語環境を設定する言語設定部１２０に、クライアントの言語環境を指定する言語識別値を設定するクライアント接続処理部１１６と、アクセス要求が含むスクリプトを検査し、多言語処理を要求するコマンドの存在を判断するコマンド処理部１１８と、コマンド処理部１１８が多言語処理を要求すると判断した場合に、コマンドを受領して、言語設定部に設定された言語環境によりデータベースにアクセスさせる言語リソース処理部１２６とを含んでいる。
【選択図】図１

Description

本発明は、情報処理装置を多言語対応させる技術に関し、より詳細には、情報処理装置が受領した言語種類を判断して、当該言語種類の情報を提供する情報処理装置、データベース・システム、情報処理方法およびプログラムに関する。

インターネットといった広域ネットワークが普及し、またブロードバンド通信も普及した現在、情報を蓄積し、配信するサーバなどの情報処理装置には、複数の言語圏からアクセスされることを想定する必要がある。このため、ウェブ・サーバなどの情報処理装置を介してコンテンツを提供しようとする者は、コンテンツ要求の言語を識別し、当該言語に翻訳されたコンテンツを検索し、検索されたコンテンツを、要求元に返す処理を行っている。

従来、コンテンツの検索のため、情報処理装置は、コンテンツ要求の言語を判断した後、ＵＲＬリダイレクトを使用して当該言語のコンテンツを管理するデータベース・サーバにリダイレクトし、翻訳されたコンテンツの検索を実行させ、検索されたコンテンツを情報処理装置に返す。情報処理装置は、データベース・サーバから受領したコンテンツを、コンテンツ要求元に返す処理を実行することで、コンテンツ要求元が使用する言語に対応するコンテンツの送付を可能とする。

このため、従来の多言語対応では、同一のコンテンツについて、異なる言語のウェブ・ページを作成し、それぞれのウェブ・ページごとに、異なる言語で翻訳された複数の異言語コンテンツを生成し、各言語ごとに索引付けを行って、分離したデータベースを構成させる必要があった。この結果、データベース・ベンダや情報処理装置のベンダは、同一のコンテンツについて、データ内容的には重複する複数のデータベースを構成し、さらに索引付けを行うことが必要とされていた。

また、例えば、特定のアプリケーション・プログラムのヘルプ表示などの場合のように、時系列的に追加させない静的コンテンツについてみれば、多言語処理を実行するためそれぞれの言語に翻訳されたヘルプ・メッセージなどのリソース・ファイルを用意しておくことができる。この目的で、例えば、情報処理装置が、例えば、Ｊａｖａ（登録商標）のResourceBundleなどの機能を実装し、ユーザが使用している言語体系に対応するリソース・ファイルを抽出し、表示させる。

一方、ウェブ・サーバなど、ネットワーク上でコンテンツを提供する情報処理装置では、近年、フォーラムやブログなど、ユーザ間またはユーザと情報処理装置との間のトランザクションに応じてコンテンツが更新される動的コンテンツの利用割合も増大している。また、インターネットの普及に伴ってウェブ・コンテンツとしてデータベースにアップロードされるコンテンツの種類や数も急激に増大している。

このようなコンテンツに対しては予めリソース・ファイルを予測することは困難であり、より効率的な言語対応処理が必要とされる。また、ウェブ・サーバなどウェブ・サービスを前提としてはいなくとも、例えば多国籍企業で複数の言語を使用する従業員を管理する場合にも、同様に複数の言語で記述されたデータベースを再構築する必要があるので、スキーマの変更やデータの冗長度の増加およびデータ同期化の問題が生じる。

この理由は、従来の多言語対応処理では、英語、日本語、中国語、ドイツ語、フランス語、イタリア語などの言語ごとに同一のコンテンツを提供するため異なる言語にコンテンツを翻訳し、各言語ごとにデータベース化し、また索引付け処理を実行する必要がある。このため、情報処理装置が対応するべき言語種類が増えることは、データ冗長度の増加を伴い、またそれぞれの索引付け処理も必要とされ、さらに各データベース間のデータ同期処理も必要となる。このため、ネットワークを介して転送されるコンテンツの量の増大と相俟って、従来の多言語対応処理は、情報処理装置の処理負荷を高める原因となっていた。一方、上述したデータの冗長性を排除する目的で、同一のデータベースで、多言語の情報を管理する従来技術も存在する。

図２７には、多言語対応のために利用されている従来のデータベースのデータ構造を示す。図２７に示した従来例は、多国籍企業における社員データベースのデータ構造を示しており複数の言語を、単一のデータベースで管理する場合の従来例である。図２７（ａ）のデータ構造は、社員番号に対して英語表記「John」が与えられており、それぞれ組織コード、電話番号などの連絡先情報などが対応付けられている。

図２７（ａ）に示す単一のデータベースで、多言語で記述された同一情報を登録したデータ構造を、図２７（ｂ）に示す。図２７（ｂ）に示すように同一の社員番号で識別される従業員について、英語で「John」を登録するレコードおよび日本語の翻訳である「ジョン」を登録するレコードが別々に生成され、各レコードについて、言語を指定する言語識別値が、「en」または「ja」として登録されている。

図２７（ｂ）で示すように、従業員を識別するため、図２７（ａ）でプライマリー・キーとして使用していた社員番号では、レコードを固有に識別することができなくなっていることがわかる。このため、同一のデータベースで複数の言語に対応する同一コンテンツを参照させるためには、図２７（ｂ）に示した従来例では、プライマリー・キーを、｛社員番号＋言語｝に拡張しなければならないことがわかる。この結果、このテーブルをアクセスするアプリケーションの修正が必要となる。また、アプリケーションが望む言語のデータがない場合、どうするかといった処理も実装する必要があり、データベースの設計コストの他にアプリケーションの設計・開発・メンテナンスコストも増大する。

加えて、データベースを単一にしたにも関わらず、同一コンテンツを登録するレコード数は対応するべき言語の分増加し、結局の所、複数のデータベースを形成する場合と大差ない冗長性を与えることになる。そして、索引付けやSQLなどの検索文も、検索要求やコンテンツ要求の言語に対応して行わなければならないという処理オーバーヘッドの増大も伴うことになる。さらに検索アプリケーションまたはウェブ・アプリケーション側で、対応する言語の登録がされていなかった場合にどのように対応するかについて、データベースとは独立して対応処理を実装させておく必要があった。

また、図２７（ｃ）で示すように、データの冗長性を排除するため、多言語で記述されるフィールドを、社員番号といったプライマリー・キーで紐付けした別のテーブルで管理することも行われている。この場合でも、結局の所、テーブルが複数化すること、各テーブルをプライマリー・キーを使用してジョインさせる必要があるため、データベースの設計コスト、アプリケーションの設計・開発・メンテナンスコストが増大する点では、図２７（ｂ）について説明した従来例と同様である。

これまで、各国の言語に対応する言語サービスを提供する技術が提案されており、例えば、特開２００３−４４４７４号公報（特許文献１）では、特定のクライアントおよびユーザ情報に関連付けられた言語情報を保存する動的な翻訳サービスの利用を通じてコンテンツ部の動的な言語翻訳を提供するため、動的な翻訳サービスはクライアントおよびユーザ情報に基づいて言語を確定し、コンテンツ部のコンテンツ要素を含むコンテンツ部のスケルトンを確定し、各スケルトンコンテンツ要素の保存された翻訳テーブルを利用するか、または各スケルトンコンテンツ要素の動的な自然言語翻訳を利用して、スケルトンコンテンツ要素がクライアントおよびユーザ情報に基づいて確定された言語に翻訳される。翻訳されたスケルトンコンテンツ要素は続いてコンテンツ部に統合するシステムが記載されている。

特許文献１は、クライアントの言語環境を識別し、クライアントの言語環境に対応した言語に翻訳し、コンテンツに統合する点を開示するが、翻訳されたコンテンツをどのように管理し、またコンテンツの追加、修正に対応して翻訳語間の同期を行うかについては開示するものではない。

また、特開平５−２４２１３９号公報（特許文献２）では、表示出力したいメッセージからなる組みをカテゴリ別と表示する国語の数だけ格納させ、サブコマンドの起動に伴ってメッセージのカテゴリ指定と出力したいメッセージの国語指定を参照すると共に、辞書を参照して記憶手段上に指定の国語のメッセージデータベースを生成する表示制御システムを開示する。特許文献２は、データベースを使用するアプリケーション側で、言語の翻訳を実行する点について開示するものの、各国語に対応したコンテンツを如何にして管理するかについて何ら開示するものではなく、各国語でのコンテンツの同期を効率化し、かつデータ冗長性を改善しながら効率的な各国言語対応を可能とするものではない。
特開２００３−４４４７４号公報 特開平５−２４２１３９号公報

上述したように、これまで、対応するべき言語種類が増大しても、データベースの主要なスキーマの変更を伴うことなく、データレコードの冗長性を排除し、データ同期化などのメンテナンス性を向上させ、さらに対応言語なしの処理を、より上位のアプリケーションとは独立して対応することができる、情報処理装置、データベース・システム、情報処理方法およびプログラムが必要とされていた。

上述した従来技術は、同一のコンテンツであるにも関わらず、言語の異なる異言語コンテンツを登録するため、独立したレコードを生成し、単一または分離したデータベースに登録する技術思想を採用することに起因する問題点である。上記従来技術の問題点は、本発明に従い、複数の言語に対応する複数のテーブルやレコードを用意することなく、複数の言語を単一のデータベース上で管理することが可能な情報処理装置、データベース・システム、情報処理方法およびプログラムを提供することにより解決される。

本発明では、上記目的を達成するために、情報処理装置を、情報処理装置にアクセスするクライアントの言語環境を識別し、言語環境を設定する言語設定部に、クライアントの言語環境を指定する言語識別値を設定するクライアント接続処理部を含んで構成する。

情報処理装置１１０は、クライアントからの接続を受け付けるクライアント接続処理部と、SQL文などのコマンドを受け付けるコマンド処理部と、コマンドが処理する言語環境の変更を要求する場合にその処理を行うレジスタ処理部と、コマンドがテーブルの作成などの操作やテーブルに対するデータの挿入・更新・削除・照会を行う要求の場合にその処理を行うテーブル処理部と、複数のテーブルのカラムから複数言語の値が管理されたリソース・テーブルにアクセスすることができ、コマンドがそのリソース・テーブルに対する操作を要求した場合にその処理を行う言語リソース処理部を実装する。本特許は、既存のデータベース・システムを拡張することで実現することができ、クライアントから受け付けるその他のコマンドは、従来どおりの処理を行う。

本発明では、複数言語の値を保存するためにテーブルのカラムのデータ・タイプとしてリソース・カラムを実装し、そのカラムを使用することで、複数言語の値を１つのカラムで管理することができる。また、複数のカラムが同一のリソースを参照できるように、リソースのみを別途管理して、それを複数のカラムから参照することもできる。リソースとは、意味付けされた複数言語の値の集合で、例えば、月の名前を複数言語で保持するものや、市の名前を複数言語で保持するものなどである。別途管理されるリソースが保持されるテーブルをリソース・テーブルと呼ぶ。この利用形態としては、社員情報テーブルの勤務地としてどの市に勤務しているかのカラムを保持させ、かつ、顧客情報テーブルの居住地としてどの市に住んでいるかのカラムを保持させた場合、各言語で市の名前を用意したリソースを定義し、両方のカラムがそのリソースを参照することができる。

この結果、同一の値についての異なる言語で記述された値が単一のテーブルの同一カラムに登録することができ、データベースの設計コストやアプリケーションの開発・設計・メンテナンスコストの増大を抑えることができる。

レジスタ処理部は、接続クライアントごとに各種変数を保持する。その変数として、２つの言語識別レジスタを実装する。以下、２つの言語識別レジスタを、言語識別レジスタCHARSETとデフォルト言語識別レジスタDEFAULT_CHARSETとして参照する。言語識別レジスタの値CHARSETおよびDEFAULT_CHARSETは、接続クライアントごとに保持される。言語識別レジスタの値CHARSETの値は、クライアントがデータベース・サーバに処理してほしいデフォルトの言語をセットする。クライアントがデータベースに接続すると、クライアントの言語環境がCHARSETの値として設定される。その後、変更したい場合は、クライアントからSQL本実施形態で導入する、言語変更コマンドであり、SET
CHARSET‘言語識別値’で変更することができる。

クライアントから送信されるコマンドには、本発明では、処理してほしい言語（言語識別値）を含めることができ、含まれていた場合は、その言語についての処理を行う。含まれていない場合は、CHARSETに設定されている言語についての処理を行う。したがって、各種アプリケーションは意識することなく自分の言語に合わせた処理を行うことができ、また、管理者がデータベースに接続して、各国語のデータを操作することもできる。

言語識別レジスタに実装されるDEFAULT_CHARSETは、要求する言語のデータが保存されていない場合に代替するための言語の値を設定するために利用する。利用形態としては２通りある。１つは、データを保存する際に、その保存する言語がDEFAULT_CHARSETに登録された値と同じであれば、デフォルト値としても保存し、参照する際、該当する言語のデータがない場合、保存されているデフォルト値を取得する方法である。例えばDEFAULT_CHARSETが英語に設定されており、英語のデータを挿入した場合、そのデータはデフォルト値としても保存される。

もう１つの方法は、データを参照する際に該当する言語のデータがない場合、言語識別レジスタに確保されたDEFAULT_CHARSETで設定されている言語のデータを取得する方法である。以下では、前者に基づいて説明する。

さらに本発明では、クライアントごとに異なるクライアント言語環境を提供するので、複数のクライアントの並列的なアクセスにおいても、個別的なアクセスを可能とする。

以上の構成を採用することにより、本実施形態によれば、多言語に対応するためのコンテンツを管理するデータベースのデータ冗長性をなくし、かつスキーマを単純にしつつ、クライアントに対して言語環境を意識することなくデータベースへのアクセスを可能とする、情報処理装置、データベース・システム、情報処理方法およびプログラムが提供できる。

以下、本発明について、実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。図１は、本実施形態のデータベース・システム１００の実施形態を示す。データベース・システム１００は、リレーショナル・データベース（以下、RDBとして参照する。）を実装する情報処理装置１１０と、RDBにより作成されたテーブルを格納するテーブル格納部１３０と、本実施形態により多言語対応するためのデータ構造を有するテーブルとして構成された言語リソースを格納する言語リソース・テーブル格納部１３２とを含んで構成されている。

情報処理装置１１０には、インターネット、ＬＡＮなどを適宜含むネットワーク１１２が接続されていて、ネットワーク１１２を介してクライアント・コンピュータ（図示せず。以下、単にクライアントとして参照する。）からのアクセス要求を受領し、テーブルの作成、編集、検索などのサービスを提供する。なお、テーブル格納部１３０と、言語リソース・テーブル格納部１３２およびこれらに対応する後述する各処理部は、図１では機能を説明する便宜上分離した機能モジュールとして記述するものであり、単一のデータベースの機能モジュールとして統合した実装形式を採用することもできる。

言語リソース・テーブル格納部１３２は、データの各属性値などを格納するリソース情報格納部とを含んで構成される。また、言語リソース・テーブル格納部１３２は、リソース参照情報格納部を含んで構成されており、リソース参照情報格納部は、データベース・システム１００が現時点で参照しているリソース・カラムの情報を管理し、排他制御、履歴管理などのために利用される。

情報処理装置１１０は、図１に示した実施形態では、サーバとして構成されている。情報処理装置１１０がサーバとして実装される場合、情報処理装置１１０は、ＣＯＲＢＡ(Common Object Resource Broker Architecture)などの分散コンピューティング環境を提供する専用サーバとして構成することもできるし、ＨＴＴＰプロトコルを使用してファイル転送・検索などのサービスを実行するウェブ・サーバとして実装することもできる。情報処理装置１１０は、専用サーバとして実装する場合、専用のクライアント・ソフトウェアが提供するAPIやユーザ・インタフェースを使用して情報処理装置１１０にアクセスする。また、情報処理装置１１０がウェブ・サーバとして実装される場合には、クライアントは、Internet Explorer（登録商標）、Firefox（登録商標）、Opera（登録商標）などのウェブ・ブラウザを実装し、情報処理装置１１０へのアクセスを可能とする。

また、情報処理装置１１０のデータベース処理モジュールにアクセする目的で、クライアントは、JDBC（Java（登録商標）Database
Connectivity)やODBC(Open Database Connectivity)などのAPIを、アプリケーション・レベルでのアクセス・プロトコルとして実装する。クライアントは、情報処理装置１１０のデータベース・アプリケーションにアクセスする場合、これらのAPIを使用して情報処理装置１１０に対するデータベース・アクセスが可能とされている。

なお、情報処理装置１１０には、ローカルのキーボード、マウス、ディスプレイ装置などが、ＵＳＢ、ＸＧＡなどのバスを介して接続されていて、情報処理装置１１０の管理者などが、情報処理装置１１０にローカルにアクセスすることができる構成とされていてもよい。

上述した情報処理装置１１０は、ＰＥＮＴＩＵＭ（登録商標）、ＸＥＯＮ（登録商標）、ＣＥＬＥＲＯＮ（登録商標）、ＡＴＨＲＯＮ（登録商標）、その他のＰＥＮＴＩＵＭ（登録商標）互換チップといったＣＩＳＣアーキテクチャのマイクロプロセッサ、または、ＰＯＷＥＲ ＰＣ（登録商標）などのＲＩＳＣアーキテクチャのプロセッサを、シングルコアまたはマルチコアの形式で実装することができる。

また、情報処理装置１１０は、ＷＩＮＤＯＷＳ（登録商標）２００Ｘ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などのオペレーティング・システムにより制御され、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、ＪＡＶＡ（登録商標）ＢＥＡＮＳ、ＰＥＲＬ、ＲＵＢＹなどのプログラミング言語を実装し、各種プログラムをＲＡＭなどの実行空間に読み込んでプロセッサがプログラムを実行させることによって、より詳細には後述する各機能部を、情報処理装置１１０上に実現する。なお、クライアントは、パーソナルコンピュータ、ワークステーション、ＰＤＡ、携帯電話などから構成され、適切なＯＳの下で、情報処理装置１１０にアクセスし、検索や新規テーブルの作成などを行う。

以下、情報処理装置１１０の各機能部について説明する。情報処理装置１１０の各処理部は、情報処理装置１１０が、本実施形態のプログラムおよび従来のデータベース・アプリケーションを、ＲＡＭなどの実行空間内に読み込んで展開し、プロセッサがプログラムを実行することにより、情報処理装置１１０を、各処理部として機能する機能手段として実現させている。

情報処理装置１１０は、ネットワーク・アダプタ１１４と、クライアント接続処理部１１６と、コマンド処理部１１８とを含んで実装される。ネットワーク・アダプタ１１４は、ネットワーク１１２を介して送付されるRDBへのアクセス要求を受領し、より上位プロトコルを使用する各機能部へとアクセス要求の内容を渡している。なお、本実施形態において、アクセス要求には、RDBに対するテーブル作成、編集の要求の他、RDBを検索する要求を含む。クライアント接続処理部１１６は、本実施形態において、クライアントが使用する言語環境を判断し、アクセス要求に対応した処理を実行させる。クライアント接続処理部１１６は、この目的で言語設定部１２０を実装する。言語設定部１２０は、より詳細には、レジスタ処理部１２０ａと、言語識別レジスタ１２０ｂとを管理する。レジスタ処理部１２０ａは、言語設定部１２０が管理するメモリ領域を編集する機能を有しており、クライアントに対応して、言語識別レジスタ１２０ｂに対し現在の言語設定を設定する。

クライアント接続処理部１１６は、クライアントがデータベースに接続すると、クライアントから送信されるクライアントが使用している言語情報（以下、言語識別値として参照する。）を、レジスタ処理部１２０ａが管理している言語識別レジスタ１２０ｂのうち、言語識別レジスタのCHARSETの値に設定するようにレジスタ処理部１２０ａに依頼する。レジスタ処理部１２０ａは、クライアントが使用している言語を言語識別レジスタ１２０ｂの言語識別レジスタの値としてCHARSETに設定する。言語識別レジスタ１２０ｂには、デフォルト言語識別レジスタの値としてDEFAULT_CHARSETも登録されており、DEFAULT_CHARSETの値は、英語にするなど、予め決められた値を設定しておくことができる。DEFAULT_CHARSETのデフォルト値については、特定の用途に対応して適宜設定することができる。

クライアントがデータベースに接続すると、クライアントはコマンドを発行することができる。コマンドは、本実施形態では、SQL文として構成されている。コマンド処理部１１８は、クライアントから発行されるコマンドを受け付け、コマンドの種類に応じて、処理を担当する処理部に処理を依頼する。

コマンドには、処理してほしい言語を言語識別値として含めることができ、処理を要求する言語の言語識別値が含まれている場合、情報処理装置１１０は、指定された言語についての処理を行う。また、処理を指定する言語識別値が含まれていない場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として、その言語についての処理を行う。

言語識別レジスタ１２０ｂは、情報処理装置１１０が管理するメモリ領域に確保されており、言語環境を識別するための機能を提供する。言語識別レジスタ１２０ｂは、種々の実装形式で情報処理装置１１０に構成することができるが、例えば、リレーショナル・レータベースとしてＤＢ２（ＤＢ２は、インターナショナル・ビジネスマシーンズ・コーポレーションの登録商標である。）の場合には、特殊レジスタと呼ばれる変数群にこの値を表す変数を割り当てて実装することができる。

言語識別レジスタ１２０ｂは、本実施形態の言語設定部として機能し、例えばクライアントまたはシステム管理者からの要求に対応して、「SET DEFAULT_CHARSET ‘fr’」などのコマンドにより適宜設定を変更することができる。

なお、データベースに接続するクライアントは、データベースに接続時、クライアントが使用する言語識別値を送付するが、これはクライアントが使用するオペレーティング・システムなどから言語情報を取得し、その言語情報と下記表１の言語識別値との対応関係を適切な不揮発性メモリに保存しておき、該当する言語識別値をデータベースに送付する。あるいは、クライアントが言語情報をサーバに送付し、サーバ側でその言語情報と下記表１の言語識別値との対応関係を適切な不揮発性メモリに保存しておき、該当する言語識別値を取得してもよい。

コマンド処理部１１８は、受信したコマンドを解析し、コマンドの種類に応じて、テーブル処理部１２４または言語リソース処理部１２６に処理を依頼する。例えば、本実施形態で、受領したSQLコマンドが言語を指定するコマンドであるSET CHARSET文を含んでいれば、言語設定部１２０に、SET文の引数とされた言語識別値を、CHARSETに登録するように依頼する。一方、コマンドがテーブルに対する操作を指令する場合、テーブル処理部１２４に処理を依頼する。さらに、コマンドがリソース・テーブルに対する操作であれば、言語リソース処理部１２６に処理を依頼する。

レジスタ処理部１２０ａは、接続クライアントごとに保持される各種変数を管理し、クライアントから「SET レジスタ名 値」文を受信すると、言語識別レジスタ１２０ｂの指定されたレジスタ名の値を指定された値に変更する。

テーブル処理部１２４は、クライアントからテーブルの作成・変更・除去コマンドやテーブルに対するデータの挿入・更新・削除・照会コマンドなどを受け付ける。テーブル処理部１２４は、本実施形態で実装された機能が使用できるようにする拡張コマンドを実装する。より詳細には、テーブル処理部１２４は、テーブル作成・更新・除去部１２４ａと、データ挿入部１２４ｃと、データ更新部１２４ｂと、データ削除部１２４ｄとを含んで構成することができる。また、テーブル処理部１２４は、データ照会部１２４ｅを含んで実装されており、テーブル格納部１３０に格納された本実施形態のリソース・カラムを含むテーブルの検索を可能とする。照会についても、本実施形態では、SQL文のSELECTコマンドを適用することによって行なうことができる。

テーブル処理部１２４は、各処理部を呼び出して、本実施形態で実装されるリソース・カラムやリソース・テーブルのデータを修正し、テーブル処理部１２４が実行するデータ編集処理およびデータ照会処理は、リソース・カラムやリソース・テーブルを対象とする編集、照会処理を可能とすることを除き、従来の機能を使用して実装することができる。

当該拡張コマンドでは、例えば、テーブルの作成コマンドに、そのカラムとして、本実施形態で実装されたリソース・カラムを指定するコードを含ませて実装することができ、それぞれの処理は、リソース・カラムに記述された多言語データについてテーブル作成・更新・除去およびデータ照会を実行する。リソース・カラムとは、本実施形態で実装される、多言語表記されたデータを含むカラムを意味する。リソース・カラムにより、複数言語の値が管理される。本実施形態では、XMLを使用して複数言語の値を管理しており、DOMまたはSAXなどを含んで実装されるXMLパーザなどを含むことができる。構造化言語としてのXMLの使用は、特定の実施形態であり、構造化文書は、どのような形態で管理されてもよい。

言語リソース処理部１２６は、クライアントから本特許で実装されたリソース・テーブルの作成・除去コマンドや、リソース・テーブルに対するデータの挿入・更新・削除コマンドなどを受け付ける。言語リソース処理部１２６は、この目的のため、より詳細には、リソース・テーブル作成・除去部１２６ａと、リソース・データ挿入部１２６ｃと、リソース・データ更新部１２６ｂと、リソース・データ削除部１２６ｄとを含んで構成することができる。

テーブル作成・変更・除去部１２６ａは、リソース・カラムを保持するテーブルの作成や、リソース・カラムをテーブルに追加する処理を実行する。データ挿入部１２６ｃ、データ更新部１２６ｂ、データ削除部１２６ｄは、それぞれ、リソース・カラムに複数言語へのデータの挿入、データの更新、データの削除を実行する。

より詳細に各処理部の機能を説明すると、リソース・テーブル作成・除去部１２６ａは、リソース・カラムとは独立して、複数言語の値を保持するためのリソース・テーブルを作成したり、除去することができる。このリソース・テーブルは、リソース・カラムから参照することができる。リソース・テーブルは、それぞれカテゴリ名で識別することができ、リソース・カラムの定義ではカテゴリ名を指定することができ、それによりリソース・カラムとリソース・テーブルを関連付けされている。

データ挿入部１２６ｃは、より具体的には、リソース・カラムにある言語の値を挿入する処理を実行する。この時に追加されたデータの言語識別値が言語識別レジスタDEFAULT_CHARSETと同じ場合、デフォルトの値としてもそのデータが格納される。また、データ更新部１２６ｂは、リソース・カラムにある言語の値を挿入・変更・削除する処理などを行う。この時追加したデータの言語識別値が言語識別レジスタDEFAULT_CHARSETと同じ場合、デフォルトの値も同様に処理される。

データ削除部１２６ｄは、リソース・カラムのデータを含めたレコードを削除する処理を行う。リソース・データ挿入部は、挿入するべきデータを、リソース・テーブルの適切な領域に追加する処理を実行させる。この時追加したデータの言語識別値が言語識別レジスタDEFAULT_CHARSETと同じ場合、デフォルトの値としてもそのデータが格納される。

また、図１には、レジスタ処理部１２０ａが設定する言語識別レジスタ１２０ｂのデータ構造１４０を示す。言語識別レジスタ１２０ｂには、クライアントが要求する言語の値がない場合に使用するデフォルトの言語を指定する言語識別値を設定する、デフォルト言語識別レジスタのためのアドレス領域１４２と、クライアントが要求するデフォルトの言語識別値を登録する言語識別レジスタのためのアドレス領域１４４とを含んで構成される。

特定の実施形態では、アドレス領域１４２は、デフォルト言語識別レジスタとして、値DEFAULT_CHARSETを登録するものとして参照され、情報処理装置１１０がデフォルト設定で使用する言語が、情報処理装置１１０の起動時の初期設定などで設定される。なお、本実施形態では、例えば管理者からの指令に基づいて、デフォルト設定の言語も変更することができる。また、アドレス領域１４４は、言語識別レジスタとして、値CHARSETを登録するものとして参照され、接続クライアントのオペレーティング・システムの言語が初期設定さる。これらの言語識別レジスタは、接続クライアント毎に保持され、接続クライアントからSET文を指令することで変更することができ、切断すると解放される。

各コマンドには言語識別値を含めることができ、コマンドに言語識別値が指定されていた場合、そのコマンドの処理は、指定された言語識別値の言語環境で処理される。指定さなかった場合、CHARSETの言語環境で処理される。CHARSETの値は、クライアントからの明示的な言語設定のコマンド“SET CHARSET‘CHARSET名’”で変更することができる。

リソース・データ更新部１２６ｂは、リソース・テーブルに、すでに登録されたデータを更新する処理を実行させ、リソース・データ削除部１２６ｄは、リソース・テーブルに登録されたデータを削除する処理を実行させる。リソース・テーブルとは、本実施形態の多言語リソース・データを格納するテーブル構造を意味し、複数のリソース・カラムから参照することができる。リソース・カラムは、特定のテーブルのカラムとして他の属性を有するカラムとともにテーブルとして構成することができ、リソース・テーブルを参照することもできるし、他の実施形態では、リソース・カラムに本実施形態の多言語リソース・データを格納することもできる。

テーブル処理部１２４で処理されたリソース・カラムの定義（カテゴリ名などの定義情報）や、そのデータは、テーブル格納部１３０に格納され、テーブル処理部１２４からアクセスされる。

言語リソース処理部１２６で処理されたリソース・テーブルの定義（カテゴリ名などの定義情報）や、そのデータは、リソース情報格納部１３２で格納され、言語リソース処理部１２６からアクセスされる。テーブル処理部１２４でカテゴリ名付きのリソース・カラムを処理する場合、各言語の値は、リソース情報格納部の、そのカテゴリのリソース・テーブルに格納されるので、テーブル処理部１２４からもアクセス可能とされている。

言語リソース・テーブル格納部１３２のリソース参照情報格納部は、どのテーブルのどのカラムがどのカテゴリのリソース・テーブルを使用しているかが格納されており、テーブル処理部で、テーブルの作成・変更・除去を行った際、カテゴリ名付きのリソース・カラムが定義されていたら、その情報に基づき、リソース参照情報格納部の情報が更新される。その他、図に示す情報処理装置１００には、その他のSQLコマンドに関連する既存のRDB処理を実行するための他処理部１２８が設けられている。

図２は、クライアントが本実施形態の情報処理装置１１０に接続してから接続を切断するまでのシーケンスの実施形態を示す。情報処理装置１１０は、その起動と同時にコマンド「db_start」２１０などを発行してRDBを起動し、RDBの終了コマンド２２０を受領して情報処理装置１１０のRDB処理が終了するまでクライアントからのアクセス要求を処理する。例えば、クライアント１が情報処理装置１１０が管理するデータベースに接続すると、クライアント１から接続時に送信される言語識別値を言語識別レジスタの値CHARSETに設定する。デフォルト言語識別レジスタの値DEFAULT_CHARSETは、予め設定された値、例えば英語などが設定されている。これらのレジスタは、接続クライアントごとに保持されて、クライアントごとの言語環境を提供する。

情報処理装置１１０は、クライアント１からのアクセス要求を処理しながら、さらにクライアント２からの接続要求およびコマンド（SQL文）２４０を受け付ける。コマンドがSET文を含む場合、レジスタ処理部１２０ａに処理を依頼し、処理終了後、処理結果をクライアント２４０に返し、次のコマンドを受け付ける。同様の接続処理およびコマンド要求が、クライアント３およびクライアント４から行われ、情報処理装置１１０は、各クライアントごとにその処理に対応するサービスを実行させている。

コマンド２３０〜２６０がテーブルに対する操作であれば、テーブル処理部１２４に処理を依頼し、処理終了後、処理結果をクライアントに返し、次のコマンドを受け付ける。さらに、コマンドがリソース・テーブルに対する操作であれば、言語リソース処理部に処理を依頼し、処理終了後、処理結果をクライアントに返し、次のコマンドを受け付ける。クライアントから受領するコマンドが切断であれば、クライアントとの接続情報を破棄し、クライアントに処理を返した後、当該クライアントとの間のセッションを終了させる。また、本実施形態で採用するコマンド以外の既存のコマンドを受領した場合、従来どおりの処理を行い、処理終了後、処理結果をクライアントに返し、次のコマンドを受け付ける。

図３は、情報処理装置１１０下とクライアントがセッションを開始し、終了するまでの処理の概略的なフローチャートである。図３の処理はステップＳ３００から開始し、ステップＳ３０１で、接続要求時に送付されるクライアントの言語を、CHARSETの値にセットし、DEFAULT_CHARSETには、説明する実施形態では、情報処理装置１１０に設定されたデフォルト言語環境である、英語を指定する言語識別値「en」の値を設定する。

ステップＳ３０２では、クライアントからのコマンドを受領し、ステップＳ３０３では、コマンドにSETコマンドとその引数を受領したか否かを判断し、SETコマンドを受領したと判断した場合（ｙｅｓ）、処理をステップＳ３０７に進め、言語設定部１２０に処理を依頼し、レジスタ処理部１２０ａおよび言語識別レジスタ１２０ｂを呼び出して、SETコマンドの引数として設定されたCHARSETの値を言語識別レジスタ１２０ｂに設定する。また、ステップＳ３０３で、SETコマンドを受領しないと判断した場合（ｎｏ）、ステップＳ３０４で、テーブルに対する操作を指令するコマンドであるか否かを判断し、テーブルに対する操作を指令するコマンドと判断した場合（ｙｅｓ）、ステップＳ３０８でテーブル処理部１２４を起動して、処理を実行させる。

また、ステップＳ３０４でテーブルに対する操作を指令しないと判断した場合（ｎｏ）、ステップＳ３０５で、リソース・テーブルに対する操作であるか否かを判断する。ステップＳ３０５でリソース・テーブルに対する操作が要求されていると判断した場合（ｙｅｓ）、ステップＳ３０９で言語リソース処理部を起動して処理を実行させる。一方、ステップＳ３０５で、リソース・テーブルに対する操作も指令されていないと判断した場合（ｎｏ）、ステップＳ３０６で、切断要求のコマンドであるか否かを判断し、切断要求ではないと判断した場合（ｎｏ）、ステップＳ３１０で従来のRDB処理を実行させる。

また、ステップＳ３０６で切断要求と判断された場合（ｙｅｓ）ステップＳ３１１で当該クライアントの間のセッションを切断し、処理を終了させる。また、ステップＳ３０７、Ｓ３０８、Ｓ３０９、およびステップＳ３１０の処理が終了した後、情報処理装置１１０は、処理をステップＳ３０２に戻し、クライアントからの新たなコマンドの要求を受領する。

図４は、本実施形態で、実装される、リソース・テーブルに対する処理を指令するコマンドと判断した場合に、図３のステップＳ３０５で呼び出されるリソース作成処理の詳細なフローチャートを示す。図４の処理は、ステップＳ４００から開始し、ステップＳ４０１で、受領したコマンドがリソース・テーブル作成を指令しているか否かを判断し、リソース・テーブルの作成を指令するコマンドであると判断した場合（ｙｅｓ）、ステップＳ４０６で図６の処理を呼び出して処理を実行させ、処理後、ステップＳ４１１で当該コマンドに対応する処理を終了させる

ステップＳ４０１で、リソース・テーブル作成を指令していないと判断された場合（ｎｏ）、ステップＳ４０２で、リソース・テーブル削除を指令するか否かを判断し、リソース・テーブル削除と判断した場合（ｙｅｓ）、ステップＳ４０７で、指定したリソース・テーブルを参照しているカラムがあれば、エラーを返す。なければ、そのリソース・テーブルを除去し、ステップＳ４１１で処理を終了させる。リソース・テーブルの削除は、例えば下記式（１）で指令することができる。

また、ステップＳ４０２で、リソース・テーブル削除を指令するコマンドではないと判断した場合（ｎｏ）、ステップＳ４０３で、リソース挿入を指令するコマンドであるか否かを判断し、リソース挿入と判断した場合（ｙｅｓ）、ステップＳ４０８で図８の処理を起動して、リソースの挿入を実行させ、ステップＳ４１１で処理を終了させる。

ステップＳ４０３で、リソース挿入ではないと判断した場合（ｎｏ）、ステップＳ４０４でリソース更新を指令するコマンドであるか否かを判断し、リソース更新を指令するコマンドであると判断した場合（ｙｅｓ）、ステップＳ４０９で、図１１の処理を起動し、処理後、ステップＳ４１１で処理を終了する。さらにステップＳ４０５でリソース削除が要求されていると判断した場合（ｙｅｓ）、ステップＳ４１０で図１２の処理を起動し、リソース・データの削除を実行し、ステップＳ４０５でリソース・データの削除処理でもないと判断した場合（ｎｏ）ステップＳ４１１で、当該リソース・テーブルへの処理要求を終了させる。

図５は、本実施形態で、テーブルに対する処理を実行するテーブル処理部１２４が実行する、図３のステップＳ３０４で呼び出される処理の詳細なフローチャートである。図５の処理は、ステップＳ５００から開始し、ステップＳ５０１で、受領したコマンドがテーブル作成を指令しているか否かを判断し、テーブルの作成を指令するコマンドであると判断した場合（ｙｅｓ）、ステップＳ５０８で図７の処理を呼び出して処理を実行させ、ステップＳ５１６で当該コマンドに対応する処理を終了させる。

ステップＳ５０１で、リソース・テーブル作成を指令していないと判断された場合（ｎｏ）、ステップＳ５０２で、テーブル変更を指令するか否かを判断し、テーブル変更と判断した場合（ｙｅｓ）、ステップＳ５０９でテーブルを変更する。なお、テーブルの変更で、リソース・カラムを追加する場合、テーブルの作成と同様な処理を行う。テーブルの変更処理において、リソース・カラムを追加する処理は、他のデータ・タイプのカラムを追加するのと同様に行うことができ、本実施形態で導入するリソース処理を指定するコードを含む、下記式（２）のコマンドを使用して実行することができる。

ステップＳ５０２で、テーブル変更ではないと判断した場合（ｎｏ）、ステップＳ５０３で、テーブル除去を指令するコマンドか否かを判断し、テーブル除去を指令すると判断した場合（ｙｅｓ）ステップＳ５１０で、テーブルを除去する。カテゴリ付きリソース・カラムが定義されている場合、すべてのレコードのキーを順にチェックし、そのキーに対応するリソースの該当レコードの参照カウンタを１つ減らし、処理をステップＳ５１６に分岐させて、ステップＳ５１６で処理を終了する。

ステップＳ５０３で、テーブル除去ではないと判断した場合（ｎｏ）、ステップＳ５０４でリソースの挿入を指令するコマンドか否かを判断し、リソースの挿入を指令すると判断した場合（ｙｅｓ）、ステップＳ５１２で、図１４および図１５の処理を起動し、該当するテーブルにデータを挿入し、データ挿入処理の後、ステップＳＳ５１６で処理を終了させる。また、ステップＳ５０４で、データ挿入を指令するコマンドではないと判断した場合（ｎｏ）、ステップＳ５０５で、データ更新を指令するコマンドであるか否かを判断し、データ更新と判断した場合（ｙｅｓ）、ステップＳ５１３で図１６、図１７の処理を起動して、データの更新処理を実行し、更新処理が終了した後、ステップＳ５１６で処理を終了させる。

ステップＳ５０５で、データ更新ではないと判断した場合（ｎｏ）、ステップＳ５０６でデータ削除を指令するコマンドであるか否かを判断し、データ削除を指令するコマンドであると判断した場合（ｙｅｓ）、ステップＳ５１４で、図１８、図１９の処理を起動してデータ削除を実行させ、処理後、ステップＳ５１６で処理を終了する。さらにステップＳ５０７でコマンドが検索を指令しているか否かを判断し、データ検索が要求されていると判断した場合（ｙｅｓ）、ステップＳ５１５で、データの検索を実行させた後、ステップＳ５１６で処理を終了させる。データの検索については、より詳細に後述する。また、ステップＳ５０７で検索処理でもないと判断した場合（ｎｏ）、ステップＳ５１６で、当該リソース・テーブルへの処理要求を終了させる。

図６は、本実施形態で、リソース・テーブルを作成する場合の概略的な処理のフローチャートである。図６の処理は、ステップＳ６００から開始し、ステップＳ６０１で、リソース・データの作成を指令するコマンドを受領する。ステップＳ６０２で、リソース保存域を、多言語対応のXMLを保存するために確保し、ステップＳ６０３で、処理を終了させる。リソース保存域は、言語リソース情報を格納および検索可能とするために確保され、従来のデータベースのテーブルの機能を用いて格納してもよい。また、データベースの特定のスキーマをこの目的に利用してもよく、当該テーブル名をリソースのカテゴリ名としてもよい。以下、スキーマ名をRESOURCE、テーブル名をカテゴリ名とし、テーブルのカラムとして１つのXMLデータ・タイプを保持するカラムRESに言語リソース情報を保持した場合について説明する。リソース・テーブルの作成は、例えば下記式（３）で指令することができる。

図７は、図５のステップＳ５０８で、情報処理装置１１０が実行するテーブル作成処理の詳細なフローチャートを示す。図７の処理は、ステップＳ７００から開始し、ステップＳ７０１で、テーブル作成を指令するコマンドを受領する。ステップＳ７０２では、対象とするカラムの第１番目の定義を検査し、ステップＳ７０３で、コマンドが、当該カラムについてリソース・カラムでのテーブル作成を指令しているか否かを判断する。

本実施形態で、SQL文を使用するスクリプトを作成する場合、リソース・カラムを保持するテーブルを作成するスクリプトは、下記式（４）や（５）で記述することができる。

なお、上記式（４Ａ）は、リソースを他のテーブルと共有するために、テーブルとは別途管理する実施形態で、‘MTH’はリソースを識別するためのカテゴリ名である。リソースを別途管理する場合、下記式（５）で示されるように、リソース・テーブルのカテゴリ名を指定してリソース保管領域とそのデータを事前に確保することもできる。また、別途管理されたリソースをどのテーブルのどのカラムが参照しているかを保持し、参照情報格納部に格納される。これはデータベースのテーブルの機能を利用して保持してもよい。以下、テーブルのスキーマ名がRESREF、テーブル名がREFERENCEで、テーブルのカラムとして１つのXMLデータ・タイプを保持するカラムREFにリソース参照情報を保持した場合について説明する。以下、テーブルT1を、暦月の名称および当該暦月の日数を多言語に対応して登録するリソース・テーブルであるものとして説明する。

ステップＳ７０３の判断で作成するカラムがリソース・カラムではなく、従来のデータ・タイプのカラムの作成を指令していると判断した場合（ｎｏ）、ステップＳ７０４で、従来方法を使用してカラム情報の保存およびデータ保存域を確保し、ステップＳ７０６で、すべてのカラムの定義を検査したか否かを判断し、ステップＳ７０６で、作成するべきカラムの処理が終了したと判断した場合（ｙｅｓ）、ステップＳ７１２で、処理を終了させる。また、ステップＳ７０６で、検査するべきカラムが残されていると判断した場合（ｎｏ）、ステップＳ７０５で、次のカラムの検査を行い、再度ステップＳ７０３の判断を、対象カラムがなくなるまで継続する。

一方、ステップＳ７０３で、リソース・カラムの作成を指令するコマンドであると判断した場合（ｙｅｓ）ステップＳ７０７で、カラム定義情報として、従来のカラム定義情報に加え、カテゴリ名を保持する。カテゴリ名がない場合は、カテゴリ名にNULLをセットする。ステップＳ７０８で、カラムのデータ（XML）保存域を確保し、ステップＳ７０９で、カテゴリ名に有意な値が設定されている場合には（ｙｅｓ）、ステップＳ７１０で、当該カテゴリ名のリソースがすでに作成済みであるか否かを判断し、有意な値ではないNULLが登録されている場合（ｎｏ）には、ステップＳ７０６に処理を分岐させ、さらに処理するべきカラムが残されているか否かの判断を行う。

一方、ステップＳ７１０で、当該カテゴリ名にリソースがすでに作成済みである場合（ｙｅｓ）、ステップＳ７０９で、さらに処理するべきカラムが残されているか否かについて判断し、当該判断に結果に応じて、テーブル作成終了またはさらなる検査を継続させる。また、ステップＳ７１０で、当該カテゴリのリソースが作成済みでない場合（ｎｏ）、ステップＳ７１１で、当該カテゴリのリソース・テーブルを作成し、そのデータ（XML）保存域を確保し、ステップＳ７０６に処理を分岐させ、処理を反復させる。

図８は、図４のステップＳ４０８の処理の詳細なフローチャートを示す。挿入するデータは、リソースの値とその値を識別するためのキーを指定することができる。図８の処理は、言語リソース処理部１２６のリソース・データ挿入部が実行する処理である。図８の処理は、ステップＳ８００から開始し、リソース・テーブルに構造化文書の挿入を指令するコマンドを受領して起動され、ステップＳ８０１で、コマンドに記述された各値（リソース名、キー名、値言語識別値（指定されている場合）を取得する。指定されていないなら、言語識別レジスタに設定されたCHARSETの値を使用する。構造化文書の追加を指令するコマンドは、種々の形式を採用することができるが、本実施形態における特定の態様では、下記式（６）としてコマンドを定義することができる。

上記式（６）では、RESOURCEの後に続くMTHはリソースのカテゴリ名、１カラム目のデータ’Jan’はキー、２カラム目のデータ‘１月’は値を表す。キーは、同一カテゴリ内の値を識別するために利用する。なお、ステップＳ８０１では、CHARSET
‘言語識別値’はオプションとして省略可能で、省略した場合、言語識別レジスタ１２２のCHARSETの値を言語識別値として使用する。言語識別値は、当該アクセス要求が要求する言語環境を指定するコードである。

ステップＳ８０２では、キーがリソース・テーブルに既登録か否かを判断する。ステップＳ８０２の判断で、キーが既登録ではないと判断した場合（ｎｏ）、ステップＳ８０３で、キーと、指定された言語識別値でのデータをリソース・テーブルに挿入する。この際、言語識別値がデフォルト言語識別レジスタに設定されたDEFAULT_CHARSETと同じ場合、デフォルトの値としてもデータを登録する。

一方、ステップＳ８０２の判断で、キーが既登録であると判断された場合（ｙｅｓ）、ステップＳ８０４に処理を分岐させ、言語指定値に該当するデータが定義されているか否かを判断する。ステップＳ８０４ですでにデータが登録されていると判断された場合（ｙｅｓ）、ステップＳ８０６で対応する言語のデータが既登録であることをクライアントに通知するエラーメッセージを発行し、ステップＳ８０７で処理を終了する。また、ステップＳ８０４で、言語指定値に該当するデータが登録されていない場合（ｎｏ）、ステップＳ８０５で、該当するレコードの子要素として、指定された言語識別値でデータを登録する。さらに言語識別値がデフォルト言語識別レジスタに設定されたDEFAULT_CHARSETと同じ場合、デフォルトの値としてもデータを登録し、処理をステップＳ８０７に戻し、終了する。

図９は、本実施形態に従い、リソース・テーブルに挿入されたデータ構造の実施形態を示す。データ構造９１０に示すように、各レコードのリソース・カラムは、言語環境の相違に対応するデータごとにvalueタグで識別され、さらに１つのレコードが、1つのキーに関する情報を保持し、resourceタグのkey属性で識別されて、階層構造を与えるようにして登録されている。また、データ構造９１０に示すように、クライアントにより指定された言語識別値は、charset＝charset名（デフォルト値はdefault）で設定されている（charset名に言語識別値が設定される）。追加されるリソース・データは、＜resource＞タグで指定される構造化文書９1０のノードにおける子ノード９1２として追加される。また、値refcountは、参照カウンタで、リソース・テーブルの該当キーを参照しているテーブルのカラムのデータ数に相当する。参照カウンタの値の設定処理については、より詳細に後述する。

本実施形態では、図９に示すように、構造化文書が管理するべき値は、月などの単純な値ではなく、例えは、テーブルT2のカラムとして、NAME VARCHAR (10)， DESCRIPTION RESOURCE (‘DESC’)を定義する場合、NAMEカラムに、“IBM”を登録しておき、DESCRIPTIONリソース・カラムには、英語とデフォルト用に “IBM stands for International Business Machines”などを登録することができる。

そして、DESCRIPTIONの対応する日本語データは、“ＩＢＭは、インターナショナル・ビジネス・マシーンズの略です”などの値をテーブルの更新処理や該当カテゴリのリソースに対する挿入処理により、子要素として登録することができる。さらに他の実施形態では、DESCRIPTIONの他、例えばブログのコンテンツ、またはその他ウェブのコンテンツとして提供するべきデータについても、それぞれ同一の翻訳値または翻訳文を同一のレコード内に登録しておくことで、多言語対応が可能となる。

図１０は、本実施形態のリソース・テーブルに登録されたデータの更新処理のフローチャートを示す。リソース・テーブルに登録されたデータの更新処理は、「UPDATE RESOURCE]スクリプトを使用して行われる処理である。図１０の処理は、クライアントからリソース・テーブルの構造化文書の更新を指令するUPDATE
RESOURCE文を受信することによって、ステップＳ１０００で、リソース・データ更新部１２６ｂが呼び出されて開始する。説明する実施形態では、更新を指令するコマンドは、値の書換えを指令するものであり、下記式（７）で与えることができる。

ステップＳ１００１では、スクリプトに記述された各値（リソース名、キー名、値、言語識別値（指定されている場合）を取得する。CHARSET ‘言語識別値’は省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。ステップＳ１００２で、キー値および言語識別値に一致するデータを検索する。ステップＳ１００３では、該当するデータが存在するか否かを判断し、該当するデータが存在しない場合（ｎｏ）、ステップＳ１００５で、クライアント２３０にエラーを返し、ステップＳ１００６で処理を終了させる。

一方、ステップＳ１００３で、該当するデータが存在すると判断した場合（ｙｅｓ）、ステップＳ１００４で該当するデータの値をコマンドで指定されたデータで書換える。書換え後の値がNULLである場合、対応するデータを削除する。言語識別値とデフォルト言語識別レジスタのDEFAULT_CHARSETの値とが一致する場合、デフォルトの値も更新し、ステップＳ１００６で処理を終了する。図１０の処理によって、一旦作成したデータを、クライアントからの指令に対応して書換えが可能となり、不要なデータの削除や値の更新などを行うことができる。

図１１は、本実施形態に書換え処理の実施形態１１１０を、スクリプトおよび構造化文書で記述されたデータを使用して説明する図である。クライアント２３０から送付される書換えを指令するスクリプト１１１１は、「UPDATE RESOURCE カテゴリ名 SET VALUE=‘value’ WHERE KEY=‘key’CHARSET‘言語識別値’」である。クライアントから送信されるコマンドが「UPDATE RESOURCE」で始まる場合、リソース・カラムの値を書換えが指令されたと判断し、書換え処理を開始する。

より具体的には、既存のデータ１１３０の書換えのため、書換えを指令するスクリプト１１２０が、「UPDATE
RESOURCE MTH SET VALUE=‘睦月’ WHERE KEY=‘Jan’CHARSET‘ja’」を受領したものとして説明する。情報処理装置１１１は、まず、カテゴリ名MTH、キー値、言語識別値を照合し、対応するデータ１１３０を取得し、スクリプト１１２０で指定されたvalue＝睦月で、データ１１３０の該当する値を、「睦月」に書換えたデータ１１４０として登録する。

図１２は、本実施形態のリソース・テーブルに登録されたデータの削除処理のフローチャートを示す。リソース・テーブルに登録されたデータの削除処理は、本実施形態では「DELETE FROM RESOURCE」で始まるコマンドを受信した場合に行われる処理である。図１２の処理は、クライアントからDELETE FROM RESOURCE文を受信することによって、ステップＳ１２００で、リソース・データ削除部１２６呼ばれ、処理を開始する。本実施形態では、リソース・テーブルの構造化文書の削除を指令するコマンドおよびその引数は、下記式（８）のコマンドで与えることができる。

ステップＳ１２０１では、スクリプトに記述された各値（リソース名、キー名、値、言語識別値（指定されている場合）を取得する。CHARSET ‘言語識別値’は省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。ステップＳ１２０２では、該当するデータを取得し、ステップＳ１２０３で該当するデータが存在しないと判断された場合（ｎｏ）、ステップＳ１２０４で、クライアントにエラーを返し、ステップＳ１２０８で処理を終了させる。

一方、ステップＳ１２０３で、該当するデータが存在すると判断した場合（ｙｅｓ）、ステップＳ１２０５で参照カウンタの値が０か否かを検査し、その参照カウンタが０であれば、ステップＳ１２０６で該当するデータの値をキー単位ですべて削除する。削除後、その結果をクライアントに返し、ステップＳ１２０８で処理を終了する。参照カウンタが０でない場合（ｎｏ）、ステップＳ１２０７でクライアントにエラーを返し、ステップＳ１２０８で処理を終了させる。図１２の処理によって、一旦作成したデータを、クライアントからの指令に対応して削除することが可能となる。

次に、リソース・テーブルを除去するコマンドは、下記式（９）として実装することができる。

リソース・テーブルの削除は、リソース参照情報を参照し、指定したリソース・テーブルを参照しているカラムがあれば、エラーを返す。一方、指定したリソース・テーブルを参照しているカラムがなければ、そのリソース・テーブルを除去することにより実行することができる。

以上、リソース・カラムを保持するテーブルの作成、リソース・テーブルの作成、挿入、更新、削除処理について説明した。以下、さらに、リソース・カラムを保持するテーブルに対して、データを挿入、更新、削除する処理、および、各種データを参照する処理について説明する。

図１３は、本実施形態の情報処理装置１１０において、リソース・カラムを保持するテーブルにデータを挿入するデータ挿入部１２４ｃが実行する処理のフローチャートを示す。当該コマンドは、種々の形式を採用することができるが、本実施形態における特定の形態では、下記式（１０）としてコマンドを定義することができる。

上記式（１０）は、Syntaxの変更例を示したものであり、CHARSET ‘言語識別値’は省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。式(１０)で示すように、リソース・カラムのデータの挿入方法として、値そのものを指定する以外にRESOURCE_SET()やRESOURCE_REF()といった関数を利用することができる。コマンド“RESOURCE_SET()”は、第１引数にキー名を、第２引数に値を設定することができ、各引数に基づいてデータが保存される。コマンド“RESOURCE_REF()”は、第１引数にキー名を設定することができ、そのキーの値を参照することを意味する。キーの値は、別途、上述したINSERT
INTO RESOURCE文で予め挿入しておくことができ、その値を参照する際にRESOURCE_REF()を利用することができる。

リソース・データの挿入処理は、ステップＳ１３００で、挿入を指令するコマンドを受領してリソース・データ挿入部１２６ｃが呼び出されることにより開始する。ステップＳ１３０１でコマンド中に設定されている、テーブル名、各カラムのデータ、言語識別値（設定されている場合）を取得する。そして、ステップＳ１３０２で、１番目のカラムの定義と値を取り出す。

上述したように、オプション的にCHARSET ‘言語識別値’は省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。各カラムのデータを１カラム目から処理する。ステップＳ１３０３で処理対象のカラムが、リソース・カラムか否かを判断し、処理対象のカラムがリソース・カラムでない場合（ｎｏ）、ステップＳ１３０４で、従来通りの処理を実行するテーブル処理部を呼び出して既存の処理を使用してテーブルに対する処理を実行させ、ステップＳ１３０７でさらに処理するカラムが存在するか否かを判断する。ステップＳ１３０７の判断でさらに処理を行うべきカラムが存在する場合（ｙｅｓ）、処理をステップＳ１３０３に戻し、再度判断を繰り返す。また、ステップＳ１３０７で処理を行うべきカラムが残っていない場合（ｎｏ）、ステップＳ１３０７で処理を終了する。

ステップＳ１３０３で処理対象のカラムが、リソース・カラムであると判断された場合（ｙｅｓ）、ステップＳ１３０５で、カテゴリ指定値は、NULLであるか否かを判断する。ステップＳ１３０５で、カテゴリ指定値がNULLであれば（ｙｅｓ）、ステップＳ１３０６で該当するカラムに言語リソースを与える構造化文書を記述する。言語識別値とデフォルト言語識別レジスタの値が一致する場合、デフォルト設定の言語の値も挿入する。一方、カテゴリ名がNULLでない場合（ｎｏ）、ポイントＡから図１４の処理に分岐する。

図１４の処理は、ポイントＡで図１３の処理から制御を渡されて開始し、ステップＳ１４０１で、カテゴリ名を取得し、ステップＳ１４０２で値のみが指定されているか否かを判断し、値のみが指定されている場合（ｙｅｓ）、ステップＳ１４０３でキーを自動生成し、登録されていないキーを得る。そして、ステップＳ１４０４で、上記式（８）で説明したと同様の処理を行う。この際、該当するリソースのキーの参照カウンタを１に設定する。一方、ステップＳ１４０２で、コマンド内で、RESOURCE_SET()が使用されており、ステップＳ１４０６でキー以外の値も含まれると判断した場合（ｎｏ）、キー名と値とを取得し、ステップＳ１４０７で該当するカテゴリのリソースに該当するキーがすでに登録されているか否かの判断を行う。キーがすでに登録されている場合（ｙｅｓ）、ステップＳ１４１０でエラーを返し処理を終了させる。

一方、ステップＳ１４０７でキーが登録されていない場合（ｎｏ）、処理をステップＳ１４０４に戻し、処理を反復させる。

また、ステップＳ１４０６の判断で、RESOURCE_SET()が含まれていない場合（ｎｏ）、ステップＳ１４０８で、コマンドに、参照カウンタの変更を指令するコマンド、例えばRESOURCE_REF()が含まれているか否かを判断する。ステップＳ１４０８で参照カウンタ（refcount）を修正するコマンドが存在すると判断する場合（ｙｅｓ）、ステップＳ１４０９でリソース・テーブルにすでにキーが登録されているか否かを判断し、登録されていない場合（ｎｏ）、ステップＳ１４１０で該当するキーが存在しないとしてエラーを返す。一方、キーが存在する場合（ｙｅｓ）、ステップＳ１４１１で、該当するキーの参照カウンタを１増分し、処理をステップＳ１４１２に戻す。

図１５は、本実施形態の情報処理装置１１０において、リソース・カラムを保持するテーブルに登録されたデータの更新を行う、リソース・データ更新部１２６ｂの処理のフローチャートを示す。図１５の処理は、ステップＳ１５００で、更新を指令するコマンドを受領して呼び出されることにより起動され、ステップＳ１５０１で、コマンドに指定された言語識別値を取得する。言語識別値は省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。ステップＳ１５０２では、WHERE節に記述されている１番目の条件のカラム名とその値を取得し、ステップＳ１５０３で、リソース・カラムを指定しているか否かを検査する。ステップＳ１５０３の判断で、リソース・カラム名が指定されていないと判断された場合（ｎｏ）、ステップＳ１５０４で、従来の処理を使用して更新対象のレコードを取得する。

一方、ステップＳ１５０３でリソース・カラムが指定されていると判断した場合（ｙｅｓ）、ステップＳ１５０７で、当該リソース・データのカテゴリ名は、NULLか否かを検査し、NULLの場合（ｙｅｓ）、ステップＳ１５０８で、該当レコードの該当カラムのレコードを順に得る。その後、ステップＳ１５０９で、CHARSET名に該当する言語識別値を取得する。該当する値がなければデフォルトの値を取得する。また、ステップＳ１５１０では、取得した値を用いて条件を判断し、取得した値が、条件に指定されている値と一致する場合、更新または挿入の対象と設定して処理をステップＳ１５０５に分岐させる。

また、ステップＳ１５０７の判断でNULLではないと判断された場合（ｎｏ）、ステップＳ１５１１で該当カラムに保存されているキー名から、該当するリソース・テーブルの該当データを得、ステップＳ１５１２で、該当するカテゴリのリソース情報を参照し、キーとCHARSET名に該当する値とを取得する。ない場合には、デフォルトの値を取得する。ステップＳ１５１３では、取得した値を用いて条件を判断し、取得した値が、条件に指定されている値と一致する場合、更新または挿入の対象と設定して処理をステップＳ１５０５に分岐させる。

ステップＳ１５０５では、WHERE節に続く条件があるか否かを判断し、条件がある場合（ｙｅｓ）、ステップＳ１５０６で、WHERE節に記述されている次の条件を取得し、処理をステップＳ１５０３に分岐させて処理を反復させる。一方、ステップＳ１５０５で、WHERE節に続く条件があるか否かを判断し、条件がないと判断した場合（ｎｏ）、ポイントＢから図１６の処理を呼び出して、更新処理を実行させる。

図１６は、図１５の挿入処理に後続する処理のフローチャートを示す。図１６の処理は、図ポイントＣで、図１５の処理から制御を渡されて開始する。ステップＳ１６００では、更新対象レコードを処理対象としてセットし、ステップＳ１６０１では、更新を指令するコマンドで指定されている第１番目のカラム名と値とを取得する。ステップＳ１６０２では、現在判断対象としている当該カラムがリソース・カラムか否かを、リソース情報を参照して判断し、リソース・カラムでない場合（ｎｏ）、ステップＳ１６０３で、従来の処理を適用してカラムへの更新を実行する。

一方、ステップＳ１６０２の判断でリソース・カラムであると判断された場合（ｙｅｓ）、ステップＳ１６０４で、当該リソースのカテゴリは、NULLか否かを判断し、NULLの場合（ｙｅｓ）、ステップＳ１６０５で、該当カラムの言語識別値の値が存在すれば、その値を置換する。ない場合は、挿入する。置換後の値がNULLであれば、言語識別値の値を削除する。言語識別値がデフォルト言語識別レジスタのDEFAULT_CHARSETの値と同じ場合、デフォルトの値についても置換する。

また、ステップＳ１６０４の判断でNULLでない場合（ｎｏ）、ステップＳ１６０６で、該当テーブルの該当カラムに保存されているキーから、該当するリソース・テーブルの該当データを得、ステップＳ１６０７で、言語識別値の値が存在すれば、その値を置換する。ない場合は、挿入する。置換後の値がNULLであれば、言語識別値の値を削除する。言語識別値がデフォルト言語識別レジスタのDEFAULT_CHARSETの値と同じ場合、デフォルトの値についても置換し、処理をステップＳ１６０８に分岐させる。

ステップＳ１６０８では、次の更新するべきカラムが残っているかを判断し、残っていない場合（ｎｏ）、ステップＳ１６１０で処理を終了させる。一方、残っている場合、ステップＳ１６０９で、次の更新するべきカラム名と値を取得し、処理をステップＳ１６０２に分岐させて処理を反復させる。

図１７は、本実施形態でリソース・カラムを保持するテーブルに登録されたデータの削除を行う処理のフローチャートである。図１７の処理は、図１５の処理に比較し、更新を削除に置き換えた以外、カラムの検査を実行する点では共通するため詳細な説明は行わない。図１７の処理は、ポイントＣに達した時点で、制御を図１８の処理に制御を渡し、削除の実体的処理を開始する。

図１８は、図１７に後続する削除処理のフローチャートである。図１８の処理は、ポイントＣで、図１７の処理から制御を渡されて開始し、ステップＳ１８００で、削除対象レコードを削除対象としてセットし、ステップＳ１８０１で、１番目のカラムをチェックする。ステップＳ１８０２では、当該カラムは、リソース・カラムか否かを判断し、リソース・カラムでない場合（ｎｏ）、ステップＳ１８０６で、さらに処理するべきカラムが残っているか否かを判断し、残っている場合（ｙｅｓ）、ステップＳ１８０９で、次のカラムをチェックし、処理を反復させる。一方、ステップＳ１８０６で、次のカラムが残っていないと判断された場合（ｎｏ）、ステップＳ１８０８で、従来のデータ削除部１２４ｄを呼び出して従来の処理を適用してカラムを削除し、ステップＳ１８１０で処理を終了する。

また、ステップＳ１８０２で、リソース・カラムであると判断した場合（ｙｅｓ）、ステップＳ１８０３で、当該リソースのカテゴリは、NULLか否かを判断し、NULLの場合（ｙｅｓ）、処理をステップＳ１８０６に分岐させ、さらに処理するべきカラムが存在しているか否かを判断し、処理を反復させる。一方、ステップＳ１８０３の判断で、当該リソースのカテゴリがNULLではないと判断された場合（ｎｏ）、ステップＳ１８０４で、該当テーブルの該当カラムに保存されているキーを得、ステップＳ１８０５で、該当するカテゴリのリソース情報を参照し、キーの参照カウンタの値を１デクリメントさせ、ステップＳ１８０６に処理を分岐させ、処理を反復させ、対象とするカラムの処理を終了した後、ステップＳ１８１０で処理を終了する。

図１９は、本実施形態にしたがって生成されるリソース・カラムを有するテーブルの実施形態を示す。図１９に示したデータ構造は、RESOURCEデータ・タイプのカラムMONTHとINTEGERデータ・タイプのカラムNUM_OF_DAYSを保持するT1テーブル１９００と、そのテーブル１９００のカラムMONTH属性を定義するリソース情報テーブル１９３０とを示している。リソース・カラム１９１０には、説明する実施形態では、カラム名=MONTHがカテゴリ名なしのRESOURCEデータ・タイプのデータを記述する構造化文書を格納するリソース・カラムである。

また、説明する実施形態では、カラム名=NUM_OF_DAYSのカラム１９２０は、データ・タイプがINTEGERの値を登録する従来カラムであり、暦月の末日の数字を登録するカラムである。リソース・カラムのデータは、タグ＜resource＞で識別された範囲にタグ＜value＞で開始するXMLで記述されている。

クライアントからSELECT文などによりリソース・テーブル１９００で表されるテーブルの”MONTH”のデータ取得要求を受領すると、SELECT文中に言語識別値が設定されていればその値を利用し、設定されていなければ言語識別レジスタのCHARSETの値を言語識別値として利用し、その言語識別値に該当する値がリソース・カラム１９１０から取得される。その言語識別値に該当する値がなければデフォルトとして格納されている値が取得される。

また、テーブルT1のカラムMONTHの定義情報１９３０は、テーブル１９００のカラム情報としてテーブル１９００を作成すると同時に作成され、従来から保持されている情報に加えカテゴリ名が追加されている。テーブルT1のカラムNUM_OF_DAYSについても、従来どおり定義情報が作成される。テーブル１９００のカラム属性としてリソース・カラムに必要な情報を登録し、テーブル１９００のリソース・カラムのデータ管理を可能とさせている。なお、図１９に示した実施形態では、リソース・テーブル１９００には、カテゴリ名が付されておらず、このため、リソース・カラムの保存域がそのまま言語リソースを格納するために利用されている。また、図１９に示した実施形態では、キー値は登録されておらず、直接valueに設定された値の一致などを使用して適切なレコードに追加するべき構造化文書が追加されて行く。

なお、リソース・テーブル１９００に登録される構造化文書には、データ作成・編集などの履歴をトレース可能とするため、作成および編集を受けた時刻のタイムスタンプが登録されている。各タイムスタンプは、データベース・システムの管理者などが、データ変更履歴を検査し、例えば、デフォルトや英語の値が更新された後に他の言語の値も更新されているかなどを検出するために利用される。

図２０は、本実施形態で、テーブルを作成する際、RESOURCEデータ・タイプのカラム情報として、カテゴリ名＝MTHを指定したものである。図２０に示したデータ構造は、RESOURCEデータ・タイプのカラムMONTHとINTEGERデータ・タイプのカラムNUM_OF_DAYSを保持するT1のテーブル情報２０３０と、テーブル情報２０３０のカラムMONTHの属性を定義するリソース情報テーブル２０２０と、カテゴリMTHのリソース・テーブル２０００を示している。図２１の実施例の場合、リソース・カラムMONTH自体では、言語リソースを保持せず、キーを保持する。キーに対応する値は、そのカテゴリのリソース・テーブル２０００が、カラム２０１０においてキーとともに保持する。

クライアント２３０からSELECT文などのより２０３０で表されるテーブルの”MONTH”のデータ取得要求を受領すると、SELECT文中に言語識別値が設定されていればその値を利用し、設定されていなければ言語識別レジスタのCHARSETの値を言語識別値として利用し、MONTHの保存域に格納されているキーに相当するデータを該当するカテゴリのリソース・テーブルから検出し、その言語識別値に該当する値を取得する。その言語識別値に該当する値がなければデフォルトとして格納されている値を取得する。

図２１は、本実施形態で、リソース・カラムを保持するテーブルがリソース・テーブルを参照中であることを示す、リソース参照情報を格納するリソース参照テーブル２１００の実施形態を示す。リソース参照テーブル２１００は、カテゴリ名付きでリソース・カラムを定義した際、そのスキーマ名と、テーブル名と、カラム名とをカテゴリ名に関連付けた情報を保持するテーブルであり、リソース参照情報格納部に格納されるデータ構造体である。図２１に示した実施形態では、リソース参照テーブル２１００のREFカラムには、構造化文書＜reference category =”MTH”＞として、そのカテゴリを参照しているスキーマ名とテーブル名とカラム名とが登録されている。さらに、CITYカテゴリについては、２つのテーブル“CUSTINFO”および“SHOPINFO”の“CITY”カラムから参照されていることが示されている。

リソース・カラムを利用してデータを更新する処理を説明する。この場合のSQL文は、データの更新を実行するSQL文CHARSET ‘言語識別値’を付加することにより実装することができる。下記式（１１）を使用して特定の実施形態について説明する。

上記式（１１）中、CHARSET ‘言語識別値’は、オプションとして省略可能で、CHARSET節を省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。式(１１)の例では言語識別値としてイタリア語(it)を指定する実施形態である。式(１１)で示すように、リソース・カラムのデータも、他のデータ・タイプのカラムと同様のフォーマットで、構造化文書として記述することができる。

図１２〜図１８の処理で、WHERE節にリソース・カラムが指定されている場合、言語識別値のデータを取り出して処理する。言語識別値のデータがない場合、デフォルトのデータを取り出して処理する。SET節にリソース・カラムが指定されている場合、言語識別値のデータとして保存される。すでに言語識別値のデータが保存されていれば置き換え、保存されていなければ挿入する。保存や挿入の方法は、リソース・カラムを保持するテーブルにデータを挿入する処理と同様な方法で行う。

なお、式（１１）の更新処理を行う前の状態としてMONTHの値のデフォルト値として‘January’が登録されており、それに相当するイタリア語が登録されていない場合、式（１１）の更新処理により、MONTHに設定された値のデフォルト値‘January’に相当するデータにイタリア語の’Gennaio’が登録される。一方、すでにMONTHの値として、デフォルト値‘January’に相当するイタリア語がすでに登録されている場合は、式（１１）の更新処理では、MONTH=’January’に該当するレコードが見つからないため、データの更新は行われないこととなる。

また、リソース・カラムを利用してデータを削除する処理のSQL文は、更新と同様な処理で該当レコードを見つけることにより実装することができる。

式（１２）の場合も同様に、CHARSETの‘言語識別値’は、オプションで省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。式（１２）の例は、言語識別値として日本語(ja)を指定する場合を例示している。WHERE節にリソース・カラムが指定されている場合、言語識別値のデータを取り出して処理する。言語識別値のデータがない場合、デフォルトのデータを取り出して処理する。上記式（１２）では、MONTHの値の日本語データが‘1月’のレコードが削除される。削除されるレコードのカラムで、カテゴリ名付きのリソース・カラムが定義されている場合、そのカテゴリのリソースの該当キーの参照カウンタを１つ減らす。

データの照会処理は、SELECT文などを使用して実装することができ、リソース・カラムに対する処理は、挿入・更新・削除などと同様な処理で情報処理装置１１０に実装することができる。下記式（１３）に、照会処理で使用するSQL文の実施形態を説明する。

上記式（１３）中、CHARSET ‘言語識別値’は、オプションで省略可能で、省略した場合、言語識別レジスタ１２０ｂのCHARSETの値を言語識別値として使用する。式（１３ｂ）の例では言語識別値として日本語語(ja)を指定するものとして説明する。式(１３ｂ)で示したようにリソース・カラムのデータも、他のデータ・タイプのカラムと同様に記述することができる。リソース・カラムのデータを照会する処理は、言語識別値に対応するデータを抽出することにより実行することができる。式(１３ｃ)の例では、リソース・カラムの値を要求するSELECT文で、この場合も、他のデータ・タイプのカラムと同様に記述することができる。リソース・カラムの値の取得は、言語識別値の値を取得し、なければ、デフォルトの値を取得する。

以下、本実施形態のデータベース・システム１００に対する検索処理の実施形態を説明する。検索処理は、図１に示したデータ照会部１２４ｅが実行し、例えばSQLなどを使用する場合には、SELECT文をコマンド処理部１１８が受領し、データ処理部１２４に対して処理を依頼することにより実行される。検索結果は、表として生成され、クライアントに検索結果として返される。なお、検索処理は、クライアントが情報検索を行う目的で情報処理装置１１０にアクセスする他、RDBの管理者がデータベースをメンテナンスするための目的でRDBの内容を抽出する目的でのアクセスに対応する検索処理を含む。

本実施形態においても、SELECT文などでデータを照会する際には、スカラ関数や表関数として参照されるSQL関数を指定することができる。スカラ関数や表関数を実行する関数モジュールは、予め登録されており、SELECT文で登録したスカラ関数や表関数が指定されている場合、該当する関数モジュールが呼ばれる。スカラ関数用モジュールは処理結果として値を返す。表関数モジュールは処理結果として表データ（カラム名と0個以上のレコード）を返す。本実施形態で言語リソース対応処理を呼び出すためのスカラ関数と表関数を、下記表２に示すが、下記関数に限定されるものではない。

図２２は、本実施形態の検索処理で生成される、SELECT文および対応する検索結果のデータ構造の実施形態を示す。データ構造２２００は、スキーマ「xxx」のテーブルT1のカラムMONTHが使用しているリソースのカテゴリ名を抽出するスカラ関数とそのレコードが保持するキー名を抽出するスカラ関数を含むSELECT文および検索結果を、図２０のリソース・テーブル２０３０から抽出した場合の検索結果を示す。SELECT文は、カラムMONTHのカテゴリ名、カラムMONTHのキー名、カラムNUM_OF_DAYSの値（月の日数）をテーブルT1から抽出することを要求しており、検出結果には、それぞれの値がリストされているのが示されている。

図２２に示す実施形態では、表２に示した表２中、（１）の、カテゴリ名を返すスカラ関数は、該当するスキーマ名、テーブル名、カラム名に定義されているカテゴリ名を返す。カテゴリ名がない場合、NULLを返す。また、表２中、（２）のキー名を返すスカラ関数についても、リソース・カラムのデータに格納されているキーを返し、カテゴリ名を使用していない場合はキーも使用しないので、NULLを返す。また、図２２の実施形態では、表２中、（３）のリソース情報を返す表関数１は、該当するカテゴリのリソース情報を表形式で返し、図２２の２２１０の実施形態では、カラムとして、キー、参照カウンタ値、言語、値、作成日、最終更新日を返しているが、説明する実施形態に限定されるものではない。

表２中、（４）のリソース情報を返す表関数２の処理を説明すると、関数２は、該当するリソース・カラムが含むリソース情報を表形式で返し、スキーマ名と、テーブル名と、カラム名とを引数とし、表２中の表関数１の値に加え、キーの値と、カテゴリ名とを抽出する。IDは、同一リソース・カラムに保存されているデータを関連付けるために動的に生成され、使用されている。なお、リソース・テーブルにカテゴリ名がない場合、カテゴリ名、キー名、および参照カウンタの値は、NULLの値が返される。

図２３は、本実施形態のまた、表２中、（４）の関数を使用する検索結果の実施形態を示す。データ構造２３００には、スキーマxxxのリソース・テーブルT1のカラムMONTHのリソース情報を抽出する表関数を含むSELECT文および検索結果を、図１９に示すテーブルから抽出した場合の結果を示す。本実施形態で実装する、RESOURCE.RESOURCE_INFO(‘schema_name’，’table_name’，’column_name’) 表関数は、カテゴリ名、キー名、参照カウンタ値、値の言語、値、作成日時、最終更新日時を返しており、結果として、CATEGORY， KEY， REFCOUNT， CHARSET， VALUE， CREATED， LASTMODIFIEDカラムに対する値がリストされているのが示されている。図２３に示したSELECT文では、テーブルのカラム名からリソース情報を抽出することができる。

さらに、図２３には、表２中の（５）のリソース参照情報を返す関数、すなわち、どのテーブルのどのカラムが、どのカテゴリのリソースを参照しているかを返す表関数についての照会結果２３１０の実施形態を示す。検索結果２３１０の実施形態では、紹介対は、図２１のリソース参照テーブル２１００を対象としてその登録要素を抽出する実施形態である。

図２３に示した検索処理は、データベースにアクセスしたクライアントが、RDBに登録されたデータを取得する目的で行うこともできる。また、図２３に示した検索処理は、RDBの管理者が、言語間で対応付けられたデータが存在するか否かをチェックする目的で使用することができる。これにより、参照しているリソース・カラムを考慮しながら、リソース・テーブルをメンテナンスすることができる。

図２２および図２３に示されるように、本実施形態では、多言語で表現されたデータが、単一のカラムで管理されており、それぞれの言語の値を保持するため、同じ意味を持つレコードを複数作成したり、テーブルを分割して管理することなく、多言語データを効率的に管理することが可能となる。

図２４は、本実施形態のリソース・テーブルの他の実施形態を示す。図２４に示す実施形態は、リソース・テーブルとして、複数の言語表記に対応する社員情報を管理する場合の実施形態に相当する。データベース作成時には、リソース参照テーブル２４１０のみが存在し、以後の入力に対応してリソース・カラムを保持する社員情報テーブル２４２０の実体内容およびリソース・テーブルが作成される。

社員情報テーブルのカラムとして、社員の名前と勤務地を含め、社員の名前をカテゴリなしのリソース・カラム、社員の勤務地をカテゴリ名＝CITYのリソース・カラム２４３０としている。社員情報テーブルの作成時、そのカラムで使用しているカテゴリCITY用のリソース・テーブルが存在していない場合、そのリソース・テーブルも作成され、リソース参照テーブルには、社員情報テーブルの勤務地カラムがカテゴリ名CITYのリソースを参照している情報を付加する。この場合、社員情報テーブルを作成するためのSQL文は、下記式（１４）で与えられる。

さらに、図２４の実施形態では、リソース・テーブル２４３０（カテゴリ名＝CITY）を参照する顧客情報テーブル２４４０を作成する。図２４の実施形態では、顧客情報テーブル２４４０のカラムとして、その居住地RESIDENCEをカテゴリ名＝CITYのリソース・カラムとして定義する。CITY用のリソース・テーブル２４３０は、SQL文（１２）によりすでに作成されているので、当該リソース・テーブルのカラムを参照することができる。この場合、対応するリソース参照テーブルには、顧客情報テーブル２４４０の居住地カラムがカテゴリ名CITYのリソースを参照している情報を付加する。この場合の例示的なSQL文は、下記式（１５）で与えられ、顧客情報テーブル２４４０＝SCHEMA.CUSTINFOが作成される。

図２５は、社員情報テーブルにいくつかのレコードが挿入された後のリソース・カラムとして定義される名前カラムを含むリソース・テーブル２５００を示す。例えば、名前＝山田太郎について、デフォルトの値、英語の値、ドイツ語の値、日本語の値、フランス語の値、およびイタリア語の値がXMLとして記述されていることが示されている。また、次レコードには、同様に、名前＝佐藤一郎の値が登録されている。また、名前カラムに続いて、作成された他のカラムのデータが保存されている。

社員情報テーブルの名前カラムの定義は、データ構造２５１０のように他のカラムと同様な形式で管理されており、カテゴリ名としてNULLが設定されている。また、社員情報テーブルの勤務地カラムの定義は、カテゴリ名としてCITYが設定されている。勤務地カラムは、カテゴリ名付きのリソース・カラムで、その場合のデータ構造を２５２０に示す。カテゴリ名付きのリソース・カラムでは、そのデータとしてキー名が保存され、値は、そのカテゴリのリソース・テーブルにキーと関連付けて保存される。また、顧客情報テーブルの居住地カラムの定義は、データ構造２５２０のように、カテゴリ名としてCITYが設定されており、その場合の参照構造を与えるデータ構造を２５２０に示す。

図２６は、カテゴリCITYのリソース・テーブルのデータ構造を示す。カテゴリCITYが有するリソース・カラム２６００では、リソース・テーブルの最初のレコードに、キー名＝Tokyoに対する値が、デフォルト、英語、ドイツ語、日本語、フランス語で定義されていることが示されている。また、顧客情報テーブル２６１０の居住地カラムには、キー名Osaka、Tokyo、New Yorkが登録されている。

説明する実施形態では、リソース・テーブル２６００のカテゴリCITYのリソース・カラムにおけるTokyoとNew Yorkの参照カウンタは、社員情報テーブルおよび顧客情報テーブルの両方から参照されていることを示し、refcount=2とされる一方、キー名＝Osakaの参照カウンタは、refcount=1に保持され、それぞれrefcount属性の値として設定されている。図２６の実施形態の場合に生成されるリソース参照情報テーブルのデータ構造を、テーブル２６３０に示す。リソース参照情報テーブル２６３０のでは、カテゴリCITYのリソース・テーブル２６００がEMPINFOのWORKLOCカラムとCUSTINFOのRESIDENCEが参照していることが記述されている。また、データ構造２６１０に示すように、キーにより相互参照可能とされている。

上述したように、リソース・テーブルを使用することで、複数のカラムから同一リソースを参照することが可能となっている。

以上のように、本発明によれば、多言語対応することが必要なデータであっても、それぞれの言語の値を保持するために同じ意味を持つレコードを複数作成したり、テーブルを分割して管理するといったことをすることなく、多言語データを効率的に管理することが可能となる。

本発明は、例えば、全世界の人々が参加可能な、インターネット掲示板に掲載されるメッセージなどを管理するためのデータベースの他、ウェブ・サイトのコンテンツをクライアント２３０の言語環境に適合させて提供するためのデータベースなどに適用することができ、既存のＤＢ２などのリレーショナル・データベースを拡張して実装することができる。

さらに本発明の上記機能処理部は、本発明を説明するための具体的な実施形態として説明したものであり、各機能は、特的の実装形式に対応し、情報処理装置のいかなる処理部の機能として実装されてもよい。

本実施形態の上記機能は、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、当該プログラムは、ハードディスク装置、ＣＤ−ＲＯＭ、ＭＯ、フレキシブルディスク、ＥＥＰＲＯＭ、ＥＰＲＯＭなどの装置可読な記録媒体に格納して頒布することができ、また他装置が可能な形式でネットワークを介して伝送することができる。

これまで本実施形態につき説明してきたが、本発明は、上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

本実施形態のデータベース・システム１００の実施形態。 クライアントが本実施形態の情報処理装置１１０に接続してから接続を切断するまでのシーケンスの実施形態。 情報処理装置１１０下とクライアントがセッションを開始し、終了するまでの処理の概略的なフローチャート。 本実施形態で、実装される、リソース・テーブルに対する処理を指令するコマンドと判断した場合の図３のステップＳ３０５の処理の詳細なフローチャート。 本実施形態で、テーブルに対する処理を実行するテーブル処理部１２４が実行する、図３のステップＳ３０４処理の詳細なフローチャート。 本実施形態で、図４のステップＳ４０６で、言語リソース処理部１２６が実行する、リソース・テーブルを作成する場合の概略的な処理のフローチャート。 本実施形態で、図５のステップＳ５０８で、テーブル処理部１２４が実行する、テーブルを作成する処理のフローチャート。 図４のステップＳ４０８の処理の詳細なフローチャート。 本実施形態に従い、リソース・テーブルに挿入されたデータ構造の実施形態。 本実施形態のリソース・テーブルに登録されたデータの更新処理のフローチャート。 本実施形態のリソース・テーブルに登録されたデータの更新処理を、スクリプトおよび構造化文書で記述されたデータを使用して説明する図。 本実施形態のリソース・テーブルに登録されたデータの削除処理のフローチャート。 本実施形態の情報処理装置１１０において、リソース・カラムを保持するテーブルにデータを挿入する処理のフローチャート。 図１３の処理に後続する処理のフローチャート。 本実施形態の情報処理装置１１０において、リソース・カラムを保持するテーブルに登録されたデータの更新を行う処理のフローチャート。 図１５の挿入処理の後続する処理のフローチャート。 本実施形態でリソース・カラムを保持するテーブルに登録されたデータの削除を行う処理のフローチャート。 図１７に後続する削除処理のフローチャート。 本実施形態で、テーブルを作成する際、リソース・カラムとして、カテゴリ名を指定しなかったテーブルの実施形態。 本実施形態で、テーブルを作成する際、リソース・カラムとして、カテゴリ名＝MTHを指定した実施形態。 本実施形態で、リソース・カラムを保持するテーブルがリソース・テーブルを参照していることを示す、リソース参照情報テーブル２１００の実施形態。 本実施形態の検索処理で生成される、SELECT文および対応する検索結果のデータ構造の実施形態。 本実施形態の検索処理の実施形態の他の実施形態。 本実施形態のリソース・カラムおよびリソース・テーブルの他の実施形態。 社員情報テーブルにいくつかのレコードが挿入された後の名前カラムのデータ構造２５００を示した図。 顧客情報テーブルおよびカテゴリCITYを有するリソース・テーブルおよびリソース参照情報テーブルのデータ構造を示した図。 多言語対応のために利用されている従来のデータベースのデータ構造を示した図。

符号の説明

１００…データベース・システム、１１０…情報処理装置、１１２…ネットワーク、１１４…ネットワーク・アダプタ、１１６…クライアント接続処理部、１１８…コマンド処理部、１２０…言語設定部、１２０ａ…レジスタ処理部、１２０ｂ…言語識別レジスタ、１２４…テーブル処理部、１２６…言語リソース処理部、１２８…他処理部、１３０…テーブル格納部、１３２…言語リソース・テーブル格納部

Claims (19)

1. 複数の言語環境を使用するクライアントからのアクセス要求を処理する情報処理装置であって、前記情報処理装置は、
   前記情報処理装置にアクセスする前記クライアントの言語環境を識別し、前記言語環境を設定する言語設定部と、
   前記言語設定部に前記クライアントの言語環境を指定する言語識別値を設定するクライアント接続処理部と、
   前記アクセス要求が含むコマンドを検査し、多言語処理を要求するコマンドの存在を判断するコマンド処理部と、
   前記コマンド処理部が前記多言語処理を要求すると判断した場合に前記コマンドを受領して、前記言語設定部に設定された前記言語環境によりデータベースにアクセスさせ、同一の値についての異なる言語で記述された値を含む複数の構造化文書を、前記データベースに対し、同一の値ごとのレコードに子要素として登録する言語リソース処理部と
   を含む情報処理装置。
2. 前記言語設定部は、前記情報処理装置がデフォルト設定として使用する言語環境を登録するデフォルト設定部を含み、前記クライアント接続処理部は、前記クライアントが当該セッション中に発行したアクセス要求含む言語識別値をクライアント言語環境として優先して登録する、請求項１に記載の情報処理装置。
3. 前記クライアント言語環境は、前記アクセス要求に含まれる言語識別値に応じて変更される、請求項２に記載の情報処理装置。
4. 前記情報処理装置は、前記クライアント言語環境を前記デフォルト設定よりも優先した言語環境として設定し、前記クライアントごとに異なるクライアント言語環境を提供する、請求項３に記載の情報処理装置。
5. 前記言語リソース処理部は、前記言語設定部により設定された言語環境を使用して前記構造化文書の挿入、更新、削除をそれぞれ実行させる、リソース・データ挿入部と、リソース・データ更新部と、リソース・データ削除部とを含む、請求項４に記載の情報処理装置。
6. 複数の言語環境を使用するクライアントからのアクセス要求を処理するデータベース・システムであって、前記データベース・システムは、
   前記情報処理装置にアクセスする前記クライアントの言語環境を識別し、前記言語環境を設定する言語設定部と、
   前記言語設定部に前記クライアントの言語環境を指定する言語識別値を設定するクライアント接続処理部と、
   前記アクセス要求が含むコマンドを検査し、多言語処理を要求するコマンドの存在を判断するコマンド処理部と、
   前記コマンド処理部が前記多言語処理を要求すると判断した場合に前記コマンドを受領して、前記言語設定部に設定された前記言語環境によりデータベースにアクセスさせ、同一の値についての異なる言語で記述された値を含む複数の構造化文書を、前記データベースに対し同一の値ごとのレコードに子要素として登録する言語リソース処理部とを含み、
   前記言語設定部は、前記情報処理装置の前記言語環境をデフォルト設定として登録するデフォルト設定部と、前記クライアントが当該セッション中に発行したアクセス要求が含む言語識別値をクライアント言語環境として登録するクライアント接続処理部と
   を含む、データベース・システム。
7. 前記言語設定部は、前記情報処理装置がデフォルト設定として使用する言語環境を登録するデフォルト設定部を含み、前記クライアント接続処理部は、前記クライアントが当該セッション中に発行したアクセス要求が含む言語識別値をクライアント言語環境として優先して登録する、請求項６に記載のデータベース・システム。
8. 前記言語リソース処理部は、前記言語設定部により設定された言語環境を使用して前記構造化文書の挿入、更新、削除をそれぞれ実行させる、リソース・データ挿入部と、リソース・データ更新部と、リソース・データ削除部とを含み、前記言語リソース処理部は、前記コマンド処理部が前記多言語処理を要求するコマンドであると判断した場合に当該コマンドを使用した前記データベースへのアクセスを実行する、請求項６に記載のデータベース・システム。
9. 前記クライアント言語環境は、前記アクセス要求に含まれる言語識別値に応じて変更される、請求項７に記載のデータベース・システム。
10. 前記データベース・システムは、前記クライアント言語環境を前記デフォルト設定よりも優先した言語環境として設定し、前記クライアントごとに異なるクライアント言語環境を提供する、請求項８に記載のデータベース・システム。
11. 複数の言語環境を使用するクライアントからのアクセス要求を処理する情報処理装置が実行する情報処理方法であって、前記情報処理装置が、
    前記情報処理装置にアクセスする前記クライアントの言語環境を識別し、言語環境を設定する言語設定部に、クライアント言語環境を指定する言語識別値を設定するステップと、
    前記アクセス要求が含むコマンドを検査し、多言語処理を要求するコマンドの存在を判断するステップと、
    前記多言語処理を要求するコマンドが存在すると判断した場合に前記コマンドを受領して、前記言語設定部に設定された前記言語環境によりデータベースにアクセスさせるステップと、
    同一の値についての異なる言語で記述された値を含む複数の構造化文書を、データベースに対して同一の値ごとのレコードに子要素として登録するステップと
    を実行する、情報処理方法。
12. 前記言語設定部は、前記データベースが管理するメモリ領域に確保され、前記言語識別値を設定するステップは、
    前記情報処理装置の前記言語環境をデフォルト設定として前記メモリ領域に登録するステップと、
    前記クライアントが発行したアクセス要求が含む言語識別値をクライアント言語環境として前記メモリ領域の異なるアドレスに登録するステップと
    を含む、請求項１１に記載の情報処理方法。
13. 前記同一の値ごとのレコードに子要素として登録するステップは、
    前記クライアント言語環境を前記デフォルト設定よりも優先した言語環境として前記子要素を作成し、前記レコードに登録するステップを含む、請求項１３に記載の情報処理方法。
14. さらに、前記クライアント言語環境を前記アクセス要求に含まれる言語識別値に応じて変更するステップを含む、請求項１３に記載の情報処理方法。
15. 複数の言語環境を使用するクライアントからのアクセス要求を処理する情報処理方法を情報処理装置が実行するためのコンピュータ実行可能なプログラムであって、前記プログラムは、前記情報処理装置が、
    前記情報処理装置にアクセスする前記クライアントの言語環境を識別し、言語環境を設定する言語設定部に、クライアント言語環境を指定する言語識別値を設定するステップと、
    前記アクセス要求が含むコマンドを検査し、多言語処理を要求するコマンドの存在を判断するステップと、
    前記多言語処理を要求するコマンドが存在すると判断した場合に前記コマンドを受領して、前記言語設定部に設定された前記言語環境によりデータベースにアクセスさせるステップと、
    同一の値についての異なる言語で記述された値を含む複数の構造化文書を、データベースに対して同一の値ごとのレコードに子要素として登録するステップと
    を実行する、コンピュータ実行可能なプログラム。
16. 前記言語設定部は、前記データベースが管理するメモリ領域に確保され、前記言語識別値を設定するステップは、
    前記情報処理装置の前記言語環境をデフォルト設定として前記メモリ領域に登録するステップと、
    前記クライアントが発行したアクセス要求が含む言語識別値をクライアント言語環境として前記メモリ領域の異なるアドレスに登録するステップと
    を含む、請求項１５に記載のプログラム。
17. 前記同一の値ごとのレコードに子要素として登録するステップは、
    前記クライアント言語環境を前記デフォルト設定よりも優先した言語環境として前記子要素を作成し、前記レコードに登録するステップを含む、請求項１６に記載のプログラム。
18. さらに、前記クライアント言語環境を前記アクセス要求に含まれる言語識別値に応じて変更するステップを含む、請求項１７に記載のプログラム。
19. 複数の言語環境を使用するクライアントからのアクセス要求を処理する情報処理装置であって、前記情報処理装置は、
    複数の言語環境を使用するクライアントからのアクセス要求を処理する情報処理装置であって、前記情報処理装置は、
    前記情報処理装置にアクセスする前記クライアントの言語環境を識別し、前記言語環境を設定する言語設定部と、
    前記言語設定部に前記クライアントの言語環境を指定する言語識別値を設定するクライアント接続処理部と、
    前記アクセス要求が含むコマンドを検査し、多言語処理を要求するコマンドの存在を判断するコマンド処理部と、
    前記コマンド処理部が前記多言語処理を要求すると判断した場合に前記コマンドを受領して、前記言語設定部に設定された前記言語環境によりデータベースにアクセスさせ、同一の値についての異なる言語で記述された値を含む複数の構造化文書を、前記データベースに対し同一の値ごとのレコードに子要素として登録する言語リソース処理部と
    を含み、
    前記言語設定部は、前記情報処理装置がデフォルト設定として使用する言語環境を登録するデフォルト設定部を含み、前記クライアント接続処理部は、前記クライアントが当該セッション中に発行したアクセス要求が含む言語識別値をクライアント言語環境として優先して登録し、
    前記クライアント言語環境は、前記アクセス要求に含まれる言語識別値に応じて変更され、前記クライアント言語環境を前記デフォルト設定よりも優先した言語環境として設定して、前記クライアントごとに異なるクライアント言語環境を提供し、
    前記言語リソース処理部は、前記言語設定部により設定された言語環境を使用して前記構造化文書の挿入、更新、削除をそれぞれ実行させる、リソース・データ挿入部と、リソース・データ更新部と、リソース・データ削除部とを含む、情報処理装置。

Images