(57)【特許請求の範囲】
【請求項１】
列挙変数値を格納する少なくとも一つのデータ・テーブルと、前記列挙変数値の少なくとも一つの言語による表現を格納する少なくとも一つのカタログ・テーブルとを含む少なくとも一つのリレーショナル・データベースから読み取られた、特定の言語による列挙値のソートされた１つのリストを算出する方法であって、前記方法は、
−  特定の言語での特定の順序でソートされた特定の列挙リストの列挙変数値の１つのリストを含む、列挙変数値を提供することの要求を受信するステップと、
−  対応するカタログ・テーブルにおいて読み出された前記特定の列挙リストの前記列挙変数値に対応する、前記特定の言語での前記表現の全てを前記特定の順序でソートするステップと、
−  前記特定の列挙表現値の前記ソートされたリストが、同じカタログ・テーブル中で前記特定の順序でソートされた前記特定の列挙変数値のリストと合致するか否かを判断し、合致しない場合には、前記特定の順序でソートされた対応する前記データ・テーブル中の前記特定の列挙変数値のリストを生成し、以降のステップをスキップする、ステップと、
−  前記先行するステップで前記合致が見出せなかった場合には、前記特定の列挙表現値の前記ソートされたリストが、前記同じカタログ・テーブル中の前記特定の順序の逆の順序でソートされた前記特定の列挙変数値のリストと合致するか否かを判断し、合致する場合に、前記特定の順序の前記逆の順序でソートされた前記対応するデータ・テーブル中の前記特定の列挙変数値のリストを生成し、以降のステップをスキップする、ステップと、
−  ２つの先行する前記ステップのいずれにおいても前記合致が見出せなかった場合には、前記同じカタログ・テーブルと前記列挙変数値を包含する前記データ・テーブルとを結合した新規テーブルを生成し、さらに、前記結合されたテーブルにおいて読み取られた前記列挙変数値が、前記特定の言語による前記特定の列挙変数値の前記表現に関してソートされたリストを生成すると、
を含む方法。
【請求項２】
−  前記先行するステップにおいて実施される、前記要求の署名に関連付けられた合致の結果を永続ストレージ手段中に保存するステップと、
−  前記受信ステップを実行するステップと、
−  前記永続ストレージ手段中の当該要求に対する前記合致結果を読み探すステップと、
−  前記永続ストレージ手段中で前記合致が見出された場合には、前記合致の算出をスキップし、前記方法の他の前記ステップのソートされたリストの前記生成を直接実行するステップと、
をさらに含む、請求項１に記載の方法。
【請求項３】
−  前記少なくとも一つのカタログ・テーブル中のあり得る全ての列挙変数および言語について合致結果を算出するステップと、
−  前記先行するステップで算出された合致結果を永続ストレージ手段中に保存するステップを実施するステップと、
を有する初期ステップをさらに含む請求項１に記載の方法であって、
前記方法は、前記受信ステップの後、
−  前記永続ストレージ手段中の当該要求に対する前記合致結果を読み探すステップと、
−  前記永続ストレージ手段中に前記合致が見出された場合には、前記合致の算出をスキップし、前記方法の他の前記ステップのソートされたリストの生成を直接実行するステップと、
をさらに含む、請求項１に記載の方法。
【請求項４】
少なくとも一つの列挙リストに適用される前記少なくとも一つのカタログ・テーブル中の変更について通報するイベントを受信すると、前記変更に関わる前記列挙リストを用いる前記要求全てについての前記算出された合致結果を削除し、前記変更に関わる前記列挙リストに対する新規カタログ値との合致を再算出することによって、前記永続ストレージ手段の内容をリフレッシュする、請求項２乃至３のいずれか１項に記載の方法。
【請求項５】
前記少なくとも一つのカタログ・テーブル中の前記表現は、文字ストリングであり、前記表現の前記順序付けは、アルファベット順で行われる順序付けである、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
コンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ上で実行されたとき、請求項１乃至５のいずれか１項に記載の前記方法の前記ステップを前記コンピュータに実行させるためのプログラミング・コード命令を含むコンピュータ・プログラム。
【請求項７】
請求項１乃至５のいずれか１項に記載の前記方法を実行するように適合された手段を含むシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティング・システムに関し、さらに具体的には、リレーショナル・データベースの操作に関する。すなわち、本発明は、リレーショナル・データベースの列挙テーブルをソート（整列）する方法を提供することを目的とする。
【背景技術】
【０００２】
列挙リスト（Ｅｎｕｍｅｒａｔｉｏｎｓ）は、意味のあるシーケンスに順序付けが可能な定性的分類のための名前付き序数値のセットである。一例として、コンピュータ上でジョブ・スケジューリングを管理するソフトウェア・アプリケーションに対し、列挙リストは、対応するオブジェクト状態によってジョブの状態を修飾するために用いられ、各状態は、取り得る状態の所定のセット｛ＲＥＡＤＹ，ＣＯＭＰＬＥＴＥＤ，ＦＡＩＬＥＤ，ＳＵＢＭＩＴＴＥＤ，…｝のうちの１つである。各状態は、文字ストリングとして表現される。しかしながら、ソフトウェア・アプリケーションの内部では、各値は、簡易化のため単純な列挙変数名と関連付けられることがある。例えば、内部変数として１文字ストリングを取れば、ＲＥＡＤＹ（準備完了）状態は「Ｒ」、ＳＵＢＭＩＴＴＥＤ（提出済み）は「Ｓ」などとすることができよう。プログラミング目的のため用いられるこれらの内部値は、これらを使うソフトウェア・アプリケーションのエンドユーザに対しては何の意味も持たない。しかしながら、アプリケーションのデータをエンドユーザに表示するために理解可能なレポートを作成する、あるいはアプリケーションのデータの理解可能な提示が必要な任意の他の場合において、全文字ストリングが必要となり、且つエンドユーザまたはレポート読者の言語が望ましいことになろう。例えば、英言語を使うエンドユーザは、ジョブが「ＲＥＡＤＹ」と述べられれば理解できようし、イタリア語を使うエンドユーザは、ジョブが「ＰＲＯＮＴＯ」と述べられれば理解できよう。これは、ジョブ状態の内部値が、ユーザ言語のロケールで読まれる文字ストリングに変換されることを意味する。なお、ここではロケールにおいて操作されるデータは、アルファベット順にソートが可能な文字ストリングである。列挙値は、何らかの仕方でソートできるものでありさえすれば何でもよく、バイナリ値でもよい。例えば、エンドユーザによるアプリケーションのデータを表示する命令を受けて、列挙変数値をソートする必要がある場合において、後記で説明するように、典型的なソフトウェア・アプリケーションに対して、従来技術では、エンドユーザの言語での文字ストリングを使って列挙変数値を表現する必要が文字ストリングをアルファベット順にソートすることを伴う場合、この要求は、処理時間およびストレージ・スペースの面からその実行コストは実に高くつく。
【０００３】
変数値を格納するためリレーショナル・データベースを用いる典型的なソフトウェア・アプリケーションは、これら列挙変数値に関連付けられた各種言語の文字ストリングを格納するために、追加の独立したテーブルであるカタログを用いることになる。エンドユーザの言語でエンドユーザに理解可能なように、アプリケーション変数値を整えるために、アプリケーションは、理解可能でない列挙内部変数値を、カタログ・テーブル中の該変数値に対応する文字ストリングを読み取ってそれらに変換する必要があろう。カタログ・リレーショナル・データベース上のデータにアクセスするために、アプリケーションはＳＱＬクエリを実行する。アプリケーションが、列挙変数値のロケールによる表現をアルファベット順にソートして、該列挙変数値を準備する必要がある場合、アプリケーションのデータ・テーブルとカタログ・テーブルとの間でＪＯＩＮ（結合）ＳＱＬステートメントが実行される。この２つのテーブルに対しＪＯＩＮをする理由は、カタログ・データベースの文字ストリングのアルファベット順でのソートは、カタログ・データベースの対応する列挙変数値とあわせ同時に実施しなければならないからである。ＪＯＩＮ  ＳＱＬオペレーションは、第一テーブルの各行の、第二テーブルの全ての行との全ての可能な組み合わせを生成することによって、２つのテーブルを結合する。すなわち、第一テーブル中の全（ｎ）行と第二テーブル中の全（ｍ）行とをロードし比較することを必要とするから、処理コストはｎ×ｍとなる。かくして、このオペレーションは、特に数千の処理対象オブジェクトがあるときは、コストは非常に高くなる。このことは、例えば、分散型コンピューティング環境において数十万のジョブをスケジューリングするジョブ管理アプリケーションなどのソフトウェア・アプリケーションのパフォーマンスに強い影響を及ぼす。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
データおよびカタログに対しＳＱＬリレーショナル・データベースを用い、ロケールを使って変換された、列挙値に対応するソートされた文字ストリングを準備するソフトウェア・アプリケーションに対し、前述の欠点を回避することが必要となっている。なお、リレーショナル・システムは、いずれにせよ非常にコスト高のままであるＪＯＩＮ  ＳＱＬステートメントを一般に必要とするので、データベース・システム技術における多くの研究が、ＪＯＩＮの効率的な実装を目指してきている。
【課題を解決するための手段】
【０００５】
本明細書では、列挙プログラミング変数値を格納する少なくとも一つのデータ・テーブルと、列挙プログラミング変数値の少なくとも一つの言語による表現を格納する少なくとも一つのカタログ・テーブルとを含む少なくとも一つのリレーショナル・データベースから読み取られた、特定の言語による列挙値のソートされた１つのリストを算出する方法が記載され、前記方法は、
−  特定の言語での特定の順序でソートされた特定の列挙リストの値の１つのリストを含む列挙変数値を提供することの要求を受信するステップと、
−  対応するカタログ・テーブルにおいて読み出された特定の列挙リストの変数値に対応する、前記特定の言語での表現の全てを特定の順序でソートするステップと、
−  特定の列挙表現値のソートされたリストが、同じカタログ・テーブル中で特定の順序でソートされた特定の列挙変数値のリストと合致する場合には、特定の順序でソートされた対応するデータ・テーブル中の特定の列挙変数値のリストを生成するステップであって、他の要求された列挙変数はデータ・テーブル中に在り、以降のステップをスキップする、該生成するステップと、
−  上記先行するステップで合致が見出せなかった場合には、該特定の列挙表現値のソートされたリストが、同じカタログ・テーブル中の該特定の順序の逆の順序でソートされた特定の列挙変数値のリストと合致する場合に、特定の順序の逆の順序でソートされた対応するデータ・テーブル中の特定の列挙変数値のリストを生成するステップであって、他の要求された列挙変数はデータ・テーブル中に在り、以降のステップをスキップする、該生成するステップと、
−  これら２つの先行するステップのいずれにおいても合致が見出せなかった場合には、同じカタログ・テーブルと列挙変数値を包含するデータ・テーブルとを結合した新規テーブルを生成し、さらに、結合されたテーブルにおいて読み取られ、特定の言語による該特定の列挙変数値の表現をソートされた列挙変数値を有するリストを生成するステップであって、他の要求された列挙変数は該結合されたテーブル中に在る、該生成するステップと、
を含む。
【０００６】
本方法は、
−  先行するステップにおいて実施される、前記要求の署名に関連付けられた合致の結果を永続ストレージ手段中に保存するステップと、
−  受信ステップを実行するステップと、
−  永続ストレージ手段中の当該要求に対する合致結果を読み探すステップと、
−  永続ストレージ手段中で合致が見出された場合には、合致の算出をスキップし、本方法の他のステップのソートされたリストの生成を直接実行するステップと、
をさらに含む。
【０００７】
また、本方法は、
−  少なくとも一つのカタログ・テーブル中のあり得る全ての列挙変数および言語について合致結果を算出するステップと、
−  先行するステップで算出された合致の結果を永続ストレージ手段中に保存するステップを実施するステップと、
を有する初期ステップを含むことができ、
前記方法は、受信ステップの後、
−  永続ストレージ手段中の当該要求に対する合致結果を読み探すステップと、
−  永続ストレージ手段中に合致が見出された場合には、合致の算出をスキップし、本方法の他のステップのソートされたリストの生成を直接実行するステップと、
をさらに含む。
【０００８】
また、本方法は、少なくとも一つの列挙リストに適用される少なくとも一つのカタログ・テーブル中の変更について通報するイベントを受信すると、該変更に関わる列挙リストを用いる要求全てについての算出された合致結果を削除し、該変更に関わる列挙リストに対する新規カタログ値との合致を再算出することによって、永続ストレージ手段の内容をリフレッシュするステップを含む。
【０００９】
本方法において、少なくとも一つのカタログ・テーブル中の表現は、文字ストリングであり、該表現の順序付けは、アルファベット順に行われる順序付けである。
【００１０】
本方法は、コンピュータ・プログラム製品であって、プログラムがコンピュータ上で実行されたとき、本方法のステップを実行するためのプログラミング・コード命令を含むコンピュータ・プログラム製品として実装することができる。
【００１１】
また、請求された方法を実行するように適合された手段を含むシステムについても記載する。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態の方法のコンピューティング環境を示す。
【図２】従来技術による、ロケールを使って列挙リストをソートするためのデータベース・テーブル管理の図である。
【図３】本発明の一実施形態による方法のフローチャートである。
【図４】本発明の第二実施形態の方法のコンピューティング環境を示す。
【図５】本発明の第二実施形態による方法のフローチャートを示す。
【発明を実施するための形態】
【００１３】
図１は、本発明の一実施形態の方法のコンピューティング環境を示す。例えば、サーバ上で作動するアプリケーション（１００）がデータベース（１２０）を用いて、データをテーブル１（１２５）、…テーブルＮ…中に格納し、また、列挙変数値を特定の言語によるアプリケーションのエンドユーザに理解可能な表現に変換するために必要な入力を記述したロケール依存の情報を、カタログ１（１３０）、…カタログＮに格納することを想定している。この図は単なる例示であって、テーブル、カタログの数は変えることが可能で、本実施形態の方法とは関係しない。クライアントによってアプリケーションに送信される要求のシンタックス（ハイレベルのプログラミング）およびクエリ（リレーショナル・データベースにアクセスするためのローレベルのプログラミングであって、今日ではＳＱＬステートメントとして標準化されている）は、例示のためだけのものである。ＳＱＬディベロッパは、ＳＥＬＥＣＴ（選択する）のようなＳＱＬステートメントを使ってデータベースにアクセスし、１つのデータベース・テーブルからの要素にアクセスする。但し、多くの場合、さらなる抽象化レイヤまたはＡＰＩがあり、これはディベロッパのためタスクをより容易にしてくれる（ｇｅｔＯｒｄｅｒｅｄＯｂｊｅｃｔｓ（順序付けされたオブジェクトを得る）（ロケール）はその一例である）。このＡＰＩは、ディベロッパが、リレーショナル・データベースにアクセスするための比較的ローレベルのクエリに関わるよりは、むしろ彼ら自身の専門域における作業をすることを可能にする。
【００１４】
クライアント・アプリケーション（１０５）から、アプリケーションの列挙変数の値に従って順序付けされたオブジェクトのリストを入手するため、当該アプリケーションに要求が送信される。この要求は、何らかの結果をエンドユーザに対し表示するためのものとすることができる。この要求（１１０）のｇｅｔＯｒｄｅｒｅｄＯｂｊｅｃｔｓ（ロケール）は、列挙変数値の、アプリケーションのエンドユーザに対し理解可能な特定の言語（ロケール、パラメータとして与えられる）による表現への変換値によって順序付けされた、少なくとも一つの列挙変数を包含する、オブジェクトのリストに対する要求を指し、かかる変換値はカタログ中に格納される。言い換えれば、システムは、オブジェクトのリストに対する要求を取得する。本記載の方法は、
−  要求されたオブジェクトが、列挙型の少なくとも一つの変数を包含する、
−  その列挙型はそのまま使われるのでなく、むしろ、（例えば、それをユーザに提示するために）カタログの中でそれをルック・アップすることによって対応するラベルに変換される、
−  要求されたオブジェクトのリストが、カタログから得られた前記ラベルによってソートされる、
場合は、直ちに適用される。
【００１５】
なお、一つ以上のオブジェクトを要求することが可能で、処理が記載中の１つのオブジェクトに適用されれば、同様に、その記載の残りの部分中の１より多いオブジェクトにも適用が可能である。クライアントの要求を処理する標準的な仕方において、アプリケーションは、データ・テーブル（１２５）とカタログ・テーブル（１３０）とを結合してＪＯＩＮテーブルを生成し、要求がある場合（１１０）それをソートする。本発明の一実施形態において、アプリケーションは、要求を受信すると、クエリを生成するために、アプリケーションの新規ソフトウェア・コンポーネント、クエリ・オプティマイザ（１３５）を必要とする。クエリ・オプティマイザは、最初に、列挙変数値ソートのどの処理を適用するかを決定する。最良の方策を決めるために、クエリ・オプティマイザは、データ・テーブルから列挙値を、カタログ・テーブル（１１５）からラベルを読み取り、ソート方策を算出し、次いでそれを使ってクエリが生成される。クエリ・オプティマイザは、順序付けされたリスト「（ロケール）によるＯｒｄｅｒｅｄＯｂｊｅｃｔｓ」（１１２）を要求元に、例えばクライアント・アプリケーション（１０５）に返す。なお、順序付けを、全面的にクエリ・オプティマイザ・コンポーネントに移譲し、該コンポーネントが順序付けされたリストを作成できるようにするといった変形も可能であろうが、こういった選択は、１つの特定言語で表現された列挙変数のソートを最適化するための全体的方法を変えるものではない。
【００１６】
図３の説明において詳しく説明するように、ソートに対する要求（１１０）を処理する際に、好適な実施形態のプロセスは、どの場合にも、データ・テーブルとカタログ・テーブルとのＪＯＩＮオペレーションを含む従来技術の恒例的プロセスに比べて、より速くより効率的なクエリを生成することができる。
【００１７】
図２は、従来技術による、指定のロケールを使って列挙リストをソートするためのデータベース・テーブル管理の図である。例えばジョブ管理アプリケーションであるこのソフトウェア・アプリケーションは、アプリケーション＿データ・テーブル（２００）によって示されるように、データをソートするためリレーショナル・データベースを用いる。このテーブルは、ジョブの状態についての少なくとも一つの列（２０４）を含み、これは列挙値である。ソフトウェア・アプリケーションによって管理されるジョブの状態に対し使われる変数は、１文字の文字ストリングであり、コンピュータ・プログラムは多くの場合英語で記述されるので、ここでは、例えば、使われる値は、ジョブ状態に対する英単語の頭文字であると仮定しよう。「Ｒ」はＲｅａｄｙ（準備完了）であるジョブに対して、「Ｓ」はＳｕｂｍｉｔｔｅｄ（提出済み）ジョブに対して、「Ｃ」はＣｏｍｐｌｅｔｅ（完了）に、および「Ｆ」はＦａｉｌｅｄ（不達成）に対して使われる。このジョブ管理アプリケーションは、データベースの列２０２中に、管理されるジョブのリストを維持し、列２０４中には、ジョブ管理アプリケーションは、対応する各ジョブに対する列挙変数値を維持する。この例では、ジョブＪ１、Ｊ２、Ｊ３、およびＪ４に焦点を当てるとしよう。
【００１８】
別個に、ディベロッパはカタログ・データベース（２１０）を当初に生成しておくことができ、これは、列挙値に対応する、サポート対象の様々な言語全てに対する文字ストリングを包含する。英語言語に対するデータは、（Ｌａｎｇｕａｇｅ（言語）に対する）Ｌａｎｇ列２１２の中に格納された単語「Ｅｎｇｌｉｓｈ（英語）」を有する、カタログ・テーブル中の４つの行を含む。英言語に対するロケールの各行は少なくとも、ＰＳ（Ｐｏｓｓｉｂｌｅ  Ｓｔａｔｅｓ（取り得る状態））列２１４中には、ジョブ状況である型（列２１８中のＪｏｂｓｔａｔｕｓ（ジョブ状況））に対する、列挙リストであるからには有限個の列挙値を含み、また、Ｌａｂｅｌ（ラベル）列２１６中には、対応する英語の理解可能な表現である英言語の文字ストリングを含む。変数値「Ｒ」の理解可能な文字ストリングは「Ｒｅａｄｙ」である。同様に、列挙値とサポート対象言語との各ペアに対しこれらの文字ストリングが提供される。例えば、列２１２中に「Ｉｔａｌｉａｎ（イタリア語）」を有する行に対する言語Ｌａｂｅｌ列２１６中と、取り得る状態のＰＳ列２１４中の変数値「Ｒ」中とから読み取れるように、イタリア語では、同じ変数値「Ｒ」に対する理解可能な表現は「Ｐｒｏｎｔｏ（準備完了）」である。
【００１９】
本発明の方法がサポートする列挙リストは、ジョブ状況の例（完了、不達成など）のように、カタログ・データベース中の特定の言語で文字ストリングとして表現することができる。表現を順序付けする際に、それをアルファベット順にすることもできようし、あるいは、時間もしくは日付または任意の好みの順序で定義することが可能である。同じ方法がこれらの他の例にも適用される。
【００２０】
なお、アプリケーション＿データ・テーブルおよびカタログ・テーブルには、本明細書で示すように各１つのテーブルを含めることも、あるいは、例えば、カタログ・テーブルに対して各言語に１つずつ、もっと多くのテーブルを含めることもできる。同様に、図２の簡易化された例が従来技術の方法を説明するのに十分であるとしても、各テーブルはもっと多くの列を含むことが可能である。単なる一例として、アプリケーション＿データは、ジョブのセットに対するジョブ・ストリームのＩＤを格納するための１つの追加列「Ｓｔｒｅａｍ（ストリーム）」（２０６）を有することができる。このジョブ・ストリーム変数は、グループごとにジョブを管理するために、該例示的なジョブ管理アプリケーションにより使用される。また、カタログ・テーブルには、各種の列挙変数を含めることができ、図２の例に対するその１つが、アプリケーション＿データ・テーブル中の「Ｓｔａｔｅ」変数と呼ばれるジョブ状況であり、これにより、カタログ・テーブル中で考察した行が、カタログ・テーブルの列「Ｔｙｐｅ（型）」（２１８）で述べられた列挙変数「Ｊｏｂｓｔａｔｕｓ」に関連付けされる。カタログ・テーブル中のさらなる行を、Ｊｏｂｓｔａｔｕｓ以外の１つの「Ｔｙｐｅ（型）」に対応させることができよう。カタログ・テーブル中の列Ｔｙｐｅの中に「ＥａｒｌｙＡｃｔｉｏｎ（早期処置）」を設けてもよく、この列挙変数は、特定の言語でのアルファベット順でソートする必要があるかもしれない（本文書中の他の１例を参照のこと）。この列挙変数は、当該ジョブに対し達成すべき処置を示す。
【００２１】
このジョブ管理アプリケーションは、特定のロケールで１つの理解可能な値を見出すために、常にカタログ・データベースを用いることができる。該アプリケーションは、カタログの英語の行の中のキー（Ｓｔａｔｅ＝Ｒ）をルック・アップしてストリング「Ｒｅａｄｙ」を見出し、またはカタログのイタリア語の行中のキーをルック・アップしてストリング「Ｐｒｏｎｔｏ」を見出す。ジョブ管理アプリケーションが、或る時点で、列挙変数値およびそれらに対応する文字ストリング・ベースの表現のレコードを作成し、それらを文字ストリングのアルファベット順にソートすることが必要になった場合、最初に、ＪＯＩＮテーブルが動的に構築されることになる。ここに示されたＪＯＩＮテーブル（２２０）は、少なくとも、アプリケーション＿データ・テーブルのＪｏｂｓおよびＳｔａｔｅの列、並びにカタログ・テーブルに示された対応する状態ラベルを有する列を含む。実際上は、最初にアプリケーション＿データ・テーブルとカタログ・テーブルとをＪＯＩＮ（結合）し、次いで、そのＪＯＩＮテーブル上でカタログ・ラベルのソート・オペレーションを実施する必要がある。
【００２２】
プログラムが、リレーショナル・データベースにアクセスするために用いるＳＱＬステートメントは、次のようにすればよい：
ＳＥＬＥＣＴ“或るもの”ＦＲＯＭ“或るテーブル”ＷＨＥＲＥ“ここにデータの数を限定するためにある条件を規定することがある”
例えば、
ＳＥＬＥＣＴ  （Ｊｏｂｓ，Ｓｔａｔｅ）  ＦＲＯＭ  Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ
ＷＨＥＲＥ  （Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ．Ｓｔｒｅａｍ＝‘Ｓ１’）
これは、
“Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ”と名付けられたテーブル中の全ての行から“Ｊｏｂｓ”および“Ｓｔａｔｅ”と名付けられた列を選択せよ。但し、“Ｓｔｒｅａｍ”と名付けられた列の値が“Ｓ１”であること
を意味し、テーブルのソートのプログラミングについては、
ＯＲＤＥＲ  ＢＹ“或る基準によって結果を順序付けることを指定する”
となる。
【００２３】
アプリケーションが、ジョブと、イタリア語で表現され、取り得るジョブ状態のアルファベット順にソートされたジョブの状態とのリストを表示する準備をするとすれば、該アプリケーションは、双方が一意的なテーブルを含む図２のアプリケーション＿データ（２００）およびカタログ（２１０）のデータベース、並びにＪＯＩＮテーブル（２２０）を生成するための以下のＳＱＬステートメントを使うことになる：
ＳＥＬＥＣＴ  （Ｊｏｂｓ，Ｓｔａｔｅ）  ＦＲＯＭ  Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ
ＪＯＩＮ  Ｃａｔａｌｏｇ  ＯＮ  Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ．Ｓｔａｔｅ＝Ｃａｔａｌｏｇ．ＰＳ
ＷＨＥＲＥ  （Ｃａｔａｌｏｇ．Ｌａｎｇ＝‘Ｉｔａｌｉａｎ’）
【００２４】
これらのステートメントは、図２のＪＯＩＮテーブル（２２０）を生成し、該テーブルは、値に対応する状態を含み、これら状態は、カタログ・テーブルのイタリア言語による対応ラベルである。このＪＯＩＮテーブルは、列挙変数値（Ｊ１、Ｊ２、Ｊ３、およびＪ４）であるジョブＩＤの第一列（２２２）を含み、該ＩＤは、アプリケーション＿データ・テーブル中のＪｏｂｓ列中に既存のものである。また、該テーブルは、列挙変数値（Ｓ、Ｒ、Ｃ、Ｆ）であるジョブ状態の第二列（２２４）を含み、該列は、アプリケーション＿データ・テーブル中に既存のものである。第三列（２２６）は、カタログ・テーブルのＬａｂｅｌ（２１６）から読み取られたラベルを含み、これらラベルは、イタリア言語に対するＰＳ列（２１４）から読み取られた状態に対応し、これは、Ｌａｎｇ列（２１２）が「Ｉｔａｌｉａｎ」を包含する行に対するものであることを意味する。ＪＯＩＮテーブル中のＲ状態に対しては、カタログ・テーブルから読み取られたＬａｂｅｌのＰｒｏｎｔｏが関連付けられており、ＳにはＩｎｓｅｒｉｔｏ、ＣにはＴｅｒｍｉｎａｔｏ、そしてＦにはＦａｌｌｉｔｏが関連付けられている。
【００２５】
結合テーブルが準備されたならば、アプリケーションは、以下のＳＱＬ節を用い、ＪＯＩＮテーブルに適用して、昇順のアルファベット順に従って、ラベル（２２６）の行を順序付けることができる。
ＯＲＤＥＲ  ＢＹ  Ｌａｂｅｌ  ＡＳＣ；
その結果は図２のソートされたＪＯＩＮテーブル（２３０）によって示されており、この中のＪＯＩＮテーブル２２０の行は、列２２６中のイタリア言語による各ラベルのアルファベット順にソートされている（Ｆａｌｌｉｔｏ、Ｉｎｓｅｒｉｔｏ、Ｐｒｏｎｔｏ、そしてＴｅｒｍｉｎａｔｏ）。ソート済みのＪＯＩＮテーブルは、アプリケーションのイタリア言語のユーザに対し、ジョブ状態値をイタリア言語で表した文字ストリングの昇順のアルファベット順にリストされた、アプリケーションに現在管理されているジョブのいろいろな状態を表示するため直接に用いることが可能である。
【００２６】
図３は、本発明の一実施形態による方法のフローチャートである。本発明の一実施形態によれば、列挙変数の値の、特定のロケールによる文字ストリングを使った表現を作成する要求を処理するために、まず、ソート方策が決められる。
【００２７】
その実装の一例は、入力としてＯｒｄｉｎａｌＴｙｐｅ（序数型）クラスおよびユーザのロケール（すなわち言語）を得てソート方策を決めるための解析システムである。次いで、このシステムは、入力型の内部表現に対応する値のリストと、対応するカタログからの変換バージョンを読み出す。入力の型がＢｏｏｌｅａｎＶａｌｕｅ（ブール値）で、且つ言語が英語の場合、内部での値は、カタログ中の「Ｙｅｓ」および「Ｎｏ」に対応する「Ｙ」および「Ｎ」である。
【００２８】
該システムは、以下の３つのリストを生成する：
１．ＡＳＣＥＮＤＩＮＧ（昇）順でソートされた内部値
２．ＤＥＳＣＥＮＤＩＮＧ（降）順でソートされた内部値
３．ＡＳＣＥＮＤＩＮＧ順で、対応するカタログ・ストリングによってソートされた内部値。
【００２９】
例えば、ＢｏｏｌｅａｎＶａｌｕｅの場合、以下のリストが得られる：
１．（Ｎ，Ｙ）
２．（Ｙ，Ｎ）
３．ソート済みリスト（‘Ｎｏ’，‘Ｙｅｓ’）に対応する（Ｎ，Ｙ）。
【００３０】
なお、言語が英語の場合、対応するカタログ・ストリングによってＡＳＣＥＮＤＩＮＧ順にソートされた内部値は、（‘Ｎｏ’，‘Ｙｅｓ’）すなわち（Ｎ，Ｙ）に対応し、１．は３．に合致する。また一方、言語がドイツ語の場合、対応するカタログ・ストリングによってＡＳＣＥＮＤＩＮＧ順にソートされた内部値は、（‘Ｊａ’，‘Ｎｅｉｎ’）すなわち（Ｙ，Ｎ）に対応し、２．は３．に合致する。
【００３１】
次いで、本システムは、各特定の（列挙型，ロケール）ペアに対する最適のソート方策を、以下により決める：
−  リスト＃３がリスト＃１に等しい場合は、方策は「カタログを無視し（ＪＯＩＮせずに）、列挙値をソートする」である
−  リスト＃３がリスト＃２に等しい場合は、方策は「カタログを無視し（ＪＯＩＮせずに）、元のソート・オペレーションによって要求されたのと反対の順を使って列挙値をソートする（例えば、クエリが、カタログ・ストリング上をＡＳＣＥＮＤＩＮＧ順でソートしなければならない場合、所望の結果を得るためこの方策に従って、実際のクエリは、ＤＥＳＣＥＮＤＩＮＧ順で列挙値をソートされることになる）」である。
−  上記以外の場合は、方策は「カタログを使用する（テーブルをＪＯＩＮし、エンドユーザのために要求された順序で文字ストリング上のソートを実施する）」である。
【００３２】
この単純な例において、英語ロケールに対しリスト＃３＝リスト＃１であり、したがって、方策は「カタログを無視し（ＪＯＩＮせずに）、列挙値をソートする」となる。
【００３３】
この単純な例では、ドイツ語ロケールに対しリスト＃３＝リスト＃２であり、したがって、方策は「カタログを無視し（ＪＯＩＮせずに）、元のソート・オペレーションによって要求されたのと反対の順を使って列挙値をソートする」となる。
【００３４】
ソート方策は、型、ロケール（言語）、およびカタログ・テーブルの実際の内容の如何によるので、システムは全体的に動的である。
【００３５】
もっと複雑な例を取り、３つの値、「Ａ」（ＡＢＥＮＤ（異常終了））、「Ｃ」（ＣＯＮＴＩＮＵＥ（継続））、および「Ｆ」（ＣＯＮＦＩＲＭ（確認））を有する「ＥａｒｌｙＡｃｔｉｏｎ」と名付けられた列挙された型が在ると仮定し、英語カタログを見てみよう。
Ａ→  Ａｂｅｎｄ
Ｃ→  Ｃｏｎｔｉｎｕｅ
Ｆ→  Ｃｏｎｆｉｒｍ
【００３６】
カタログ順では、リストはＡ、Ｆ、Ｃとしてソートする。これは、どの「ネイティブ」な順序とも合致せず、したがって、方策は「カタログを使用し」、「ＪＯＩＮ」を用いることになる：
ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ
ＪＯＩＮ  Ｃａｔａｌｏｇ  ｏｎ  Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ．ＥａｒｌｙＡｃｔｉｏｎ＝Ｃａｔａｌｏｇ．ＰＳ
ＷＨＥＲＥ（Ｃａｔａｌｏｇ．ＬＡＮＧ＝‘Ｅｎｇｌｉｓｈ’ａｎｄ  Ｃａｔａｌｏｇ．Ｔｙｐｅ＝‘ＥａｒｌｙＡｃｔｉｏｎ’）
ＯＲＤＥＲ  ＢＹ  Ｃａｔａｌｏｇ．Ｌａｂｅｌ
【００３７】
次にイタリア語カタログを検討してみよう：
Ａ→  Ｆｉｎｅ  ａｎｏｍａｌａ
Ｃ→  Ｃｏｎｔｉｎｕａ
Ｆ→  Ｃｏｎｆｅｒｍａ
【００３８】
カタログ順では、リストはＦ、Ｃ、Ａとしてソートする。これは、逆向き（ＤＥＳＣＥＮＤＩＮＧ）のネイティブ順序に合致し、したがって、この場合、最良の方策は「カタログを無視し（ＪＯＩＮせずに）、元のソート・オペレーションによって要求されたのと反対の順を使って列挙値をソートする」である。
ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ
ＯＲＤＥＲ  ＢＹ  Ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ．ＥａｒｌｙＡｃｔｉｏｎ  ＤＥＳＣ
【００３９】
このシステムを用いると、同じ使用クエリが、２つの全く異なるＳＱＬステートメントを生成し、イタリア語カタログの実際の値を利用することによって、第二のクエリが最適化されており、効率的な仕方で遂行されることになる、ということがわかる。
【００４０】
図３のフローチャートは、カタログ・データベース中に格納された１つの言語ロケール中の値に対応する文字ストリングのアルファベット順に順序付けして、アプリケーション＿データ・データベースのアプリケーションに内部的な列挙変数の値の文字ストリングのリストを構築することに対する、標準的な要求をアプリケーションにおいて捕捉する第一ステップ（３００）から開始される。同じことは複数の列挙値にも適用され、このことは上記の説明を変えるものではない。
【００４１】
次いで、ソート方策が決められ、これは、対応するカタログ・ストリングによってＡＳＣＥＮＤＩＮＧ順でソートされた内部列挙値のリストを収集することから開始され、図１のカタログ・テーブルでは、要求のロケールが英語の場合、その結果は、Ｃ、Ｆ、Ｒ、Ｓである。ＡＳＣＥＮＤＩＮＧ順でソートされた内部列挙値のリストが収集され、図１のアプリケーション＿データ・テーブルでは、要求のロケールが英語の場合、その結果は、Ｃ、Ｆ、Ｒ、Ｓである。この２つのリストが対比され（３０５）、その検査結果が肯定的であれば、上記の要求を実行する方策は、ＪＯＩＮを無視し、むしろ列挙変数値を直接ソートし（３１０）、要求の実行を終了させて、ソートされた列挙値をカタログ・データベース中の対応する文字ストリングに置換するため、アプリケーションに戻る（３１５）と決めることになる。
【００４２】
この２つのリストが対比された（３０５）後、その検査結果が否定的であれば、ＤＥＳＣＥＮＤＩＮＧ順でソートされた内部列挙値のリストが収集され、対応するカタログ・ストリングによって、ＡＳＣＥＮＤＩＮＧ順でソートされた内部列挙値のリストと対比される（３２０）。その検査結果が肯定的であれば、上記の要求を実行する方策は、ＪＯＩＮを無視し、むしろ列挙変数値を直接ソートし（３２５）、要求の実行を終了させて、ソートされた列挙値をカタログ・データベース中の対応する文字ストリングに置換するため、アプリケーションに戻る（３１５）と決めることになる。
【００４３】
対応するカタログ・ストリングによってＡＳＣＥＮＤＩＮＧ順でソートされた内部値と、ＤＥＳＣＥＮＤＩＮＧ順でソートされた内部値との合致をチェックする第二検査（３２０）の結果が否定的であれば、内部値とカタログとのＪＯＩＮが実施される（３３０）（図２のＪＯＩＮテーブル２２０を得る）。次いで、ＪＯＩＮテーブル上でソートが実施される（３３５）（図２のソート済みＪＯＩＮテーブル２３０を得る）。次いで、プロセスはアプリケーションに戻り、該ソート済みＪＯＩＮテーブルの内容は要求に対する結果を包含する。
【００４４】
なお、このフローチャートは、特定の列挙リストのソートに対する要求があるときに実行される方法を表している。該要求が複数の列挙リスト（プログラム中のｇｅｔＯｒｄｅｒｅｄＯｂｊｅｃｔの複数のプログラミング・オブジェクト）に対するものである場合、このフローチャートは各々の列挙リスト（各々のオブジェクト）に対して繰り返される。
【００４５】
図４は、本発明の第二実施形態の方法のコンピューティング環境を示す。本発明の第二実施形態において、アプリケーションは第二機能によって強化されており、この機能はアプリケーション（１００）の第二ソフトウェア・コンポーネント、「方策キャッシュ（Ｓｔｒａｔｅｇｙ  Ｃａｃｈｅ）」コンポーネント（４００）として実装することが可能である。方策キャッシュ・コンポーネントは、これもアプリケーションに関連付けられており、特定の要求に対し、カタログ中の内容に従って、算出されたソート方策を格納するためのマネージャである。図３で説明したように、ソートのための方策は、１つの所与の言語で記述された表現の列挙値変数をアルファベット順にソートする要求（１１０）ｇｅｔＯｒｄｅｒｅｄＯｂｊｅｃｔｓ（ロケール）に応えるための一切のソートを実施する前に算出される（３０５、３２０）。この方策は、各々のソート要求に対しクエリ・オプティマイザによって算出され、カタログが変わったときに変更することができる。クエリ・オプティマイザがソート方策を算出する際に、カタログ・テーブル、すなわち、指定された列挙型および言語に対するラベルのリストから、いくつかの情報が読み取られる。これらのデータの一切の変更をモニタする必要があり、カタログ中の或る特定の型の値を表すラベルが変更された場合、この型に対する方策は、再算出する必要があり、このとき、特定の型に対する１つの要求に対しクエリ・オプティマイザによって既に算出されているソート方策は、もはや使うことはできない。このとき、１つの要求に対しクエリ・オプティマイザによって既に算出されているソート方策は、もはや使うことはできない。方策キャッシュは、クエリ・オプティマイザよって以前に算出されたソート方策を、リポジトリ（４２０）に格納し、該方策は（キー，値）のペアを用いて符号化することが可能で、この値は、クエリ・オプティマイザによる最良の方策の算出の結果であって、どのような値も可能であり、結果が「データベース値をソートする」（３１０）であれば「１」とし、または「データベース値にＲＥＶＥＲＳＥ（逆順）ソートを実施する」（３２５）に対しては「２」とし、あるいは「ＪＯＩＮテーブルを生成し、ＪＯＩＮテーブルにソートを実施する」（３３０、３３５）に対しては「３」とすることなどができよう。上記のキーは、同じ出力を有すべき要求が同じキーを有するように、要求に関連付けられている。クエリ・オプティマイザは、所与の要求に対し算出された方策を方策キャッシュに送信し、該キャッシュはこの情報をリポジトリ中に格納する。
【００４６】
なお、リポジトリは、コンピュータのための永続ストレージ手段の１つの型であって、上記と同じ方法は、永続ストレージ手段の任意の他の型にも適用される。
【００４７】
方策キャッシュは、リポジトリ中の情報を正確に維持する。特定の型についてカタログが更新された場合、その型に対する方策は、要求に対してもはや有効でなく、方策キャッシュ・コンポーネントは、その型に関連する全ての情報を破棄する。クエリ・オプティマイザが、或る要求に対し或る方策を再使用する必要がある場合、該オプティマイザは、その方策を再算出し、その情報を方策キャッシュに再付与し、該キャッシュはそれをリポジトリ中に格納することになる。方策キャッシュは、データベース・トリガ（ＴＲＩＧＧＥＲ）からリポジトリ中の一切の変化の報告を受け、このトリガは、何らかの変化が生じたとき処置するため、リレーショナル・データベースが備えるメカニズムである。方策キャッシュによって、ＣａｔａｌｏｇＣｈａｎｇｅ（）（カタログ変更）（４１０）が受信され、これにより該キャッシュは、リポジトリから当該全情報を破棄し、クエリ・オプティマイザは、方策を再算出して、格納のためにそれを方策キャッシュ・コンポーネントに提供する必要がある。
【００４８】
このリポジトリは、情報のペアを含み、これは、特定の要求を認識するために使われ、どのソート方策を適用するかを決めるため算出される合致の結果を認識するために使われる情報である。例として、要求の一切の署名が正当であること、検査結果に対して一切の変数が有効であることなどがある。
【００４９】
図５は、本発明の第二実施形態による方法のフローチャートを示す。図３の第一フローチャートに比べると、この第二実施形態に対応する随意的なステップ（３４０、３４２、３４５）が加えられている。図３に示されたフローによって算出されるソート方策は、随意的に、永続リポジトリ（４２０）に保存することができる。このリポジトリが使われる場合、ソートが必要な時、指定された（列挙型，ユーザ言語）ペアに対するソート方策が見付かるどうか、まずリポジトリがチェックされ（検査３４０）、見付かった場合（検査３４０に対する「Ｙｅｓ」回答）、フローの残りの部分（すなわち、ステップ３０５を含めこのステップから始まる全てのステップ）は実行されない。
【００５０】
また、リポジトリが使われる場合、アプリケーションの起動時にこれにポピュレートすることが可能である。そうする場合、アプリケーションの開始時に、該アプリケーションは、アプリケーションがサポートする必要のある全てのあり得る（列挙型，ユーザ言語）ペアを生成し、それらの各々に対する適切なソート方策を生成し、それをリポジトリに保存する。
【００５１】
また、リポジトリが使われる場合、さらに動的な仕方でこれにポピュレートすることが可能である。そうする場合、アプリケーションは、ソート節（１１０）を有するクエリが発行されるまで待ち、その時点でリポジトリが存在し機能しているかどうかをチェックし、そして：
−  リポジトリが存在する場合、アプリケーションはそれを使ってソート方策を読出して返し；
−  リポジトリが存在しない場合、アプリケーションはそれを生成し、指定された（列挙型，ユーザ言語）ペアに対するエントリだけを算出して、リポジトリに加える。
【００５２】
また、アプリケーションは、カタログの変更に対するモニタを行うことを決めることができる。カタログが変更された場合、アプリケーションは、ソート方策リポジトリをクリアして、次回にそれが使われるときは白紙から開始することを確実にする。これは、例えば、カタログ・テーブル上にデータベース・トリガ（４１０）を使って実装することができる。
【００５３】
なお、上記説明および諸例はいくつかの特定のオブジェクトを取り扱っているが、本発明はローカライズ可能な値のセットから成る全ての種類の型に適用される。列挙型は、ユーザに直接表示できるものでなく「ストリングへの変換」ステップを必要とし、この「ストリングへの変換」ステップが、（値，ストリング）のペアを包含するテーブルをルック・アップすることによって実装される、任意のデータ型に一般化することができよう。
【００５４】
記載した最適化法は、最初に、どの程度の頻度でこの最適化法を適用することが可能かということが問われよう。この回答は、列挙値、列挙リストの長さ、およびカタログ言語に多くを依存する。分散型コンピューティング環境において、ジョブ・スケジューリングを実施するアプリケーションについて、いくつかの西洋言語に対して収集された統計は、全事例の３５％が最適化可能であることを示している。これはアプリケーションの如何によっても変わり得る。また、説明した最適化法は、該最適化法の使用からどのくらいの利得が得られるかということも問われよう。これは、主として、テーブルのサイズに依存し、論文に見られる典型的な値に基づけば、コスト高なＪＯＩＮオペレーションの節減は、パフォーマンスを１０倍（すなわち、１０００％）以上向上することが可能であるが、実際的応用で見られる多くの要素に大きく影響されよう。
【００５５】
リポジトリの使用は、同じ列挙リストに対し同じ要求が受信されたとき、最良の方策を決めるための検査の再実施を回避させてくれる。
【図１】
0006369841.tif 000002
【図２】
0006369841.tif 000003
【図３】
0006369841.tif 000004
【図４】
0006369841.tif 000005
【図５】
0006369841.tif 000006