JP2816430B2 - Set fetch processing method - Google Patents
Set fetch processing methodInfo
- Publication number
- JP2816430B2 JP2816430B2 JP61102032A JP10203286A JP2816430B2 JP 2816430 B2 JP2816430 B2 JP 2816430B2 JP 61102032 A JP61102032 A JP 61102032A JP 10203286 A JP10203286 A JP 10203286A JP 2816430 B2 JP2816430 B2 JP 2816430B2
- Authority
- JP
- Japan
- Prior art keywords
- search
- user program
- records
- database
- dbms
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の詳細な説明】
〔産業上の利用分野〕
本発明は、データベース検索時のユーザプログラムと
データベース管理システム（以降、DBMSと略す）との間
のインタフエースに関するものである。
〔従来の技術〕
従来、データベースの検索においては、ユーザプログ
ラムからの一回の検索要求コールに対して一個のレコー
ドしか返していなかつた。これは、検索時、条件を満足
する結果のレコード数が不定であること、また、検索し
たレコードに対する操作（変更，削除）を可能とするこ
と等の理由による。
しかし、このインタフエースでは、検索するレコード
数が決まつていて、かつ検索のみを目的とした検索要求
であつたとしても一回一回コールしなければならない。
一回コールするたびに、ユーザプログラムとDBMSとの間
で制御の受け渡しが発生する。このオーバヘツドは、検
索レコード数が増えるのに比例して増大する。
近年になつて、表形式のデータ構造を有するリレーシ
ヨナルDBMSが出て来たが、リレーシヨナルDBMSの特徴の
一つに集合操作がある。端末ユーザは、エンドユーザイ
ンタフエース機能を介してデータベースに対する検索，
更新を一括して行うことができる。
〔発明が解決しようとする問題点〕
しかしながら、上述の従来技術ではプログラム・イン
タフエースにおいては従来通りのインタフエース（１レ
コード/1コール）であり、インタフエースの統一がとれ
ていない。
本発明の目的は、プログラムからのデータベース検索
要求時、転送のための制御の移行のオーバヘツドを削減
することを目的としてなされたものである。
〔問題点を解決するための手段〕
上記の目的のために、本発明においてはデータベース
中に一個以上のフイールドからなるレコード群を格納す
る機能と、当該データベースより指定した条件のレコー
ドを検索する機能とを有するデータベース管理システム
において、ユーザプログラムからのレコードの検索要求
時、一回のコールで複数個のレコードの検索を行い、そ
の検索結果のレコード群をまとめてユーザプログラム側
へ転送する。
〔作用〕
本発明によれば、ユーザプログラム側からDBMSをコー
ルする回数が減少し、ユーザプログラム側とDBMSとの間
の制御移行のための処理時間を削減し、データベース検
索に要する総所要時間を減少させることができる。
〔発明の実施例〕
以下図面を用いて本発明を詳細に説明する。
第１図は、本発明の一実施例の構成図である。ユーザ
プログラム６が、検索のためにDBMSに対してコールを発
行すると、インタフエースモジユール５を介してDBMS側
に制御が渡る。DBMS側では、最初にDBMS制御部１が制御
を受け取る。DBMS制御部１は、先ずコール解析部３を呼
び、コールパラメタの解析を行う。検索要求の場合に
は、データベースアクセス処理部４を呼び出す。データ
ベースアクセス処理部４は、検索条件を満足するレコー
ドを検索する。その後、データ転送処理部２が、OSの共
通領域12（CSA:コモン サービス エリア,Common Serv
ice Area）を利用して、ユーザプログラム側の受け取り
エリア13にデータを転送する。ユーザプログラム６は、
検索データに対する加工，編集，出力等の処理を行つた
後、検索が終了でなけでば、再度DBMSをコールする。検
索が終了するまで、上記の処理が繰り返される。
集合フエツチ機能を実現するためには、ユーザプログ
ラム側で複数レコード分の受け取りエリアを用意し、受
け取り可能なレコード数をDBMSに知らせる必要がある。
第２図に、リレーシヨナルDBMSにおけるユーザプログ
ラムの例を示す。このプログラム20では、従業員テーブ
ル（EMP）から、部署番号（DNO）が10の部署に所属する
従業員の従業員名（ENAME）を検索している。プログラ
ム中のデータベース操作コマンド（先頭がEXEC SQLで始
まつている分）は、「ワーキング ドラフト アメリカ
ン ナシヨナル スタンダード データベース ランゲ
ージ エス キユーエル（working draft American Nat
ional Standard Database Language SQL）」（Dec.1984
ISO/TC97/SC21/WG5−15）に準じている。DECLARE CUR
SOR（デクレア カーソル）コマンド21は、カーソルを
宣言しているコマンドであり、検索文（SELECT（セレク
ト）節以降）とカーソル名を対応付けている。OPEN（オ
ープン）コマンド22は、カーソルを検索結果となるレコ
ード群の先頭レコードの前にカーソルを位置付け、FETC
H（フエツチ）コマンド23は、カーソルを一個進めた後
にデータを取り出し、CLOSE（クローズ）コマンド24
は、検索を終了することを示すコマンドである。
リレーシヨナルDBMSでは、このようにデータベース操
作言語を直接プログラム中に記述させ、プリプロセツサ
30を介してコール文に展開させるものが多い。40は、プ
リプロセツサによりコール文に展開された後のプログラ
ムである。プリプロセス時に、検索文を解析し、システ
ムに登録するため、カーソル宣言に対応するコール文は
生成されない。
第３図に集合フエツチ機能を利用した検索プログラム
の例を示す。集合フエツチの場合、OPENコマンド22のカ
ーソル名の後の括弧内で受け取りレコード数を指定す
る。FETCHコマンド23では、INTO（インツー）節で受け
取りエリアを指定し、カーソル名の後の括弧内に検索し
たレコード数受け取り用の変数名を指定する。40は、プ
リプロセス後のコール文展開例である。
次にDBMS側の処理方式を第１図を用いて示す。
DBMS側では、制御を受け取るとコール解析部３でコー
ルパラメタの解析を行う。（１）オープンコールの場合
には、指定された検索レコード数分のエリア（転送用バ
ツフアエリア）11を確保する。（２）フエツチコールの
場合には、データベースアクセス処理部４を呼び出す。
データベースアクセス処理部４は、検索条件を満足する
レコードを検索し、ユーザプログラムに必要なデータを
指定してレコード数分、転送用バツフア11に溜め込む。
その後、データ転送処理部２が、CSA領域12を介して、
ユーザプログラム側の受け取りエリア13にデータを転送
する。（３）クローズコールの場合には、転送用バツフ
アエリア11を解放する。
他の実施例として、ユーザプログラム側の受け取りエ
リアの確保及び、検索レコード数の通知を、インタフエ
ースモジユール５で行う方式が考えられる。この場合、
ユーザプログラム20のユーザインタフエースは従来通り
でも良い。
インタフエースモジユール５は、ユーザプログラムか
らオープンコールが来た時に、複数レコード分の受け取
りエリアを確保する。その後、コールパラメタに受け取
りレコード数を追加し、DBMSをコールする。なお、受け
取りエリア確保のためにはレコード長とレコード数が必
要である。レコード長を知る方法としては、（１）プリ
プロセス時にプリプロセツサがオープンコールのパラメ
タとしてレコード長を付加する。（２）一旦DBMSをコー
ルし、対応する検索対象レコードのレコード長を返して
もらう、といつたものがある。確保するレコード数は、
（１）DBMS空間とユーザプログラム空間との間のデータ
転送用に確保した領域（CSA領域）に入り切る分とか、
（２）仕様として設定した任意の個数分、にする。
フエツチコールを受け取つた時には、最初のフエツチ
コール、あるいは受け取りエリア中のレコードを全てユ
ーザプログラムに渡してしまつている場合には、DBMS本
体をコールして、受け取りエリアの先頭レコードをユー
ザプログラムに渡す。それ以外のフエツチコールの場合
には、受け取りエリア中の次レコードを渡す。
なお、以上の実施例では、空間間での直接のデータ転
送が不可能な場合を示したため、CSA領域を利用してい
る。OSによつては、空間間で直接データを転送できるも
のもあり、その場合には指定レコード数分のデータを、
直接、受け取りエリアに転送すれば良い。
〔発明の効果〕
以上述べたように本発明によれば、ユーザプログラム
からのデータベース検索時に、一回のコールで複数のレ
コード分のデータをユーザプログラム側に転送している
ため、ユーザプログラム側からDBMSをコールする回数が
減少し、ユーザプログラム側とDBMSとの間の制御移行の
ための処理時間を削減でき、データベース検索に要する
総所要時間を減少させることができる。Description: TECHNICAL FIELD The present invention relates to an interface between a user program and a database management system (hereinafter abbreviated as DBMS) at the time of database search. [Related Art] Conventionally, in a database search, only one record has been returned in response to one search request call from a user program. This is because, at the time of retrieval, the number of records as a result satisfying the condition is not fixed, and it is possible to operate (change, delete) the retrieved record. However, in this interface, the number of records to be searched is fixed, and even if the search request is only for searching, it must be called once.
Each time a call is made, control is transferred between the user program and the DBMS. This overhead increases in proportion to the number of search records. In recent years, a relational DBMS having a tabular data structure has appeared, and one of the features of the relational DBMS is a set operation. The terminal user can search the database via the end user interface function,
Updates can be performed collectively. [Problems to be Solved by the Invention] However, in the above-mentioned conventional technology, the program interface is the same as the conventional interface (one record / call), and the interface is not unified. An object of the present invention is to reduce the overhead of transferring control for transfer when a database search request is made from a program. [Means for Solving the Problems] For the above purpose, in the present invention, a function of storing a record group consisting of one or more fields in a database and a function of searching a record of a specified condition from the database In the database management system having the above structure, when a record search request is made from the user program, a plurality of records are searched by a single call, and the records of the search results are collectively transferred to the user program. [Operation] According to the present invention, the number of times the user program calls the DBMS is reduced, the processing time for control transfer between the user program and the DBMS is reduced, and the total time required for database search is reduced. Can be reduced. Embodiments of the Invention Hereinafter, the present invention will be described in detail with reference to the drawings. FIG. 1 is a configuration diagram of one embodiment of the present invention. When the user program 6 issues a call to the DBMS for search, control passes to the DBMS via the interface module 5. On the DBMS side, the DBMS control unit 1 first receives control. The DBMS control unit 1 first calls the call analysis unit 3 and analyzes the call parameters. In the case of a search request, the database access processing unit 4 is called. The database access processing unit 4 searches for a record that satisfies the search condition. Thereafter, the data transfer processing unit 2 executes the OS common area 12 (CSA: Common Service Area, Common Service Area).
Using the ice area), data is transferred to the receiving area 13 on the user program side. The user program 6
After processing such as processing, editing, and outputting the search data, if the search is not completed, the DBMS is called again. The above processing is repeated until the search ends. In order to realize the collective fetch function, it is necessary to prepare a receiving area for a plurality of records on the user program side and to notify the DBMS of the number of records that can be received. FIG. 2 shows an example of a user program in the relational DBMS. In the program 20, an employee name (ENAME) of an employee belonging to a department having a department number (DNO) of 10 is searched from the employee table (EMP). The database operation commands in the program (beginning with EXEC SQL) are described in the Working Draft American National Standard Database Language
ional Standard Database Language SQL) "(Dec. 1984)
It conforms to ISO / TC97 / SC21 / WG5-15). DECLARE CUR
The SOR (Declare Cursor) command 21 is a command that declares a cursor, and associates a search statement (after the SELECT clause) with a cursor name. The OPEN command 22 positions the cursor before the first record in the group of records to be searched,
The H (fetch) command 23 retrieves data after moving the cursor forward by one, and the CLOSE (close) command 24
Is a command to end the search. In the relational DBMS, the database operation language is directly described in the program as described above, and the preprocessor is used.
There are many things to expand into call statements through 30. Reference numeral 40 denotes a program after being expanded into a call statement by the preprocessor. During preprocessing, the search statement is analyzed and registered in the system, so no call statement corresponding to the cursor declaration is generated. FIG. 3 shows an example of a search program using the set fetch function. In the case of a set fetch, the number of records to be received is specified in parentheses after the cursor name of the OPEN command 22. In the FETCH command 23, the receiving area is specified in the INTO (into) clause, and the variable name for receiving the number of records searched is specified in parentheses after the cursor name. Reference numeral 40 denotes an example of call statement expansion after preprocessing. Next, a processing method on the DBMS side will be described with reference to FIG. On the DBMS side, upon receiving the control, the call analysis unit 3 analyzes the call parameters. (1) In the case of an open call, an area (transfer buffer area) 11 for the specified number of search records is secured. (2) In the case of a fetch call, the database access processing unit 4 is called.
The database access processing unit 4 searches for records satisfying the search conditions, specifies data necessary for the user program, and stores the data in the transfer buffer 11 for the number of records.
After that, the data transfer processing unit 2
The data is transferred to the receiving area 13 on the user program side. (3) In the case of a closed call, the transfer buffer area 11 is released. As another embodiment, a method in which the receiving module on the user program side is secured and the number of search records is notified by the interface module 5 can be considered. in this case,
The user interface of the user program 20 may be conventional. The interface module 5 secures a receiving area for a plurality of records when an open call comes from a user program. After that, add the number of received records to the call parameters and call the DBMS. Note that a record length and the number of records are required to secure the receiving area. The method of knowing the record length is as follows: (1) The preprocessor adds the record length as a parameter of the open call during preprocessing. (2) There is a method in which a DBMS is called once and the record length of a corresponding search target record is returned. The number of records to be secured is
(1) To be able to fit in the area (CSA area) reserved for data transfer between the DBMS space and the user program space,
(2) Arbitrary number set as specifications. When a fetch call is received, the first fetch call or, if all records in the receiving area have been passed to the user program, the DBMS itself is called and the first record of the receiving area is passed to the user program. For other foot calls, the next record in the receiving area is passed. In the above embodiment, the case where direct data transfer between spaces is impossible is shown, and therefore the CSA area is used. Some operating systems can directly transfer data between spaces, in which case the data for the specified number of records is
What is necessary is just to transfer to a receiving area directly. [Effects of the Invention] As described above, according to the present invention, at the time of database search from the user program, data of a plurality of records is transferred to the user program side by one call, so that the user program side The number of times the DBMS is called can be reduced, the processing time for control transfer between the user program side and the DBMS can be reduced, and the total time required for database search can be reduced.
【図面の簡単な説明】
第１図は本発明の一実施例の構成図、第２図はリレーシ
ヨナルDBMSを使用する、従来の１コール１レコード検索
を行うユーザプログラムの例、第３図は集合フエツチ機
能を使用したユーザプログラムの例を示す概要図であ
る。
１……DBMS制御部、２……データ転送処理部、３……コ
ール解析部、４……データベースアクセス処理部、６…
…ユーザプログラム、５……６と連結したインタフエー
スモジユール、７……ユーザプログラム側のデータ転送
処理部、10……データベース、11……転送用バツフアエ
リア、12……OSのCSA領域、13……ユーザプログラム側
のデータ受け取りエリア、30……データベース操作コマ
ンドをデータベースコール文に展開するプリプロセツ
サ、20……プリプロセス前のユーザプログラム、40……
プリプロセス後のユーザプログラム、21〜24……プログ
ラムからのデータベース検索用のデータベース操作コマ
ンド。BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of one embodiment of the present invention, FIG. 2 is an example of a conventional user program for performing one-call one-record search using a relational DBMS, and FIG. FIG. 4 is a schematic diagram illustrating an example of a user program using a fetch function. 1 ... DBMS control unit, 2 ... Data transfer processing unit, 3 ... Call analysis unit, 4 ... Database access processing unit, 6 ...
... the interface module connected to the user program, 5 ... 6, 7 ... the data transfer processing section on the user program side, 10 ... the database, 11 ... the transfer buffer area, 12 ... the OS CSA area, 13 ... ... Data receiving area on user program side, 30 ... Preprocessor that expands database operation commands into database call statements, 20 ... User program before preprocessing, 40 ...
User program after pre-processing, 21 to 24 ... Database operation commands for database search from the program.
フロントページの続き (72)発明者 中村 史朗 川崎市麻生区王禅寺1099番地 株式会社 日立製作所システム開発研究所内 (72)発明者 武藤 英男 川崎市麻生区王禅寺1099番地 株式会社 日立製作所システム開発研究所内 (72)発明者 福嶋 慎一 横浜市戸塚区戸塚町5030番地 株式会社 日立製作所ソフトウエア工場内 (56)参考文献 特開 昭59−3570（ＪＰ，Ａ) 特開 昭58−223865（ＪＰ，Ａ) 特開 昭59−32027（ＪＰ，Ａ)Continuation of front page (72) Inventor Shiro Nakamura 1099 Ozenji, Aso-ku, Kawasaki Hitachi Systems Development Laboratory (72) Inventor Hideo Muto 1099 Ozenji, Aso-ku, Kawasaki Hitachi Systems Development Laboratory (72) Inventor Shinichi Fukushima 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi Co., Ltd. Hitachi Software Factory (56) References JP-A-59-3570 (JP, A) JP-A-58-223865 (JP, A) JP-A-59-32027 (JP, A)
Claims (1)
該データベースに対するユーザプログラムからの検索要
求に応答して、前記データベースを検索する検索手段を
有するDBMSを備えたデータベースシステムにおいて、 前記DBMSは、前記ユーザプログラムからの検索レコード
数を指定した検索要求を前記検索手段に転送すると共に
前記検索レコード数分の転送用バッファエリアを確保
し、前記検索手段は前記検索レコード数の指定に基づき
複数のデータレコードの検索を一括して行ない、検索結
果を前記転送用バッファエリアに格納し、該転送用バッ
ファエリアに格納された検索結果である複数のデータレ
コードを一括して前記ユーザプログラムに転送すること
を特徴とする集合フェッチ処理方式。(57) [Claims] A database that holds multiple data records,
In a database system comprising a DBMS having a search means for searching the database in response to a search request from the user program for the database, the DBMS sends a search request specifying the number of search records from the user program. At the same time as transferring to the search means, a transfer buffer area for the number of search records is secured, and the search means performs a search of a plurality of data records at once based on the designation of the number of search records, and stores the search result in the transfer A set fetch processing method, wherein a plurality of data records as search results stored in the buffer area for transfer are collectively transferred to the user program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP61102032A JP2816430B2 (en) | 1986-05-06 | 1986-05-06 | Set fetch processing method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP61102032A JP2816430B2 (en) | 1986-05-06 | 1986-05-06 | Set fetch processing method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPS62259135A JPS62259135A (en) | 1987-11-11 |
| JP2816430B2 true JP2816430B2 (en) | 1998-10-27 |
Family
ID=14316417
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP61102032A Expired - Fee Related JP2816430B2 (en) | 1986-05-06 | 1986-05-06 | Set fetch processing method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2816430B2 (en) |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS593570A (en) * | 1982-06-29 | 1984-01-10 | Fujitsu Ltd | Data transfer controlling system |
-
1986
- 1986-05-06 JP JP61102032A patent/JP2816430B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPS62259135A (en) | 1987-11-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2760794B2 (en) | Database processing method and apparatus | |
| US6694312B2 (en) | Database processing method and apparatus for processing data by analyzing query input | |
| US5835904A (en) | System and method for implementing database cursors in a client/server environment | |
| JP3742177B2 (en) | Parallel database system routine execution method | |
| US5640555A (en) | Performance optimization in a heterogeneous, distributed database environment | |
| US5842196A (en) | Database system with improved methods for updating records | |
| US6105017A (en) | Method and apparatus for deferring large object retrievals from a remote database in a heterogeneous database system | |
| US5668987A (en) | Database system with subquery optimizer | |
| US5903893A (en) | Method and apparatus for optimizing a merge-join operation across heterogeneous databases | |
| EP0747839A1 (en) | Database management system with improved indexed accessing | |
| EP1107135A2 (en) | Parallel optimized triggers in parallel processing database systems | |
| US6343286B1 (en) | Efficient technique to defer large object access with intermediate results | |
| JP2003099441A (en) | Data retrieving procedure searching method | |
| US7174553B1 (en) | Increasing parallelism of function evaluation in a database | |
| US6999967B1 (en) | Semantically reducing the number of partitions involved in a join | |
| JP2816430B2 (en) | Set fetch processing method | |
| Luo | Partial materialized views | |
| US6487551B2 (en) | Externalizing very large objects in a relational database client/server environment | |
| JP2624170B2 (en) | Logical deletion data physical deletion method | |
| JPH09305622A (en) | Method and system for managing data base having document retrieval function | |
| JPH05334363A (en) | Data base retrieval system | |
| JPH0456344B2 (en) | ||
| JPH04340163A (en) | Keyword retrieval system | |
| CA2322603C (en) | Optimizing updatable scrollable cursors in database systems | |
| JPH0749880A (en) | Data base access request device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |