JP2001184353A - データベース情報のスクロール - Google Patents

Abstract

(57)【要約】 【課題】 データベース情報のスクロールを提供する。 【解決手段】 特にクライアント−サーバ・コンピュー
ティング・システムにおいて、データベース・レコード
をスクロールするための方法及び装置が開示されてい
る。データベース（１０４）は、レコードを保有してお
り、それぞれが固有の識別子を保持したサーバ（１０
２）によりアクセス可能とされている。クライアント
（１００）は、サーバ（１０２）に対してデータベース
・レコードの検索を要求する。レコードは、データベー
ス（１０４）から検索され、サーバ（１０２）に記憶さ
れる。サーバ（１０２）は、これらのレコードのサブセ
ットについてのレコード端部に対応した上側コンテクス
ト・トークンと、下側コンテクスト・トークンとを決定
する。上側コンテクスト・トークンと、下側コンテクス
ト・トークンとは、それぞれ固有の識別子を含んでい
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベースを用
いるコンピューティング・システムに関する。本発明
は、特にデータベース情報における結果セットのスクロ
ールに関するものである。

【０００２】

【従来の技術】現代における大型コンピューティングシ
ステムにおいては、共通技術として、（ｉ）ユーザによ
り操作が行われる多数のワークステーションによって特
徴づけられる表示階層、（ｉｉ）アプリケーション／ビ
ジネス論理を実行する多数のサーバによって特徴づけら
れるビジネス階層、（ｉｉｉ）データ記憶と連携化とに
基づいて作業を行う、多数のデータベースによって特徴
づけられるデータ階層といった、３つの階層を有してい
る。ローカル又はワイドエリア・ネットワーク（LAN/WA
N）は、上述した３つの階層要素を互いに連携させてい
る。

【０００３】上述したコンピューティング・システム
は、多種多様な分野において用途が見出されており、大
学における研究及び教育設備から、ビジネス用途にまで
わたるものである。実際的に、ほとんどすべてのビジネ
スは、上述したシステムを用いてビジネスの機能を処理
し、そのクライアントにサービスを行っている。例え
ば、システムは、ワードプロセッサ、支払い目的、及び
クライアントの問い合わせのための目録を制御するため
に用いることができる。多くのビジネスは、きわめて膨
大なクライアントをベースとして有しており、商品及び
サービスについて広範な目録を提供することになる。そ
の一例としては、全国的なクライアントをベースとして
サービスを提供するテレコミニュケーション・サービス
・プロバイダ（Telco）を挙げることができる。Telcoの
加入者は、したがって数百万の数となることもあり、各
顧客は、課金情報、新規サービスへの要求、製品に対す
る注文といった多岐にわたるいかなる問い合わせに対し
ても、顧客サービス部門(Customer Service Representa
tive:CSR)の迅速な対応を期待する。

【０００４】同様の例としては、公益設備、保険会社、
銀行、病院、法律事務所、会計事務所、ストック取引
社、大学、及び政府機関を挙げることができるが、これ
らに限られるわけではない。

【０００５】CSRワークステーションは、データベース
サーバへと接続するネットワークを有する外部ユーザと
なりうる。例えば顧客は、インターネットを介してベン
ダーのウエッブ・サーバへと接続するウエッブ・ブラウ
ザを用いて、ベンダーのデータベースに記憶された情報
へとアクセスすることができる。

【０００６】ほとんどすべてのコンピュータ・アプリケ
ーションにおいては、ユーザが膨大なデータのリストの
サブセット、例えばTelcoにおけるCSRでは、顧客への課
金情報の表示を閲覧するといった多くの場合がある。こ
れらの場合には、スクロールするためのある種の形式を
用いることが必要となろう。コンピュータの用語におい
ては、スクロールとは、スクリーン上でテキストを右か
ら左へと、又は上から下へと移動させて単一のディスプ
レイ表示内に収まりきらないテキストを表示させるため
の能力をいう。

【０００７】スクロール・バーが設けられたグラフィカ
ル・ユーザ・インタフェイス(GUI)ウインドウにおける
膨大なリストのサブセットを見ることになるユーザにつ
いて考えると、ホスト・アプリケーションは、最初(Fir
st)、最後(Last)、次(Next)、その前(Previous)、検索
(Search)といった要求に対応できることが必要とされ
る。‘First’では、GUIウインドウがリストの第１のサ
ブセットの上に配置される。‘Last’では、リストのう
ちの最後のサブセットが表示される。GUIウインドウが
リストのサブセットを表示させている場合には、‘Nex
t’では、次のサブセットを表示させ、‘Previous’で
は、その前のサブセットを表示させる。‘Search’要求
は、ユーザに対してリスト内の特定のデータを見出す能
力を与える。

【０００８】クライアント−サーバ・システムにおいて
は、ユーザ（クライアント）に対して膨大になりうるリ
ストにわたりスクロールを行わせつつ、サーバ・マシン
においてはこの膨大になりうるリストを記憶させること
に伴い、多くの問題が生じる。例えば、 １．サーバ・マシンは、多くのクライアントについての
結果セットを保有しながらリソースの外で実行を行わな
ければならないこと、 ２．サーバ・マシンは、クライアントが終了したことを
認識しなければならないこと、 ３．クライアント・マシンがクラッシュして、ある種の
‘パイピング’がクラッシュを解決するために試みられ
ている場合には、サーバをクライアントにアクセスさせ
る（例えば、クライアント・マシーンが“ファイアウオ
ール”の後ろにあるか？、またタイムアウトが用いられ
ている場合にはこのタイムアウトがどう設定されている
か？、タイムアウト期間の間にスクロールさせたことに
より膨大なリストを得ることになるクエリーを開始した
ことで、サーバがダウンするか？）（また、通常ではネ
ットワークの信頼性を失わせてしまうので、クライアン
トとサーバとの間のWANを介した（ソケット）接続を維
持させたままで、これを解消することは許容されるもの
ではない）ということ、 ４．多くのより大きなシステム、及びインターネット・
ウエッブ・サーバに基づいたアプリケーションにおいて
は特に、アプリケーションのサーバ側には、クライアン
ト情報が処理の間に保持できないようにする方法が組み
込まれ、より大きなスループットを可能とし、リソース
の過剰な使用を禁止するので、これらのシステムにおい
てはデータは、スクロール要求の間には保持することが
できないこと、を挙げることができる。

【０００９】また、クライアントへリストを通信させ、
クライアントに記憶させることに伴う問題も存在する。
例えば、以下のような問題がある。 １．リストが膨大となることもあり、そのような場合そ
の通信は許容できないほどに遅くなるか、又は不可能と
なってしまう。インターネットに基づいた用途では、し
ばしばクライアントは、モデムを使用する。典型的なモ
デムの速度は、１秒あたりデータが数キロバイト程度で
ある。このリストは、容易にメガバイト、又は数１０メ
ガバイト程度となることがあるので、役に立たない程に
通信を遅くさせることになる。サーバに対して信頼性の
ある高速な接続を行っているクライアントもあるが、そ
れ以外は、信頼性が低いか、又は低速で接続している。 ２．リストのいかなる部分でも表示できるようにするた
め、ユーザはリスト全体を取得し、その通信を待つこと
が必要となる。ユーザが思い通りの結果を取得できるよ
うにうまく検索を行えた場合には、データの第１のウイ
ンドウが最も重要である場合が多く、リストの残りに対
するアクセスは必要ではあろうが、第１のウインドウよ
りも少ない頻度でアクセスされるのが一般的である。 ３．リストのためにクライアント・マシン上に記憶容量
が確保されていなければならないことである。

【００１０】特に知られているスクロール構成として
は、日本国特許出願番号第０６−３１４３０６号（Hita
chi Ltd, Tkashi及びMichiko）、名称：データベース・
ディスプレイ方法を挙げることができる。この文献にお
いては、検索された結果セットを受取り、ローカル・フ
ァイル中に結果セットを記憶し、その後ローカル・ファ
イルから抽出を行って、データの一部を表示させるワー
クステーションが開示されている。この方法は、上述し
たようにクライアントに対してリストを通信することに
伴うすべての問題を有するものである。

【００１１】

【発明が解決しようとする課題】本発明の目的は、従来
技術に伴う問題を生じさせずにデータベースの結果セッ
トをスクロールすることを可能にすることを目的とす
る。

【００１２】

【課題を解決するための手段】本発明は、データベース
・レコードをスクロールするための方法であって、
（ａ）各データベース・レコードに固有の識別子をアロ
ケートするステップと（ｂ）前記レコードのサブセット
の複数のレコード端部に対応し、少なくとも前記各レコ
ードに対する前記識別子を含む上側コンテクスト・トー
クンと、下側コンテクスト・トークンとを決定するステ
ップと、（ｃ）スクロール要求に応答して前記レコード
の隣接したサブセットにアクセスすめために前記上側コ
ンテクスト・トークン又は前記下側コンテクスト・トー
クンを用いるステップとを含むものである。

【００１３】本発明はさらに、データベースがレコード
を保有し、かつそれぞれが固有の識別子を含むサーバに
よりアクセスされるクライアント−サーバシステムにお
けるデータベース・レコードのスクロール方法であっ
て、該方法は、（ａ）前記データベース・レコードのセ
ットを検索するステップと、（ｂ）前記サーバにより前
記レコードのサブセットに対する複数のレコード端部に
対応し、かつそれぞれの前記レコードに対する識別子を
少なくとも含む上側コンテクスト・トークンと下側コン
テクスト・トークンとを決定するステップと、（ｃ）前
記クライアントからスクロール要求がある場合には、検
索された前記レコードの隣接するサブセットにアクセス
するために前記サーバが連携する上側コンテクスト・ト
ークン又は下側コンテクスト・トークンのいずれかを用
いるステップと、（ｄ）前記レコードの前記隣接するサ
ブセットに対する新たな上側コンテクスト・トークンと
下側コンテクスト・トークンとを決定するステップと、
（ｅ）前記クライアントに新たなコンテクスト・トーク
ンと共に前記サブセットを送信するステップとを含むも
のである。

【００１４】スクロール要求は、下側コンテクスト・ト
ークンから開始する次のサブセット、又は上側コンテク
スト・トークンから開始する前のサブセットを含むこと
ができる。スクロール要求は、さらに固有の識別子の参
照部を含む属性を有する検索ストリングにおける付加的
なステートメントを含むことができる。サーチ順序情報
ステートメントを、さらにスクロール要求の検索ストリ
ング中に含ませることができ、このステートメントは、
上側コンテクスト・トークン又は下側コンテクスト・ト
ークンから構成され、かつ参照部を含んでいる。

【００１５】本発明は、さらにまた、データベース・レ
コードをスクロールするクライアント−サーバ・コンピ
ューティング・システムであって、該システムは、
（ａ）データのスクロールを可能とするアプリケーショ
ン・プログラムを実行する１つ以上のクライアント・コ
ンピュータと、（ｂ）クライアント・アプリケーション
・プログラムを実行する前記クライアントと通信リンク
によって接続されるサーバ・コンピュータと、（ｃ）前
記サーバによりアクセス可能とされ、固有の識別子を含
むそれぞれのレコードを記憶するデータベースとを含
み、前記クライアントは、前記サーバに対し、前記デー
タベースの検索の後に上側コンテクスト・トークン及び
下側コンテクスト・トークンを含む前記レコードのセッ
トの要求を前記サーバに送信可能であり、前記サーバ
は、検索された前記レコードのサブセットのレコード両
端部を特定し、前記レコードについての識別子を少なく
とも含む上側コンテクスト・トークンと下側コンテクス
ト・トークンとを決定し、前記上側コンテクスト・トー
クン又は下側コンテクスト・トークンを用いて前記レコ
ード両端部のいずれかに隣接したサブセットを規定す
る。

【００１６】前記サーバは、前記データベース・レコー
ドの前記セットを記憶するためのメモリを含み、前記ク
ライアントからのスクロール要求は、前記上側コンテク
スト・トークン又は前記下側コンテクスト・トークンを
含み、記憶された前記セットからそれぞれ次のサブセッ
トを検索するため用いられる。

【００１７】

【発明の実施の形態】代表的なクライアント−サーバ・
プラットホーム 図１は、本発明が適用され３つの階層を含むコンピュー
ティング・システム１０の構成を示した図である。表示
（すなわちクライアント／ユーザ）階層は、数字
（１．．．ｎ）のクライアント・ワークステーション２
０により示されている。このクライアント・ワークステ
ーションは、適切なコンピューティング端末、例えばパ
ーソナルコンピュータとすることができる。ビジネス・
階層は、数字（１．．．ｐ）のサーバ３０により示され
ており、このサーバは、専用のミニコンピュータ又はメ
インフレームとすることができる。データ・階層は、数
字（１．．．ｍ）のデータベース４０により示されてお
り、このデータベースは、動的に管理され磁気的又は光
学的な記録媒体を含んでいても良い。

【００１８】コンピューティング・システム１０は、
‘オープン’設計とされていて、外部ネットワーク７
０，７２，７４を介して同様のデバイス２２，３２，４
２への通信リンクと、リモートテレフォン端末２４，２
６とを提供している。

【００１９】ワークステーション２０と、サーバ３０
と、データベース４０とは、ローカル又はワイドエリア
・ネットワーク（LAN又はWAN）５０により互いに接続さ
れている。LAN/WAN５０は、上述した３つの基本要素そ
れぞれの間を通して情報を伝送している。図１に示す構
成は、例示するためのみのものであり、ネットワークに
ついては、ワークステーション２０と、サーバ３０と、
データベース４０とを通して情報通信するという目的が
達成される限り、用いることができるいかなる別の形態
であっても良い。

【００２０】本発明の態様は、上述した従来の技術の欄
において説明した分野において工業的用途を有してい
る。限定することは意図しないが、ここでは、合衆国の
多くの州にわたって操作が行われるTelcoの例について
説明する。このようなTelcoは、典型的にはセルラー自
動車電話の音声及びデータ交信の他にも、地域、地方、
州間、国際間の音声及びデータ・コールをサポートす
る。Telcoの顧客は、例えば２番目の電話／ＦＡＸ／イ
ンターネット・ラインの取付け、呼出し回送、及び伝言
といった広い範囲の商品及びサービスから選択を行うこ
とができる。

【００２１】顧客はまた、課金及びサービス障害に関連
してワークステーション２０をステーションとしたCSRs
についての問い合わせを行うことが可能とされているこ
とを希望する。このことは、今日のTelcoが少なくとも
１００万人の顧客を有し、典型的には少なくとも５００
のCSRsを必要とするので、理由がないことではない。上
述した規模のTelcoシステムのインフラ構造は、１時間
あたり約１５，０００のビジネス処理を取扱うことが予
測される。各ビジネス処理について、６のCSR機械処理
が必要とされ、個々の機械それぞれの処理は、２０デー
タベースにも上る処理（すなわち、I/Os）を含むもので
ある。

【００２２】上述の特性を得るために必要とされるコン
ピューティング・ハードウエアの規模についてより良い
例を挙げると、CSRワークステーション２０を、ウイン
ドウズＮＴ（商標）オペレーティング・システムを実行
するペンティアム（商標）を有するパーソナルコンピュ
ータとし、サーバ３０を１台以上のIBM UNIX（商標）ベ
ースの１２−ウエイRS-6000（商標）S-70マシンとし、
データベースは、約40Gbytesの容量を必要とすると共
に、オラクル(Oracle)（商標）又はIBM DB-2（商標）シ
ステムにより管理されるものを挙げることができる。当
然ながら、データ通信を処理することができ、操作され
る別のLAN/WANサーバについては、当業者によれば容易
に理解することができよう。

【００２３】一般化されたクライアント−サーバアーキ
テクチャにおけるスクロール図２は、クライアント−サ
ーバシステムのための一般化されたコンピューティング
・アーキテクチャを示す。クライアント・プロセス１０
０は、図１に示されていると同様、ワークステーション
２０とすることができ、サーバ・プロセス１０２は、ま
た図１に示したサーバ・マシン３０のどの１つとするこ
ともできる。同様にして、データベース１０４は、図１
に示すデータ記憶部４０のうちの１つを示している。し
かしながら、均等範囲においては、クライアント・プロ
セス１００と、サーバ・プロセス１０２とを、単一のマ
シン上に存在させることも可能である（例えば、単一の
サーバマシン３０）。

【００２４】クライアント・マシン１０２上において
は、グラフィカル・ユーザ・インタフェイス（GUI）・
レイヤ１１０が、ユーザのためのマン−マシン・インタ
フェイスを提供している。GUIレイヤは、クライアント
−サーバ・システムにより実行される特定のコンピュー
ティング操作又は目的が実行されるアプリケーション・
レイヤ１１２をインタフェイスしている。アプリケーシ
ョン・レイヤは、ミドルウエア・レイヤ１１４とインタ
フェイスされており、このミドルウエア・レイヤ１１４
は、システムリソース使用、オペレーティング・システ
ム・ロック、メモリ・アクセス・シェア、コンテナ・サ
ービス、キュー・サービス、処理サービス、作業連携に
おける論理ユニット、プロセス間通信、ユーザ・アクセ
ス制御サービス、コンフィギュレーション・リトリーバ
ル・サービスといった動作を処理する。ミドルウエア・
レイヤ１１４は、オペレーティング・システム及び通信
サービスを表している。オブジェクト指向環境において
は、オブジェクトは、サービス要求に応答するミドルウ
エアにより例示することができる。クライアント・マシ
ン１００のトランスポート・レイヤ１１６は、サーバ１
０２とネットワーク通信されており、通常ではオブジェ
クトを表したバイナリ・ストリングを通信する。サーバ
・プロセス１０２は、トランスポート・レイヤ１１６，
１１６’の機能と、ミドルウエア・レイヤ１１４，１１
４’の機能と、アプリケーション・レイヤ１１２，１１
２’の機能に応答する。

【００２５】ミドルウエア・レイヤ１１４，１１４’
は、例えばインターナショナル・ビジネス・マシーンズ
・コーポレイションの製品であるCICS-TM, ENCINA-TM,
CBConnector-TMとすることができる。

【００２６】それぞれのアプリケーション・レイヤ１１
２，１１２’は、UNIX-TMオペレーティング・システム
により構成することができる。サーバ・アプリケーショ
ン・レイヤ１１２，１１２’については、付加的なデー
タベース・プロセスが存在し、このデータベース・プロ
セスは、インターナショナル・ビジネス・マシーンズ・
コーポレイションの製品であるDB2-TMといった所望のリ
レーショナル・データベースとすることができる。デー
タベース１０４は、SQLコール・コマンドを介してアク
セスされる。

【００２７】それぞれのアプリケーション・レイヤ１１
２，１１２’は、共に操作されるスクロール・エンジン
１２０，１２０’を含んでいる。スクロール・エンジン
は、高い水準のプログラミング言語で記述することがで
き、このプログラミング言語については、本願の教示に
従い当業者によれば明らかであろう。

【００２８】スクロール操作典型的なデータベース応答
においては、CSR照会は、データベースがサーバへと数
百〜数千ラインの結果セットを戻す結果となるが、GUI
１１０においては、一度に２０〜５０ラインが表示され
るにすぎない。完全な結果セットは、サーバ１０２に存
在し、要求された部分のみがスクロール要求にしたがっ
てクライアント１００へと送られることになる。

【００２９】クライアントは、サーバへとクエリー(que
ly)を発して、きわめて大きなデータ量である可能性の
あるデータ・リストの関心のある最初のサブセットを検
索する。サーバは、データベースに対してクエリーを発
して、クライアントへと上側“コンテクスト・トーク
ン”及び下側“コンテクスト・トークン”と共に、要求
されたデータのサブセットを送信する。“コンテクスト
・トークン”とは、クライアントが連続して“Next”
（又は“Previous”）スクロール要求を発する場合に、
データの次（又はそれ以前の）サブセットをリターンす
るようにさせて、サーバ・データベースにおける位置を
変更するに充分な情報を含むデータ・ピースをいう。

【００３０】ユーザが表示されたデータのサブセットを
超えてスクロール・ダウンする場合には、Next要求がク
ライアントからサーバへと下側コンテクスト・トークン
と共に送られる。サーバでは、このコンテクスト・トー
クンは、データベースが元のサブセットではなくデータ
の次のサブセットを戻すように元のデータベース・クエ
リーを変更させる。このサーバは、新たに決定された上
側コンテクスト・トークン及び下側コンテクスト・トー
クンと共にサブセットをクライアントへと送信する。同
様にして、ユーザが表示されているデータ・サブセット
を越えて上側にスクロールを行う場合には、Previousが
元のサブセットではなく、データの次のサブセットをリ
ターンさせる。サーバは、新たに決定された上側コンテ
クスト・トークン及び下側コンテクスト・トークンと共
に、このサブセットをクライアントへと通信する。

【００３１】重要なことは、データの全リストがクライ
アントへと通信されず、クライアントに関連する情報
が、要求の間サーバに保持されることはないことにあ
る。

【００３２】クライアント上でコンテクストを決定し、
記憶することによりサーバは、スクロールを行うそれぞ
れのクライアントに対応したいかなる別のプロセスやコ
ンテクスト・リソースも保有することを要求されない。
このようにして、クライアント・セッションを、スクロ
ール・プロセスにおいて停止させることができ、かつ不
確定にサーバを待機させずに済むことになる。

【００３３】リレーショナル・データベースの場合に
は、コンテクストは、結果セットを発生させるSQLクエ
リーのためのクエリー・タームの一部となる。従来の一
般的なクエリーを下記に示す。 SELECT A, B, C FROM <your-table> WHERE <your-predicates> ORDER BY B, C

【００３４】本発明においては、このステートメント
は、下記のように変更される。 SELECT A, B, C, D, OID FROM <your-table> WHERE <your-predicates> AND B > :b OR (B= :b AND (C > :c OR (C = :c AND OI
D > :oid))) ORDER BY B, C, OID

【００３５】このデータベースは、各列（すなわちエン
トリ）に対して固有の値を有するようにして配置されて
いるので、２重になるデータ値を区別することが可能と
なる。この例の場合の区別部は、“OID”（object id:
オブジェクトｉｄ）である。この実施例では、クライア
ント・ユーザは、行Ｂ及びＣにより記憶されることにな
る、このクエリーを要求する。ORDER BY節のフィールド
が、コンテクスト・トークンである。OIDは、常にORDER
BYにおける最後のフィールドとされていて、リターン
される各列が確実に固有となるようにさせている。アプ
リケーションにより要求されるORDER BYが存在しない場
合には、ORDER BY OIDは、デフォルトとしてクエリーに
加えられる。

【００３６】第１のデータベース要求については、列
１．．．ｘ（ｘは、フェッチの数である）に対して：b,
:c, :dについての好適な値は、第１の列がリターンさ
れるように与えられる。コンテクスト・トークンは、そ
の後列ｘについてB, C及びOIDの値とされることにな
る。（付随的にNULLsは、他の値の前にNULLを配置して
いる通常のSQLデータベースの昇順サーチでは、First
と、Lastと、Searchと、Reverse Searchクエリーに対す
るコンテクスト・トークン値として適切である）。これ
に続くデータの‘Next’セットは、直前の要求の最後の
ラインから:b, :c, :oidの値のコンテクスト・トークン
を渡す。このようにすることにより、要求された位置
（この場合には列ｘ＋１）でカーソルが再度表示される
こととなる。

【００３７】すべてのORDER BY行（すなわちコンテクス
ト・トークン）は、常にクエリーのAND節における属性
において出現する。しかしながら、AND節の属性におけ
る行は、‘ORDER BY’の一部を形成する必要はないこと
に留意されたい。また、‘ORDER BY’行は、各列につい
てクライアントへとリターンされる必要があり、このた
めSELECT節内に配置される。非表示のデータのソートを
行うことはまれなので、通常ではリターンされる余分の
データは、OIDのみとされる。

【００３８】コンテクスト・トークンは、異なるスクロ
ール・クエリー（すなわち、ORDERBY と、コンテクス
ト・トークンWHERE属性と、SELECTing コンテクスト・
トークン）を形成するように変更される。例えば、‘Ne
xt’は、“より大きい”サイン（すなわち、（）及び昇
順ソーティング）を必要とするが、‘Previous’は、
“より小さい”サイン、（すなわち、（）及び降順ソー
ティング）を必要とするため、例えば、‘Previous’と
は反対に‘Next’クエリーには異なった形態が存在す
る。

【００３９】‘Serach’クエリーは、付加的にWHEREサ
ーチ基準を含み、‘First’クエリーと等価である。双
方ともSELECTステートメントに含まれるコンテクスト・
トークンを含むことが必要とされ、かつ双方ともORDER
BYフィールドを必要とする。‘Next’クエリーは、コン
テクスト・トークンWHEREが加えられており、上述した
２つと同様に等価である。同様に、‘Last’クエリー
は、各フィールドについてDESCendingのORDER BY及びコ
ンテクスト・トークンSELECTedを含むように変更された
元のクエリーと等価である。‘Previous’クエリーは、
コンテクスト・トークンWHERE基準が付加され、‘Las
t’クエリーと同一であり、“より大きい”サインを用
いる代わりに“より小さい”サインを用いている。さら
に、リバース・サーチは、‘Last’クエリーにサーチ基
準を加えることによって含ませることができる。

【００４０】リレーショナル・データベースではないシ
ステムにおいても、スクロールは、コンテクストが結果
セットにおいてプライマリ・キーとなるように提供され
ていれば、依然として可能である。実際に、これは、デ
ータベースを操作する通常の方法である。

【００４１】具体的な実施例 本発明の態様によるフローダイアグラムを示す図３を参
照して、スクロールの具体的な実施例を説明する。

【００４２】スタート・ステップ１００に続いて、ステ
ップ１０２においてクライアントは、表示される検索さ
れた結果セットの第１の部分を要求する。第１の要求
は、下記の形とされる。 Constant query conditions :name >= Smith, age >= 0 Context :name = Smith, age = 0, oid = 0 Mode :next Size :30

【００４３】‘constant query conditions’は、全結
果セットを特定する。‘size’は、サーバによる第１の
要求に対するそれぞれの処理についてリターンされる結
果セットのサイズを特定する。‘context’は、その上
側にあるエントリを参照するか、又は第１のエントリで
ある。すなわち、上述した‘context’は、結果セット
が下記の場合に正確なものである。 Name Age oid Smith 40 276 Smith 50 34 Smith 60 345 Smith 70 44 Smith 80 233 Smith 100 800

【００４４】ステップ１０４において、サーバは、クラ
イアントからの要求を受取る。ステップ１０６では、サ
ーバは、要求された‘mode’が‘Next’か、又は‘Prev
ious’のいずれであるかを確認する。ステップ１０８で
は、サーバは、データの‘Next’部分について、データ
ベースに対してクエリーを発する。SQL構造の場合に
は、この要求は下記の形とされる。 SELECT Name, Age, Oid FROM Table WHERE name >= Smith AND age >= 0 AND name > Smyth OR (name = Smyth AND age > 100 OR
(age = 100 AND Oid >800)) ORDER BY Name, Age, Oid

【００４５】ステップ１１０においては、サーバは、結
果セットの‘Previous’部分に対する要求を発する。上
述したと同一のデータについて上述したように、要求は
以下のようになる。 SELECT Name, Age, Oid FROM Table WHERE name >= Smith AND age >= 0 AND name ( Smith OR ( name = Smith AND age (40) OR
(age = 40 AND Oid (276)) ORDER BY Name DESC, Age DESC, Oid DESC

【００４６】この結果セットは、データベースによりソ
ートされていたとは逆に検索される。このようにして、
結果セットは、上側コンテクスト・トークンの上部から
開始して、リストを通して後方へと進行して行く。

【００４７】ステップ１１２は、データベースのアクセ
スを示している。データベースが用いることができるコ
ンテクストの上側又は下側に結果セットを戻すことがで
きる場合には、スクロールに用いることが可能となる。
後述するようにして、リレーショナル・データベースで
あることは、必要とされるものではないことが示され
る。ステップ１１４において、結果セットについて要求
された部分（‘Next’又は‘Previous’クエリーのいず
れかのモード）は、クライアントへとリターンされる。
ステップ１１６においては、クライアントは、その時点
で表示されたデータの要求された一部を保有している。
ステップ１１８では、クライアントは、データの新たな
スクリーンについてのスクロール・コマンドを発する。
このコマンドは、その時点でのコンテクストに比較して
上又は下の移動を行うためのものである。

【００４８】ステップ１２０においては、ユーザは、ス
クリーンの底部に最も近いオブジェクトを選択し、クラ
イアントは、サーバへとNextクエリーを含む下側コンテ
クスト・トークンを送信する。下記のスクリーンにおけ
るディスプレイについて考察する。 Name Age Oid Smyth 17 247 Smyth 17 455 Smyth 18 23 Smyth 20 234 Smyth 30 400

【００４９】これは、下記の下側コンテクスト・トーク
ンを有することになる。 Name = Smyth, Age = 30, and Oid = 400 かくして、‘Next’ページを要求するクエリーは、下記
のようになる。 SELECT Name, Age, Oid FROM Table WHERE name >= Smith AND age >= 0 AND name > Smith OR (name = Smyth AND age > 30 OR
(age = 30 AND Oid > 400)) ORDER BY Name, Age, Oid

【００５０】上述したように、第１の２つの節は、同一
のまま残されている、すなわち、 WHERE name >= Smith AND age >= 0 である。第３の節は、コンテクストを補強するものであ
る。

【００５１】ステップ１２２ではユーザは、スクリーン
の上部に最も近いレコードを選択し、クライアント・ア
プリケーションは、上側コンテクスト・トークン及び
‘Previous’クエリーを送信する。スクリーンにおける
ディスプレイは、下記の形となる。 Name Age Oid Smyth 17 234 Smyth 17 455 Smyth 18 23 Smyth 20 234 Smyth 30 400 このコンテクストは、下記のようになる。 Name = Smyth, Age = 17 and Oid = 234

【００５２】この場合には、前のページを要求するクエ
リーは、 SELECT Name, Age, Oid FROM Table WHERE name >= Smith AND age >= 0 AND name ( Smyth OR (name = Smyth AND age < 17 OR
(age = 17 AND Oid < 234)) ORDER BY Name DESC, Age DESC, Oid DESC となる。

【００５３】再度、第１の２つの節は同一のまま残され
ていることに留意されたい。すなわち、 WHERE name >= Smith AND age >= 0 である。第３の節は、コンテクストを補強する。

【００５４】別の実施例 別の実施例について説明する。ニュージーランドに住ん
でいるTelcoの完全な顧客リストをリターンする元々の
クエリーは、 SELECT firstName, surname, age, country FROM custo
mers WHERE country =‘New Zealand’ORDER BY surna
me, age である。

【００５５】１．‘Next’クエリー Nextクエリーは、下記のようになる。 SELECT firstName, surname, age, country, oid FROM customers WHERE country = ‘New Zealand’ AND surname > :surname OR (surname = :surname AND
(age > :age OR (age =:age AND OID > :oid))) ORDER BY surname, age, oid

【００５６】この文法においては、<surname, age, oid
>がコンテクスト・トークンである。このコンテクスト
・トークンは、ORDER BYにおけるフィールドとして形成
される。コンテクスト・トークン<:surname, :age, :oi
d>は、データの最後に検索されたラインの一部である。
WHERE節は、所定のコンテクスト・トークンの後の‘Nex
t’レコードが、surnameがコンテクスト・トークンにお
けるsurnameよりも大きい場合のものであるか、又は同
一であれば、ORDER BY（すなわちage）における次のフ
ィールドを閲覧する必要があるかを示すものである。こ
のようにして、‘Next’レコードは、同一のsurnameを
含むようにされ、かつコンテクスト・トークン内におけ
るageよりも大きなageを含むことになる。しかしなが
ら、またageが同一の場合には、その後‘Next’レコー
ドは、surnameが同一で、ageが同一で、Oidが、コンテ
クスト・トークン内のものよりも大きなものとされるこ
とになる。Oidは固有なので、‘Next’レコードを得る
ことが常に可能となる。

【００５７】２．‘First’クエリー Firstクエリーは、下記の形となる。 SELECT firstname, surname, age, country, oid FROM Customers WHERE country = ‘New Zealand’ ORDER BY surname, age, oid

【００５８】ここで、コンテクスト・トークン<Null, N
ull, Null>と共に、‘Next’クエリーを用いることも可
能である。

【００５９】３．Searchクエリー ユーザが、ニュージーランドにおける顧客のリストにわ
たって、支払いを行わなかった顧客へとリストを狭めよ
うと希望する場合には、サーチ基準を、単にFirst（又
は、<Null, Null, Null>を含むNext）データへと加える
ことにより行われる。また、サーチ・フォワード要求
（その時点での位置から前方へのサーチ）は、その時点
でのコンテクスト・トークンと共に、Nextクエリーに対
してサーチ基準を加えることにより可能とされる。サー
チ・クエリーは、 SELECT firstname, surname, age, country, oid FROM Customers WHERE country = ‘New Zealand’ AND surname > :surname OR (surname = :surname AND
(age > :age OR (age =:age AND oid > :oid))) AND accountOverdrawn = true ORDER BY surname, age, oid となる。

【００６０】この点からは、（又はサーチがキャンセル
されるまでは）すべてのNextクエリー及びPreviousクエ
リーは、それらのWHERE条件に加えられる付加的なサー
チ基準“AND accountOverdrawn = true”を含んでい
る。

【００６１】４．‘Previous’クエリー Previousクエリーは、下記のようになる。 SELECT firstname, surname, age, country, oid FROM Customers WHERE country = ‘New Zealand’ AND surname < :surname OR (surname = :surname AND (age < :age OR (age = :age AND oid < :oid))) ORDER BY surname DESC, age DESC, oid DESC ‘DESC’は、各フィールドに含まれることに留意された
い。

【００６２】５．‘Last’クエリー Lastクエリーは、下記のようになる。 SELECT firstName, surname, age, country, oid FROM Customers WHERE country = ‘New Zealand’ ORDER BY surname DESC, age DESC, oid DESC

【００６３】適 用 本発明によるコンテクスト・トークン技術は、スクロー
ル・クエリーを発生するための標準的なデータベース・
クエリーを変更することが必要となる。

【００６４】実施例において用いるOIDは、データ内の
各レコードについて固有の識別子である。これは、ORDE
R BY内のデータがすでにプライマリ・キーとされていな
い場合にのみ、必要とされる。この場合には、又はプラ
イマリ・キーがテーブルにおけるある別のフィールドを
用いて形成される場合には、その後にOIDは必要とされ
ない。また、多くのデータベースは、固有の識別子を与
えることに留意されたい。例えば、オラクルは、上述し
た実施例におけるOIDと等価なROWIDフィールドを有して
いる。

【００６５】データベース・インデックスは、ORDER BY
節におけるフィールドの少なくとも一部をカバーするこ
とが必要とされる。これは、データが記憶されている膨
大なテーブルから、バックデータを選択する効果的な方
法である。

【００６６】クライアントにキャッシュを導入するよう
に選択して、ユーザ・ウインドウよりも大きなデータの
サブセットを保持させておくようにすることも可能であ
る。これは、ネットワーク帯域幅、アプリケーション要
求、データベース効率、全システム能力、クライアント
容量に応じたスクロールの‘チューニング’を可能とす
る。キャッシュは、公知のアルゴリズムを用いて導入す
ることができる。

【００６７】例えば、ユーザは、インターネットを介し
て銀行のウエッブ・サーバへと低帯域幅のモデムにより
接続することができる。このようなインターネットに基
づいたアプリケーションは、クライアントのアプリケー
ションのその時点でのセッションのための情報を、サー
バ上に保持する試みはしない。ユーザは、最近の銀行決
済の詳細のリストを閲覧することを希望する場合があ
る。ユーザは、時系列とは逆に記憶されているリストに
ついて問い合わせるが、統計的には該ユーザは、最後の
数百の詳細のみについて遡って閲覧する傾向にあること
が知られている。このリストは、数千の詳細にわたる長
さを有している。したがって、アプリケーションは、一
度に５０の詳細情報を検索するようにサーバに要求する
ことを動的に決定する。これは、低速のネットワークに
対して充分に早く応答することを可能とすると共に、ユ
ーザに対して第１のスクリーン、すなわち２５の詳細情
報を充分迅速に表示することを可能とする。クライアン
ト・マシン上の実際のキャッシュは、１００の詳細情報
を保持することも可能な場合もあるが、これについては
利用可能なメモリにより制限を受ける。ユーザが‘ペー
ジダウンを’押す場合には、キャッシュからデータの第
２のスクリーンが直ちに利用可能とされる。これに続く
‘ページダウン’では、クライアント・マシンが銀行の
サーバに対し、さらなる５０の詳細情報を要求する。リ
ターン場合には、ユーザは、２５のレコードからなる第
３のスクリーンを閲覧することができる。ユーザが‘ペ
ージアップ’を押す場合には、前のセットがキャッシュ
内に依然として保持されているので、直ちに表示するこ
とができることになる。

【００６８】本発明は、上述した実施例に限定されるも
のではなく、本発明の趣旨の範囲内における数多くの別
の実施例及び変更例は、当業者によれば明らかであるこ
とは理解されるものである。

【００６９】本発明の実施例を添付の図面を参照して説
明するが、これらの実施例は本発明を制限するものでは
ない。

【図面の簡単な説明】

【図１】本発明を適用する３つの階層を含むコンピュー
ティング・システムの例示的構成を示した図。

【図２】クライアント−サーバ・アーキテクチャを示す
簡略化した図。

【図３】本発明を実施するためのフローチャート。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ステファン・トーマス・グラハム ニュージーランド国、オークランド、ホウ ィック、コックルベイ、ロビーズロード 55 (72)発明者 ジェィムス・レオナルド・ダンウッディ ニュージーランド国、ウェリントン、マウ ンガラキ、アカシアアヴェニュー 37Ｂ Ｆターム(参考） 5B075 KK07 KK13 KK33 KK37 ND03 ND26 ND36 PP30 PQ02 PQ32 PQ46 PQ66 5B082 EA07 GC03 GC04 GC05 HA08 5E501 AC23 AC33 BA05 DA02 FA13 FB32

Claims (12)

【特許請求の範囲】
1. 【請求項１】 データベース・レコードをスクロールす
   るための方法であって、（ａ）各データベース・レコー
   ドに固有の識別子をアロケートするステップと、（ｂ）
   前記レコードのサブセットの複数のレコード端部に対応
   し、少なくとも前記各レコードに対する前記識別子を含
   む上側コンテクスト・トークンと、下側コンテクスト・
   トークンとを決定するステップと、（ｃ）スクロール要
   求に応答して前記レコードの隣接したサブセットにアク
   セスするために前記上側コンテクスト・トークン又は前
   記下側コンテクスト・トークンを用いるステップとを含
   むデータベース・レコードのスクロール方法。
2. 【請求項２】 さらに、前記ステップ（ｃ）の後に、
   （ｄ）前記レコードの前記隣接するサブセットに対して
   新たな上側コンテクスト・トークンと、新たな下側コン
   テクスト・トークンとを決定するステップを含む請求項
   １に記載のデータベース・レコードのスクロール方法。
3. 【請求項３】 前記ステップ（ｃ）における前記スクロ
   ール要求は、（ｉ）下側コンテクスト・トークンから開
   始する次のサブセット又は、（ｉｉ）上側コンテクスト
   ・トークンから開始する前のサブセットを含む請求項２
   に記載のデータベース・レコードのスクロール方法。
4. 【請求項４】 前記ステップ（ｂ）が開始する前に、さ
   らに（ｅ）前記データベース・レコードのセットを検索
   するステップと、（ｆ）該レコードの前記サブセットを
   表示するステップとを含む請求項３に記載のデータベー
   ス・レコードのスクロール方法。
5. 【請求項５】 前記ステップ（ｃ）は、（ｉ）前記スク
   ロール要求に応答して発生するスクロール要求サーチス
   トリング内に前記固有の識別子に対する参照部を有する
   付加的なステートメントを含ませるステップを含む請求
   項１に記載のデータベース・レコードのスクロール方
   法。
6. 【請求項６】（ｉｉ）前記スクロール要求サーチストリ
   ング内に、前記上側コンテクスト・トークン又は前記下
   側コンテクスト・トークンを含むサーチ順序情報ステー
   トメント及び前記参照部を含ませるステップを含む請求
   項５に記載のデータベース・レコードのスクロール方
   法。
7. 【請求項７】 データベースがレコードを保有し、かつ
   それぞれが固有の識別子を含むサーバによりアクセスさ
   れるクライアント−サーバシステムにおけるデータベー
   ス・レコードのスクロール方法であって、（ａ）前記デ
   ータベース・レコードのセットを検索するステップと、
   （ｂ）前記サーバにより前記レコードのサブセットに対
   する複数のレコード端部に対応し、かつそれぞれの前記
   レコードに対する識別子を少なくとも含む上側コンテク
   スト・トークンと下側コンテクスト・トークンとを決定
   するステップと、（ｃ）前記クライアントからスクロー
   ル要求がある場合には、検索された前記レコードの隣接
   するサブセットにアクセスするために、前記サーバが上
   側コンテクスト・トークン又は下側コンテクスト・トー
   クンのいずれかを用いるステップと、（ｄ）前記レコー
   ドの前記隣接するサブセットに対する新たな上側コンテ
   クスト・トークンと下側コンテクスト・トークンとを決
   定するステップと、（ｅ）前記クライアントに対して新
   たなコンテクスト・トークンと共に前記サブセットを送
   信するステップとを含むデータベース・レコードのスク
   ロール方法。
8. 【請求項８】 前記ステップ（ｃ）における前記スクロ
   ール要求は、（ｉ）前記下側コンテクスト・トークンか
   ら開始する次のサブセット又は、（ｉｉ）前記上側コン
   テクスト・トークンから開始する前のサブセットを含む
   請求項７に記載のデータベース・レコードのスクロール
   方法。
9. 【請求項９】 前記ステップ（ｃ）は、前記クライアン
   トにおいて実行され、（ｉ）前記スクロール要求に応答
   して発生するスクロール要求サーチストリング内に、前
   記固有の識別子に対する参照部を有する付加的なステー
   トメントを含ませるステップを含む請求項８に記載のデ
   ータベース・レコードのスクロール方法。
10. 【請求項１０】 （ｉｉ）前記スクロール要求サーチス
    トリング内に、前記上側コンテクスト・トークン又は前
    記下側コンテクスト・トークンを含むサーチ順序情報ス
    テートメント及び前記参照部を含ませるステップを含む
    請求項９に記載のデータベース・レコードのスクロール
    方法。
11. 【請求項１１】 データベース・レコードをスクロール
    するクライアント−サーバ・コンピューティング・シス
    テムであって、該システムは、（ａ）データのスクロー
    ルを可能とするアプリケーション・プログラムを実行す
    る１つ以上のクライアント・コンピュータと、（ｂ）ク
    ライアント・アプリケーション・プログラムを実行す
    る、前記クライアントと通信リンクによって接続される
    サーバ・コンピュータと、（ｃ）前記サーバによりアク
    セス可能とされ、固有の識別子を含むそれぞれのレコー
    ドを記憶するデータベースとを含み、 前記クライアントは、前記サーバに対し、前記データベ
    ースの検索後に上側コンテクスト・トークン及び下側コ
    ンテクスト・トークンとを含む前記レコードのセットの
    要求を前記サーバに送信可能であり、前記サーバは、検
    索された前記レコードのサブセットのレコード両端部を
    特定し、前記レコードについての識別子を少なくとも含
    む上側コンテクスト・トークンと下側コンテクスト・ト
    ークンとを決定し、前記上側コンテクスト・トークン又
    は前記下側コンテクスト・トークンを用いて前記レコー
    ド両端部のいずれかに隣接したサブセットにアクセスす
    るクライアント−サーバ・コンピューティング・システ
    ム。
12. 【請求項１２】 前記サーバは、前記データベース・レ
    コードの前記セットを記憶するためのメモリを含み、前
    記クライアントからのスクロール要求は、前記上側コン
    テクスト・トークン又は前記下側コンテクスト・トーク
    ンを含み、記憶された前記セットからそれぞれ次のサブ
    セットを検索するため用いられる請求項１１に記載のク
    ライアント−サーバ・コンピューティング・システム。