(58)【調査した分野】(Int.Cl.,DB名)
少なくとも一つの列挙リストに適用される前記少なくとも一つのカタログ・テーブル中の変更について通報するイベントを受信すると、前記変更に関わる前記列挙リストを用いる前記要求全てについての前記算出された合致結果を削除し、前記変更に関わる前記列挙リストに対する新規カタログ値との合致を再算出することによって、前記永続ストレージ手段の内容をリフレッシュする、請求項2乃至3のいずれか1項に記載の方法。
前記少なくとも一つのカタログ・テーブル中の前記表現は、文字ストリングであり、前記表現の前記順序付けは、アルファベット順で行われる順序付けである、請求項1〜4のいずれか1項に記載の方法。
【発明の概要】
【発明が解決しようとする課題】
【0004】
データおよびカタログに対しSQLリレーショナル・データベースを用い、ロケールを使って変換された、列挙値に対応するソートされた文字ストリングを準備するソフトウェア・アプリケーションに対し、前述の欠点を回避することが必要となっている。なお、リレーショナル・システムは、いずれにせよ非常にコスト高のままであるJOIN SQLステートメントを一般に必要とするので、データベース・システム技術における多くの研究が、JOINの効率的な実装を目指してきている。
【課題を解決するための手段】
【0005】
本明細書では、列挙プログラミング変数値を格納する少なくとも一つのデータ・テーブルと、列挙プログラミング変数値の少なくとも一つの言語による表現を格納する少なくとも一つのカタログ・テーブルとを含む少なくとも一つのリレーショナル・データベースから読み取られた、特定の言語による列挙値のソートされた1つのリストを算出する方法が記載され、前記方法は、
− 特定の言語での特定の順序でソートされた特定の列挙リストの値の1つのリストを含む列挙変数値を提供することの要求を受信するステップと、
− 対応するカタログ・テーブルにおいて読み出された特定の列挙リストの変数値に対応する、前記特定の言語での表現の全てを特定の順序でソートするステップと、
− 特定の列挙表現値のソートされたリストが、同じカタログ・テーブル中で特定の順序でソートされた特定の列挙変数値のリストと合致する場合には、特定の順序でソートされた対応するデータ・テーブル中の特定の列挙変数値のリストを生成するステップであって、他の要求された列挙変数はデータ・テーブル中に在り、以降のステップをスキップする、該生成するステップと、
− 上記先行するステップで合致が見出せなかった場合には、該特定の列挙表現値のソートされたリストが、同じカタログ・テーブル中の該特定の順序の逆の順序でソートされた特定の列挙変数値のリストと合致する場合に、特定の順序の逆の順序でソートされた対応するデータ・テーブル中の特定の列挙変数値のリストを生成するステップであって、他の要求された列挙変数はデータ・テーブル中に在り、以降のステップをスキップする、該生成するステップと、
− これら2つの先行するステップのいずれにおいても合致が見出せなかった場合には、同じカタログ・テーブルと列挙変数値を包含するデータ・テーブルとを結合した新規テーブルを生成し、さらに、結合されたテーブルにおいて読み取られ、特定の言語による該特定の列挙変数値の表現をソートされた列挙変数値を有するリストを生成するステップであって、他の要求された列挙変数は該結合されたテーブル中に在る、該生成するステップと、
を含む。
【0006】
本方法は、
− 先行するステップにおいて実施される、前記要求の署名に関連付けられた合致の結果を永続ストレージ手段中に保存するステップと、
− 受信ステップを実行するステップと、
− 永続ストレージ手段中の当該要求に対する合致結果を読み探すステップと、
− 永続ストレージ手段中で合致が見出された場合には、合致の算出をスキップし、本方法の他のステップのソートされたリストの生成を直接実行するステップと、
をさらに含む。
【0007】
また、本方法は、
− 少なくとも一つのカタログ・テーブル中のあり得る全ての列挙変数および言語について合致結果を算出するステップと、
− 先行するステップで算出された合致の結果を永続ストレージ手段中に保存するステップを実施するステップと、
を有する初期ステップを含むことができ、
前記方法は、受信ステップの後、
− 永続ストレージ手段中の当該要求に対する合致結果を読み探すステップと、
− 永続ストレージ手段中に合致が見出された場合には、合致の算出をスキップし、本方法の他のステップのソートされたリストの生成を直接実行するステップと、
をさらに含む。
【0008】
また、本方法は、少なくとも一つの列挙リストに適用される少なくとも一つのカタログ・テーブル中の変更について通報するイベントを受信すると、該変更に関わる列挙リストを用いる要求全てについての算出された合致結果を削除し、該変更に関わる列挙リストに対する新規カタログ値との合致を再算出することによって、永続ストレージ手段の内容をリフレッシュするステップを含む。
【0009】
本方法において、少なくとも一つのカタログ・テーブル中の表現は、文字ストリングであり、該表現の順序付けは、アルファベット順に行われる順序付けである。
【0010】
本方法は、コンピュータ・プログラム製品であって、プログラムがコンピュータ上で実行されたとき、本方法のステップを実行するためのプログラミング・コード命令を含むコンピュータ・プログラム製品として実装することができる。
【0011】
また、請求された方法を実行するように適合された手段を含むシステムについても記載する。
【発明を実施するための形態】
【0013】
図1は、本発明の一実施形態の方法のコンピューティング環境を示す。例えば、サーバ上で作動するアプリケーション(100)がデータベース(120)を用いて、データをテーブル1(125)、…テーブルN…中に格納し、また、列挙変数値を特定の言語によるアプリケーションのエンドユーザに理解可能な表現に変換するために必要な入力を記述したロケール依存の情報を、カタログ1(130)、…カタログNに格納することを想定している。この図は単なる例示であって、テーブル、カタログの数は変えることが可能で、本実施形態の方法とは関係しない。クライアントによってアプリケーションに送信される要求のシンタックス(ハイレベルのプログラミング)およびクエリ(リレーショナル・データベースにアクセスするためのローレベルのプログラミングであって、今日ではSQLステートメントとして標準化されている)は、例示のためだけのものである。SQLディベロッパは、SELECT(選択する)のようなSQLステートメントを使ってデータベースにアクセスし、1つのデータベース・テーブルからの要素にアクセスする。但し、多くの場合、さらなる抽象化レイヤまたはAPIがあり、これはディベロッパのためタスクをより容易にしてくれる(getOrderedObjects(順序付けされたオブジェクトを得る)(ロケール)はその一例である)。このAPIは、ディベロッパが、リレーショナル・データベースにアクセスするための比較的ローレベルのクエリに関わるよりは、むしろ彼ら自身の専門域における作業をすることを可能にする。
【0014】
クライアント・アプリケーション(105)から、アプリケーションの列挙変数の値に従って順序付けされたオブジェクトのリストを入手するため、当該アプリケーションに要求が送信される。この要求は、何らかの結果をエンドユーザに対し表示するためのものとすることができる。この要求(110)のgetOrderedObjects(ロケール)は、列挙変数値の、アプリケーションのエンドユーザに対し理解可能な特定の言語(ロケール、パラメータとして与えられる)による表現への変換値によって順序付けされた、少なくとも一つの列挙変数を包含する、オブジェクトのリストに対する要求を指し、かかる変換値はカタログ中に格納される。言い換えれば、システムは、オブジェクトのリストに対する要求を取得する。本記載の方法は、
− 要求されたオブジェクトが、列挙型の少なくとも一つの変数を包含する、
− その列挙型はそのまま使われるのでなく、むしろ、(例えば、それをユーザに提示するために)カタログの中でそれをルック・アップすることによって対応するラベルに変換される、
− 要求されたオブジェクトのリストが、カタログから得られた前記ラベルによってソートされる、
場合は、直ちに適用される。
【0015】
なお、一つ以上のオブジェクトを要求することが可能で、処理が記載中の1つのオブジェクトに適用されれば、同様に、その記載の残りの部分中の1より多いオブジェクトにも適用が可能である。クライアントの要求を処理する標準的な仕方において、アプリケーションは、データ・テーブル(125)とカタログ・テーブル(130)とを結合してJOINテーブルを生成し、要求がある場合(110)それをソートする。本発明の一実施形態において、アプリケーションは、要求を受信すると、クエリを生成するために、アプリケーションの新規ソフトウェア・コンポーネント、クエリ・オプティマイザ(135)を必要とする。クエリ・オプティマイザは、最初に、列挙変数値ソートのどの処理を適用するかを決定する。最良の方策を決めるために、クエリ・オプティマイザは、データ・テーブルから列挙値を、カタログ・テーブル(115)からラベルを読み取り、ソート方策を算出し、次いでそれを使ってクエリが生成される。クエリ・オプティマイザは、順序付けされたリスト「(ロケール)によるOrderedObjects」(112)を要求元に、例えばクライアント・アプリケーション(105)に返す。なお、順序付けを、全面的にクエリ・オプティマイザ・コンポーネントに移譲し、該コンポーネントが順序付けされたリストを作成できるようにするといった変形も可能であろうが、こういった選択は、1つの特定言語で表現された列挙変数のソートを最適化するための全体的方法を変えるものではない。
【0016】
図3の説明において詳しく説明するように、ソートに対する要求(110)を処理する際に、好適な実施形態のプロセスは、どの場合にも、データ・テーブルとカタログ・テーブルとのJOINオペレーションを含む従来技術の恒例的プロセスに比べて、より速くより効率的なクエリを生成することができる。
【0017】
図2は、従来技術による、指定のロケールを使って列挙リストをソートするためのデータベース・テーブル管理の図である。例えばジョブ管理アプリケーションであるこのソフトウェア・アプリケーションは、アプリケーション_データ・テーブル(200)によって示されるように、データをソートするためリレーショナル・データベースを用いる。このテーブルは、ジョブの状態についての少なくとも一つの列(204)を含み、これは列挙値である。ソフトウェア・アプリケーションによって管理されるジョブの状態に対し使われる変数は、1文字の文字ストリングであり、コンピュータ・プログラムは多くの場合英語で記述されるので、ここでは、例えば、使われる値は、ジョブ状態に対する英単語の頭文字であると仮定しよう。「R」はReady(準備完了)であるジョブに対して、「S」はSubmitted(提出済み)ジョブに対して、「C」はComplete(完了)に、および「F」はFailed(不達成)に対して使われる。このジョブ管理アプリケーションは、データベースの列202中に、管理されるジョブのリストを維持し、列204中には、ジョブ管理アプリケーションは、対応する各ジョブに対する列挙変数値を維持する。この例では、ジョブJ1、J2、J3、およびJ4に焦点を当てるとしよう。
【0018】
別個に、ディベロッパはカタログ・データベース(210)を当初に生成しておくことができ、これは、列挙値に対応する、サポート対象の様々な言語全てに対する文字ストリングを包含する。英語言語に対するデータは、(Language(言語)に対する)Lang列212の中に格納された単語「English(英語)」を有する、カタログ・テーブル中の4つの行を含む。英言語に対するロケールの各行は少なくとも、PS(Possible States(取り得る状態))列214中には、ジョブ状況である型(列218中のJobstatus(ジョブ状況))に対する、列挙リストであるからには有限個の列挙値を含み、また、Label(ラベル)列216中には、対応する英語の理解可能な表現である英言語の文字ストリングを含む。変数値「R」の理解可能な文字ストリングは「Ready」である。同様に、列挙値とサポート対象言語との各ペアに対しこれらの文字ストリングが提供される。例えば、列212中に「Italian(イタリア語)」を有する行に対する言語Label列216中と、取り得る状態のPS列214中の変数値「R」中とから読み取れるように、イタリア語では、同じ変数値「R」に対する理解可能な表現は「Pronto(準備完了)」である。
【0019】
本発明の方法がサポートする列挙リストは、ジョブ状況の例(完了、不達成など)のように、カタログ・データベース中の特定の言語で文字ストリングとして表現することができる。表現を順序付けする際に、それをアルファベット順にすることもできようし、あるいは、時間もしくは日付または任意の好みの順序で定義することが可能である。同じ方法がこれらの他の例にも適用される。
【0020】
なお、アプリケーション_データ・テーブルおよびカタログ・テーブルには、本明細書で示すように各1つのテーブルを含めることも、あるいは、例えば、カタログ・テーブルに対して各言語に1つずつ、もっと多くのテーブルを含めることもできる。同様に、
図2の簡易化された例が従来技術の方法を説明するのに十分であるとしても、各テーブルはもっと多くの列を含むことが可能である。単なる一例として、アプリケーション_データは、ジョブのセットに対するジョブ・ストリームのIDを格納するための1つの追加列「Stream(ストリーム)」(206)を有することができる。このジョブ・ストリーム変数は、グループごとにジョブを管理するために、該例示的なジョブ管理アプリケーションにより使用される。また、カタログ・テーブルには、各種の列挙変数を含めることができ、
図2の例に対するその1つが、アプリケーション_データ・テーブル中の「State」変数と呼ばれるジョブ状況であり、これにより、カタログ・テーブル中で考察した行が、カタログ・テーブルの列「Type(型)」(218)で述べられた列挙変数「Jobstatus」に関連付けされる。カタログ・テーブル中のさらなる行を、Jobstatus以外の1つの「Type(型)」に対応させることができよう。カタログ・テーブル中の列Typeの中に「EarlyAction(早期処置)」を設けてもよく、この列挙変数は、特定の言語でのアルファベット順でソートする必要があるかもしれない(本文書中の他の1例を参照のこと)。この列挙変数は、当該ジョブに対し達成すべき処置を示す。
【0021】
このジョブ管理アプリケーションは、特定のロケールで1つの理解可能な値を見出すために、常にカタログ・データベースを用いることができる。該アプリケーションは、カタログの英語の行の中のキー(State=R)をルック・アップしてストリング「Ready」を見出し、またはカタログのイタリア語の行中のキーをルック・アップしてストリング「Pronto」を見出す。ジョブ管理アプリケーションが、或る時点で、列挙変数値およびそれらに対応する文字ストリング・ベースの表現のレコードを作成し、それらを文字ストリングのアルファベット順にソートすることが必要になった場合、最初に、JOINテーブルが動的に構築されることになる。ここに示されたJOINテーブル(220)は、少なくとも、アプリケーション_データ・テーブルのJobsおよびStateの列、並びにカタログ・テーブルに示された対応する状態ラベルを有する列を含む。実際上は、最初にアプリケーション_データ・テーブルとカタログ・テーブルとをJOIN(結合)し、次いで、そのJOINテーブル上でカタログ・ラベルのソート・オペレーションを実施する必要がある。
【0022】
プログラムが、リレーショナル・データベースにアクセスするために用いるSQLステートメントは、次のようにすればよい:
SELECT“或るもの”FROM“或るテーブル”WHERE“ここにデータの数を限定するためにある条件を規定することがある”
例えば、
SELECT (Jobs,State) FROM Application_data
WHERE (Application_data.Stream=‘S1’)
これは、
“Application_data”と名付けられたテーブル中の全ての行から“Jobs”および“State”と名付けられた列を選択せよ。但し、“Stream”と名付けられた列の値が“S1”であること
を意味し、テーブルのソートのプログラミングについては、
ORDER BY“或る基準によって結果を順序付けることを指定する”
となる。
【0023】
アプリケーションが、ジョブと、イタリア語で表現され、取り得るジョブ状態のアルファベット順にソートされたジョブの状態とのリストを表示する準備をするとすれば、該アプリケーションは、双方が一意的なテーブルを含む
図2のアプリケーション_データ(200)およびカタログ(210)のデータベース、並びにJOINテーブル(220)を生成するための以下のSQLステートメントを使うことになる:
SELECT (Jobs,State) FROM Application_data
JOIN Catalog ON Application_Data.State=Catalog.PS
WHERE (Catalog.Lang=‘Italian’)
【0024】
これらのステートメントは、
図2のJOINテーブル(220)を生成し、該テーブルは、値に対応する状態を含み、これら状態は、カタログ・テーブルのイタリア言語による対応ラベルである。このJOINテーブルは、列挙変数値(J1、J2、J3、およびJ4)であるジョブIDの第一列(222)を含み、該IDは、アプリケーション_データ・テーブル中のJobs列中に既存のものである。また、該テーブルは、列挙変数値(S、R、C、F)であるジョブ状態の第二列(224)を含み、該列は、アプリケーション_データ・テーブル中に既存のものである。第三列(226)は、カタログ・テーブルのLabel(216)から読み取られたラベルを含み、これらラベルは、イタリア言語に対するPS列(214)から読み取られた状態に対応し、これは、Lang列(212)が「Italian」を包含する行に対するものであることを意味する。JOINテーブル中のR状態に対しては、カタログ・テーブルから読み取られたLabelのProntoが関連付けられており、SにはInserito、CにはTerminato、そしてFにはFallitoが関連付けられている。
【0025】
結合テーブルが準備されたならば、アプリケーションは、以下のSQL節を用い、JOINテーブルに適用して、昇順のアルファベット順に従って、ラベル(226)の行を順序付けることができる。
ORDER BY Label ASC;
その結果は
図2のソートされたJOINテーブル(230)によって示されており、この中のJOINテーブル220の行は、列226中のイタリア言語による各ラベルのアルファベット順にソートされている(Fallito、Inserito、Pronto、そしてTerminato)。ソート済みのJOINテーブルは、アプリケーションのイタリア言語のユーザに対し、ジョブ状態値をイタリア言語で表した文字ストリングの昇順のアルファベット順にリストされた、アプリケーションに現在管理されているジョブのいろいろな状態を表示するため直接に用いることが可能である。
【0026】
図3は、本発明の一実施形態による方法のフローチャートである。本発明の一実施形態によれば、列挙変数の値の、特定のロケールによる文字ストリングを使った表現を作成する要求を処理するために、まず、ソート方策が決められる。
【0027】
その実装の一例は、入力としてOrdinalType(序数型)クラスおよびユーザのロケール(すなわち言語)を得てソート方策を決めるための解析システムである。次いで、このシステムは、入力型の内部表現に対応する値のリストと、対応するカタログからの変換バージョンを読み出す。入力の型がBooleanValue(ブール値)で、且つ言語が英語の場合、内部での値は、カタログ中の「Yes」および「No」に対応する「Y」および「N」である。
【0028】
該システムは、以下の3つのリストを生成する:
1.ASCENDING(昇)順でソートされた内部値
2.DESCENDING(降)順でソートされた内部値
3.ASCENDING順で、対応するカタログ・ストリングによってソートされた内部値。
【0029】
例えば、BooleanValueの場合、以下のリストが得られる:
1.(N,Y)
2.(Y,N)
3.ソート済みリスト(‘No’,‘Yes’)に対応する(N,Y)。
【0030】
なお、言語が英語の場合、対応するカタログ・ストリングによってASCENDING順にソートされた内部値は、(‘No’,‘Yes’)すなわち(N,Y)に対応し、1.は3.に合致する。また一方、言語がドイツ語の場合、対応するカタログ・ストリングによってASCENDING順にソートされた内部値は、(‘Ja’,‘Nein’)すなわち(Y,N)に対応し、2.は3.に合致する。
【0031】
次いで、本システムは、各特定の(列挙型,ロケール)ペアに対する最適のソート方策を、以下により決める:
− リスト#3がリスト#1に等しい場合は、方策は「カタログを無視し(JOINせずに)、列挙値をソートする」である
− リスト#3がリスト#2に等しい場合は、方策は「カタログを無視し(JOINせずに)、元のソート・オペレーションによって要求されたのと反対の順を使って列挙値をソートする(例えば、クエリが、カタログ・ストリング上をASCENDING順でソートしなければならない場合、所望の結果を得るためこの方策に従って、実際のクエリは、DESCENDING順で列挙値をソートされることになる)」である。
− 上記以外の場合は、方策は「カタログを使用する(テーブルをJOINし、エンドユーザのために要求された順序で文字ストリング上のソートを実施する)」である。
【0032】
この単純な例において、英語ロケールに対しリスト#3=リスト#1であり、したがって、方策は「カタログを無視し(JOINせずに)、列挙値をソートする」となる。
【0033】
この単純な例では、ドイツ語ロケールに対しリスト#3=リスト#2であり、したがって、方策は「カタログを無視し(JOINせずに)、元のソート・オペレーションによって要求されたのと反対の順を使って列挙値をソートする」となる。
【0034】
ソート方策は、型、ロケール(言語)、およびカタログ・テーブルの実際の内容の如何によるので、システムは全体的に動的である。
【0035】
もっと複雑な例を取り、3つの値、「A」(ABEND(異常終了))、「C」(CONTINUE(継続))、および「F」(CONFIRM(確認))を有する「EarlyAction」と名付けられた列挙された型が在ると仮定し、英語カタログを見てみよう。
A→ Abend
C→ Continue
F→ Confirm
【0036】
カタログ順では、リストはA、F、Cとしてソートする。これは、どの「ネイティブ」な順序とも合致せず、したがって、方策は「カタログを使用し」、「JOIN」を用いることになる:
SELECT * FROM Application_data
JOIN Catalog on Application_data.EarlyAction=Catalog.PS
WHERE(Catalog.LANG=‘English’and Catalog.Type=‘EarlyAction’)
ORDER BY Catalog.Label
【0037】
次にイタリア語カタログを検討してみよう:
A→ Fine anomala
C→ Continua
F→ Conferma
【0038】
カタログ順では、リストはF、C、Aとしてソートする。これは、逆向き(DESCENDING)のネイティブ順序に合致し、したがって、この場合、最良の方策は「カタログを無視し(JOINせずに)、元のソート・オペレーションによって要求されたのと反対の順を使って列挙値をソートする」である。
SELECT * FROM Application_data
ORDER BY Application_data.EarlyAction DESC
【0039】
このシステムを用いると、同じ使用クエリが、2つの全く異なるSQLステートメントを生成し、イタリア語カタログの実際の値を利用することによって、第二のクエリが最適化されており、効率的な仕方で遂行されることになる、ということがわかる。
【0040】
図3のフローチャートは、カタログ・データベース中に格納された1つの言語ロケール中の値に対応する文字ストリングのアルファベット順に順序付けして、アプリケーション_データ・データベースのアプリケーションに内部的な列挙変数の値の文字ストリングのリストを構築することに対する、標準的な要求をアプリケーションにおいて捕捉する第一ステップ(300)から開始される。同じことは複数の列挙値にも適用され、このことは上記の説明を変えるものではない。
【0041】
次いで、ソート方策が決められ、これは、対応するカタログ・ストリングによってASCENDING順でソートされた内部列挙値のリストを収集することから開始され、
図1のカタログ・テーブルでは、要求のロケールが英語の場合、その結果は、C、F、R、Sである。ASCENDING順でソートされた内部列挙値のリストが収集され、
図1のアプリケーション_データ・テーブルでは、要求のロケールが英語の場合、その結果は、C、F、R、Sである。この2つのリストが対比され(305)、その検査結果が肯定的であれば、上記の要求を実行する方策は、JOINを無視し、むしろ列挙変数値を直接ソートし(310)、要求の実行を終了させて、ソートされた列挙値をカタログ・データベース中の対応する文字ストリングに置換するため、アプリケーションに戻る(315)と決めることになる。
【0042】
この2つのリストが対比された(305)後、その検査結果が否定的であれば、DESCENDING順でソートされた内部列挙値のリストが収集され、対応するカタログ・ストリングによって、ASCENDING順でソートされた内部列挙値のリストと対比される(320)。その検査結果が肯定的であれば、上記の要求を実行する方策は、JOINを無視し、むしろ列挙変数値を直接ソートし(325)、要求の実行を終了させて、ソートされた列挙値をカタログ・データベース中の対応する文字ストリングに置換するため、アプリケーションに戻る(315)と決めることになる。
【0043】
対応するカタログ・ストリングによってASCENDING順でソートされた内部値と、DESCENDING順でソートされた内部値との合致をチェックする第二検査(320)の結果が否定的であれば、内部値とカタログとのJOINが実施される(330)(
図2のJOINテーブル220を得る)。次いで、JOINテーブル上でソートが実施される(335)(
図2のソート済みJOINテーブル230を得る)。次いで、プロセスはアプリケーションに戻り、該ソート済みJOINテーブルの内容は要求に対する結果を包含する。
【0044】
なお、このフローチャートは、特定の列挙リストのソートに対する要求があるときに実行される方法を表している。該要求が複数の列挙リスト(プログラム中のgetOrderedObjectの複数のプログラミング・オブジェクト)に対するものである場合、このフローチャートは各々の列挙リスト(各々のオブジェクト)に対して繰り返される。
【0045】
図4は、本発明の第二実施形態の方法のコンピューティング環境を示す。本発明の第二実施形態において、アプリケーションは第二機能によって強化されており、この機能はアプリケーション(100)の第二ソフトウェア・コンポーネント、「方策キャッシュ(Strategy Cache)」コンポーネント(400)として実装することが可能である。方策キャッシュ・コンポーネントは、これもアプリケーションに関連付けられており、特定の要求に対し、カタログ中の内容に従って、算出されたソート方策を格納するためのマネージャである。
図3で説明したように、ソートのための方策は、1つの所与の言語で記述された表現の列挙値変数をアルファベット順にソートする要求(110)getOrderedObjects(ロケール)に応えるための一切のソートを実施する前に算出される(305、320)。この方策は、各々のソート要求に対しクエリ・オプティマイザによって算出され、カタログが変わったときに変更することができる。クエリ・オプティマイザがソート方策を算出する際に、カタログ・テーブル、すなわち、指定された列挙型および言語に対するラベルのリストから、いくつかの情報が読み取られる。これらのデータの一切の変更をモニタする必要があり、カタログ中の或る特定の型の値を表すラベルが変更された場合、この型に対する方策は、再算出する必要があり、このとき、特定の型に対する1つの要求に対しクエリ・オプティマイザによって既に算出されているソート方策は、もはや使うことはできない。このとき、1つの要求に対しクエリ・オプティマイザによって既に算出されているソート方策は、もはや使うことはできない。方策キャッシュは、クエリ・オプティマイザよって以前に算出されたソート方策を、リポジトリ(420)に格納し、該方策は(キー,値)のペアを用いて符号化することが可能で、この値は、クエリ・オプティマイザによる最良の方策の算出の結果であって、どのような値も可能であり、結果が「データベース値をソートする」(310)であれば「1」とし、または「データベース値にREVERSE(逆順)ソートを実施する」(325)に対しては「2」とし、あるいは「JOINテーブルを生成し、JOINテーブルにソートを実施する」(330、335)に対しては「3」とすることなどができよう。上記のキーは、同じ出力を有すべき要求が同じキーを有するように、要求に関連付けられている。クエリ・オプティマイザは、所与の要求に対し算出された方策を方策キャッシュに送信し、該キャッシュはこの情報をリポジトリ中に格納する。
【0046】
なお、リポジトリは、コンピュータのための永続ストレージ手段の1つの型であって、上記と同じ方法は、永続ストレージ手段の任意の他の型にも適用される。
【0047】
方策キャッシュは、リポジトリ中の情報を正確に維持する。特定の型についてカタログが更新された場合、その型に対する方策は、要求に対してもはや有効でなく、方策キャッシュ・コンポーネントは、その型に関連する全ての情報を破棄する。クエリ・オプティマイザが、或る要求に対し或る方策を再使用する必要がある場合、該オプティマイザは、その方策を再算出し、その情報を方策キャッシュに再付与し、該キャッシュはそれをリポジトリ中に格納することになる。方策キャッシュは、データベース・トリガ(TRIGGER)からリポジトリ中の一切の変化の報告を受け、このトリガは、何らかの変化が生じたとき処置するため、リレーショナル・データベースが備えるメカニズムである。方策キャッシュによって、CatalogChange()(カタログ変更)(410)が受信され、これにより該キャッシュは、リポジトリから当該全情報を破棄し、クエリ・オプティマイザは、方策を再算出して、格納のためにそれを方策キャッシュ・コンポーネントに提供する必要がある。
【0048】
このリポジトリは、情報のペアを含み、これは、特定の要求を認識するために使われ、どのソート方策を適用するかを決めるため算出される合致の結果を認識するために使われる情報である。例として、要求の一切の署名が正当であること、検査結果に対して一切の変数が有効であることなどがある。
【0049】
図5は、本発明の第二実施形態による方法のフローチャートを示す。
図3の第一フローチャートに比べると、この第二実施形態に対応する随意的なステップ(340、342、345)が加えられている。
図3に示されたフローによって算出されるソート方策は、随意的に、永続リポジトリ(420)に保存することができる。このリポジトリが使われる場合、ソートが必要な時、指定された(列挙型,ユーザ言語)ペアに対するソート方策が見付かるどうか、まずリポジトリがチェックされ(検査340)、見付かった場合(検査340に対する「Yes」回答)、フローの残りの部分(すなわち、ステップ305を含めこのステップから始まる全てのステップ)は実行されない。
【0050】
また、リポジトリが使われる場合、アプリケーションの起動時にこれにポピュレートすることが可能である。そうする場合、アプリケーションの開始時に、該アプリケーションは、アプリケーションがサポートする必要のある全てのあり得る(列挙型,ユーザ言語)ペアを生成し、それらの各々に対する適切なソート方策を生成し、それをリポジトリに保存する。
【0051】
また、リポジトリが使われる場合、さらに動的な仕方でこれにポピュレートすることが可能である。そうする場合、アプリケーションは、ソート節(110)を有するクエリが発行されるまで待ち、その時点でリポジトリが存在し機能しているかどうかをチェックし、そして:
− リポジトリが存在する場合、アプリケーションはそれを使ってソート方策を読出して返し;
− リポジトリが存在しない場合、アプリケーションはそれを生成し、指定された(列挙型,ユーザ言語)ペアに対するエントリだけを算出して、リポジトリに加える。
【0052】
また、アプリケーションは、カタログの変更に対するモニタを行うことを決めることができる。カタログが変更された場合、アプリケーションは、ソート方策リポジトリをクリアして、次回にそれが使われるときは白紙から開始することを確実にする。これは、例えば、カタログ・テーブル上にデータベース・トリガ(410)を使って実装することができる。
【0053】
なお、上記説明および諸例はいくつかの特定のオブジェクトを取り扱っているが、本発明はローカライズ可能な値のセットから成る全ての種類の型に適用される。列挙型は、ユーザに直接表示できるものでなく「ストリングへの変換」ステップを必要とし、この「ストリングへの変換」ステップが、(値,ストリング)のペアを包含するテーブルをルック・アップすることによって実装される、任意のデータ型に一般化することができよう。
【0054】
記載した最適化法は、最初に、どの程度の頻度でこの最適化法を適用することが可能かということが問われよう。この回答は、列挙値、列挙リストの長さ、およびカタログ言語に多くを依存する。分散型コンピューティング環境において、ジョブ・スケジューリングを実施するアプリケーションについて、いくつかの西洋言語に対して収集された統計は、全事例の35%が最適化可能であることを示している。これはアプリケーションの如何によっても変わり得る。また、説明した最適化法は、該最適化法の使用からどのくらいの利得が得られるかということも問われよう。これは、主として、テーブルのサイズに依存し、論文に見られる典型的な値に基づけば、コスト高なJOINオペレーションの節減は、パフォーマンスを10倍(すなわち、1000%)以上向上することが可能であるが、実際的応用で見られる多くの要素に大きく影響されよう。
【0055】
リポジトリの使用は、同じ列挙リストに対し同じ要求が受信されたとき、最良の方策を決めるための検査の再実施を回避させてくれる。