JPH1011464A - クライアント/サーバ型のデータベース・システム - Google Patents
クライアント/サーバ型のデータベース・システムInfo
- Publication number
- JPH1011464A JPH1011464A JP8167336A JP16733696A JPH1011464A JP H1011464 A JPH1011464 A JP H1011464A JP 8167336 A JP8167336 A JP 8167336A JP 16733696 A JP16733696 A JP 16733696A JP H1011464 A JPH1011464 A JP H1011464A
- Authority
- JP
- Japan
- Prior art keywords
- data
- server
- client
- dbms
- binary
- 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.)
- Pending
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】 ディスクへの書込み処理を最小限にしてデー
タベースの格納または更新を行い得るようにすること。 【解決手段】 リクエスタは、最初にSQL文をサーバ
処理部に送り、次に変数データをサーバ処理部に送る。
BLOBデータ(バイナリ型の長大データ)の追加また
は更新を示すSQL文を受け取ると、サーバ処理部は準
備実行要求をDBMSに対して発行する。準備実行要求
を受け取ると、DBMSはBLOBデータの格納位置を
決定する。サーバ処理部は、BLOBデータを受け取る
と、これををDBMSに渡す。DBMSは渡されたBL
OBデータを決定された格納位置に格納する。
タベースの格納または更新を行い得るようにすること。 【解決手段】 リクエスタは、最初にSQL文をサーバ
処理部に送り、次に変数データをサーバ処理部に送る。
BLOBデータ(バイナリ型の長大データ)の追加また
は更新を示すSQL文を受け取ると、サーバ処理部は準
備実行要求をDBMSに対して発行する。準備実行要求
を受け取ると、DBMSはBLOBデータの格納位置を
決定する。サーバ処理部は、BLOBデータを受け取る
と、これををDBMSに渡す。DBMSは渡されたBL
OBデータを決定された格納位置に格納する。
Description
【0001】
【発明の属する技術分野】本発明は、クライアント/サ
ーバ型のデータベース・システムにおいて、BLOB
(BINARY LARGE OBJECT :バイナリ型の長大データ)を
扱う場合の高速化手法に関するものである。
ーバ型のデータベース・システムにおいて、BLOB
(BINARY LARGE OBJECT :バイナリ型の長大データ)を
扱う場合の高速化手法に関するものである。
【0002】
【従来の技術】従来のホスト・システムでの更新処理に
おけるデータベース・システムとアプリケーションとの
変数データの受渡しは、メモリまたはディスクに格納し
たデータを一度に指定するものであった。しかし、クラ
イアント/サーバ・システムでは、更新データはクライ
アントに存在するため、BLOBのような巨大データを
一回で受け渡すと、大量の転送時間が必要となる。この
ような場合、従来のインタフェースでは、サーバ上のサ
ーバ処理部が全ての更新データを受け取った後でなけれ
ばDBMSを呼び出すことが出来ない。更に、DBMS
側では、受け取ったデータを格納するため、サーバ処理
部がディスクに格納したデータを再度転送して格納する
ことになり、結果的に二回のディスクへの格納処理が必
要になっていた。
おけるデータベース・システムとアプリケーションとの
変数データの受渡しは、メモリまたはディスクに格納し
たデータを一度に指定するものであった。しかし、クラ
イアント/サーバ・システムでは、更新データはクライ
アントに存在するため、BLOBのような巨大データを
一回で受け渡すと、大量の転送時間が必要となる。この
ような場合、従来のインタフェースでは、サーバ上のサ
ーバ処理部が全ての更新データを受け取った後でなけれ
ばDBMSを呼び出すことが出来ない。更に、DBMS
側では、受け取ったデータを格納するため、サーバ処理
部がディスクに格納したデータを再度転送して格納する
ことになり、結果的に二回のディスクへの格納処理が必
要になっていた。
【0003】
【発明が解決しようとする課題】本発明は、この点に鑑
みて創作されたものであって、ディスクへの書込み処理
を最小限にしてデータベースの格納または更新を行い得
るようになったクライアント/サーバ型のデータベース
・システムを提供することを目的としている。
みて創作されたものであって、ディスクへの書込み処理
を最小限にしてデータベースの格納または更新を行い得
るようになったクライアント/サーバ型のデータベース
・システムを提供することを目的としている。
【0004】
【課題を解決するための手段】請求項1のクライアント
/サーバ型のデータベース・システムは、クライアント
と、リレーショナル・データベースを有するサーバと、
サーバとクライアントを接続する回線とを有するクライ
アント/サーバ型のデータベース・システムであって、
サーバとクライアントの間で、SQL文の転送後に変数
データを転送するプロトコルが取り決められ、サーバ
は、バイナリ型の長大データの追加または更新を示すS
QL文を受け取ったときには、当該バイナリ型の長大デ
ータの格納位置を決定し、バイナリ型の長大データを受
け取ったときには、当該バイナリ型の長大データを上記
決定した格納位置に格納することを特徴とするものであ
る。
/サーバ型のデータベース・システムは、クライアント
と、リレーショナル・データベースを有するサーバと、
サーバとクライアントを接続する回線とを有するクライ
アント/サーバ型のデータベース・システムであって、
サーバとクライアントの間で、SQL文の転送後に変数
データを転送するプロトコルが取り決められ、サーバ
は、バイナリ型の長大データの追加または更新を示すS
QL文を受け取ったときには、当該バイナリ型の長大デ
ータの格納位置を決定し、バイナリ型の長大データを受
け取ったときには、当該バイナリ型の長大データを上記
決定した格納位置に格納することを特徴とするものであ
る。
【0005】請求項2のクライアント/サーバ型のデー
タベース・システムは、請求項1のクライアント/サー
バ型のデータベース・システムにおいて、サーバは、サ
ーバ処理部およびデータベース管理システムを有してお
り、サーバ処理部は、バイナリ型の長大データの追加ま
たは更新を示すSQL文を受け取った時には、データベ
ース管理システムに対して準備実行要求を発行し、デー
タベース管理システムは、準備実行要求が発行されたと
きには、上記バイナリ型の長大データの格納位置を決定
し、サーバ処理部は、バイナリ型の長大データを受け取
った時には、当該バイナリ型の長大データをデータベー
ス管理システムに渡し、データベース管理システムは、
渡されたバイナリ型の長大データを上記決定された格納
位置に格納することを特徴とするものである。
タベース・システムは、請求項1のクライアント/サー
バ型のデータベース・システムにおいて、サーバは、サ
ーバ処理部およびデータベース管理システムを有してお
り、サーバ処理部は、バイナリ型の長大データの追加ま
たは更新を示すSQL文を受け取った時には、データベ
ース管理システムに対して準備実行要求を発行し、デー
タベース管理システムは、準備実行要求が発行されたと
きには、上記バイナリ型の長大データの格納位置を決定
し、サーバ処理部は、バイナリ型の長大データを受け取
った時には、当該バイナリ型の長大データをデータベー
ス管理システムに渡し、データベース管理システムは、
渡されたバイナリ型の長大データを上記決定された格納
位置に格納することを特徴とするものである。
【0006】
【発明の実施の形態】図1は本発明のクライアント/サ
ーバ・システムの構成例を示すものである。同図におい
て、10はサーバ、11はDBMS(データベース管理
システム)、12はサーバ処理部、13はメモリ、14
はディスク、20はクライアント、21はリクエスタ、
23と24はメモリ、25はディスクを示している。
ーバ・システムの構成例を示すものである。同図におい
て、10はサーバ、11はDBMS(データベース管理
システム)、12はサーバ処理部、13はメモリ、14
はディスク、20はクライアント、21はリクエスタ、
23と24はメモリ、25はディスクを示している。
【0007】サーバ10は例えばDS/90と呼ばれる
計算機であり、クライアント20は例えば通常のパソコ
ンである。サーバ10とクライアント20は、回線で接
続されている。DBMS11やサーバ処理部12,リク
エスタ21は、プログラムで実現されている。なお、図
示しないが、一般にサーバには回線を介して複数のクラ
イアントが接続されている。
計算機であり、クライアント20は例えば通常のパソコ
ンである。サーバ10とクライアント20は、回線で接
続されている。DBMS11やサーバ処理部12,リク
エスタ21は、プログラムで実現されている。なお、図
示しないが、一般にサーバには回線を介して複数のクラ
イアントが接続されている。
【0008】サーバ10は、DBMS11やサーバ処理
部12,メモリ13,ディスク14を有している。DB
MS11は、データベースのアクセスを制御するもので
ある。サーバ処理部12は、クライアント側から送られ
てきたSQL文やデータをDBMS11に渡すための処
理を行う。メモリ13は、クライアント側からのデータ
を一時的に記憶するものである。ディスク14には、リ
レーショナル・データベースのデータが格納されてい
る。
部12,メモリ13,ディスク14を有している。DB
MS11は、データベースのアクセスを制御するもので
ある。サーバ処理部12は、クライアント側から送られ
てきたSQL文やデータをDBMS11に渡すための処
理を行う。メモリ13は、クライアント側からのデータ
を一時的に記憶するものである。ディスク14には、リ
レーショナル・データベースのデータが格納されてい
る。
【0009】クライアント20は、リクエスタ21やア
プリケーション22,メモリ23,メモリ24,ディス
ク25を有している。リクエスタ21は、アプリケーシ
ョンから処理要求やデータを受け取り、これら処理要求
やデータをサーバ側に送る。アプリケーション22は、
リクエスタ21に対して処理要求やデータを渡す。メモ
リ23はアプリケーション22に割り当てられており、
メモリ24はリクエスタ21に対して割り当てられてい
る。ディスク25の中には、各種のデータが格納されて
いる。
プリケーション22,メモリ23,メモリ24,ディス
ク25を有している。リクエスタ21は、アプリケーシ
ョンから処理要求やデータを受け取り、これら処理要求
やデータをサーバ側に送る。アプリケーション22は、
リクエスタ21に対して処理要求やデータを渡す。メモ
リ23はアプリケーション22に割り当てられており、
メモリ24はリクエスタ21に対して割り当てられてい
る。ディスク25の中には、各種のデータが格納されて
いる。
【0010】アプリケーション22とリクエスタ21と
の間のインタフェースは、例えばODBC(Open DataBa
se Connectivity:米国マイクロソフト社の商標)で定め
られているように、先ず処理要求を発行し、その後、必
要なデータを転送することが可能な方式であるものとす
る。
の間のインタフェースは、例えばODBC(Open DataBa
se Connectivity:米国マイクロソフト社の商標)で定め
られているように、先ず処理要求を発行し、その後、必
要なデータを転送することが可能な方式であるものとす
る。
【0011】リクエスタ21とサーバ処理部12との間
には、SQL文の転送後に変数データを転送すると言う
プロトコルが取り決められている。サーバ処理部12
は、SQL文を受け取ると、DBMS11に対してデー
タ格納位置の決定を要求し、次いでデータをDBMS1
1に渡す。データを複数回に分けて渡しても良い。
には、SQL文の転送後に変数データを転送すると言う
プロトコルが取り決められている。サーバ処理部12
は、SQL文を受け取ると、DBMS11に対してデー
タ格納位置の決定を要求し、次いでデータをDBMS1
1に渡す。データを複数回に分けて渡しても良い。
【0012】DBMS11が格納するデータは、論理的
には複数の欄から成る行の集まりとして管理される。行
はレコードと呼ばれる物理的な単位でまとめて格納され
る。ただし、BLOBデータについてはデータは別に格
納され、レコード中には位置(内部的な名前)のみが格
納される。DBMS11は、受け取ったBLOBデータ
を予め処理要求が正常終了した時に格納される場所に転
送する。ただし、この結果は、全てのデータが受け渡さ
れ、最後にレコードが追加または更新されるまで外から
は見えない。
には複数の欄から成る行の集まりとして管理される。行
はレコードと呼ばれる物理的な単位でまとめて格納され
る。ただし、BLOBデータについてはデータは別に格
納され、レコード中には位置(内部的な名前)のみが格
納される。DBMS11は、受け取ったBLOBデータ
を予め処理要求が正常終了した時に格納される場所に転
送する。ただし、この結果は、全てのデータが受け渡さ
れ、最後にレコードが追加または更新されるまで外から
は見えない。
【0013】図2はデータ格納処理シーケンスを説明す
るための図である。データ格納のためのSQL文は、例
えば INSERT INTO TABLE1 VALUES (:従業員番号,:顔写
真) と言うものである。顔写真はBLOBデータである。
るための図である。データ格納のためのSQL文は、例
えば INSERT INTO TABLE1 VALUES (:従業員番号,:顔写
真) と言うものである。顔写真はBLOBデータである。
【0014】クライアント側のアプリケーションは、最
初にSQL文を登録する。SQL文の登録は、具体的に
は例えばODBC APIではSQLPrepare関
数が対応する。リクエスタは、登録されたSQL文を記
憶し、後の実行に備える。登録されたSQL文は繰り返
して実行要求を行うことが出来る。
初にSQL文を登録する。SQL文の登録は、具体的に
は例えばODBC APIではSQLPrepare関
数が対応する。リクエスタは、登録されたSQL文を記
憶し、後の実行に備える。登録されたSQL文は繰り返
して実行要求を行うことが出来る。
【0015】アプリケーションは、SQL文の登録を行
った後、変数(上記の例では、従業員番号と顔写真)の
宣言を行う。変数の宣言は、具体的には例えばODBC
APIではSQLBindParameter関数が
対応する。この処理は、変数データの型と長さを通知す
る処理である。この長さをもとに、リクエスタは最終デ
ータを判定する。
った後、変数(上記の例では、従業員番号と顔写真)の
宣言を行う。変数の宣言は、具体的には例えばODBC
APIではSQLBindParameter関数が
対応する。この処理は、変数データの型と長さを通知す
る処理である。この長さをもとに、リクエスタは最終デ
ータを判定する。
【0016】アプリケーションは、変数の宣言を行った
後、SQL文の実行を指示する。これは、具体的には例
えばODBC APIではSQLExecute関数が
対応する。SQL文の実行が指示されると、リクエスタ
は、SQL文(変数データの宣言を含む)をサーバ側に
送ると共に、アプリケーションに対してデータを要求す
る。
後、SQL文の実行を指示する。これは、具体的には例
えばODBC APIではSQLExecute関数が
対応する。SQL文の実行が指示されると、リクエスタ
は、SQL文(変数データの宣言を含む)をサーバ側に
送ると共に、アプリケーションに対してデータを要求す
る。
【0017】サーバ処理部は、SQL文を受け取ると、
文内容を解析する。このSQL文は変数データとしてB
LOBデータを含んでいるので、データ処理部は、DB
MSに対して準備実行要求を発行する。DBMSは、準
備実行要求を受け取ると、サーバ処理部が受け取ったS
QL文を解析し、BLOBデータの格納位置を決定す
る。
文内容を解析する。このSQL文は変数データとしてB
LOBデータを含んでいるので、データ処理部は、DB
MSに対して準備実行要求を発行する。DBMSは、準
備実行要求を受け取ると、サーバ処理部が受け取ったS
QL文を解析し、BLOBデータの格納位置を決定す
る。
【0018】アプリケーションは、リクエスタからのデ
ータの要求を受け取ると、データの受渡しを行う。リク
エスタは、渡されたデータの総計が転送最大サイズに達
するまでアプリケーションに対してデータの要求を行
い、転送最大サイズに達したならば、渡された全データ
をサーバ側に転送する。転送データには、データの型や
何番目の変数データかを示す制御データが付加されてい
る。なお、転送最大サイズは32K〜128Kバイト程
度である。BLOBデータとして、画像,音声,,動
画,長大なテキスト等があり、大きさは特に定まってい
ないが、例えば画像データは数十Kバイト〜数Mバイト
程度の大きさを持つ。
ータの要求を受け取ると、データの受渡しを行う。リク
エスタは、渡されたデータの総計が転送最大サイズに達
するまでアプリケーションに対してデータの要求を行
い、転送最大サイズに達したならば、渡された全データ
をサーバ側に転送する。転送データには、データの型や
何番目の変数データかを示す制御データが付加されてい
る。なお、転送最大サイズは32K〜128Kバイト程
度である。BLOBデータとして、画像,音声,,動
画,長大なテキスト等があり、大きさは特に定まってい
ないが、例えば画像データは数十Kバイト〜数Mバイト
程度の大きさを持つ。
【0019】サーバ処理部は、クライアント側からの転
送データを受け取ると、その内のBLOBデータをDB
MSに受け渡し、受取りの完了をクライアントに対して
通知する。DBMSは、渡されたBLOBデータを予め
決定された格納位置に格納する。なお、BLOB以外の
データは、実処理実行要求で纏めて渡される。
送データを受け取ると、その内のBLOBデータをDB
MSに受け渡し、受取りの完了をクライアントに対して
通知する。DBMSは、渡されたBLOBデータを予め
決定された格納位置に格納する。なお、BLOB以外の
データは、実処理実行要求で纏めて渡される。
【0020】リクエスタは受取りの完了を受け取ると次
のデータをサーバ側に転送し、サーバ処理部は転送デー
タを受け取って転送データ中のBLOBデータをDBM
Sに受け渡し、受取り完了をクライアントに対して通知
する。このような処理は、繰り返し行われる。
のデータをサーバ側に転送し、サーバ処理部は転送デー
タを受け取って転送データ中のBLOBデータをDBM
Sに受け渡し、受取り完了をクライアントに対して通知
する。このような処理は、繰り返し行われる。
【0021】転送データが最後のものである場合には、
サーバ処理部は、その内のBLOBデータをDBMSに
受け渡し、その後で実処理実行要求をDBMSに対して
発行する。DBMSは、上述のように渡されたBLOB
データを予め決定された格納位置に格納する。
サーバ処理部は、その内のBLOBデータをDBMSに
受け渡し、その後で実処理実行要求をDBMSに対して
発行する。DBMSは、上述のように渡されたBLOB
データを予め決定された格納位置に格納する。
【0022】また、DBMSは、実処理実行要求を受け
取ると、再びSQL文を詳細に解析してSQL文で示さ
れた要求を実行する。BLOBデータを含まない場合に
は、この呼出し一回だけでSQL文の処理が実行され
る。この呼出し前にBLOBデータは格納されている
が、この処理が行われるまで、他の利用者はデータベー
スに登録されたBLOBデータを参照することはできな
い。
取ると、再びSQL文を詳細に解析してSQL文で示さ
れた要求を実行する。BLOBデータを含まない場合に
は、この呼出し一回だけでSQL文の処理が実行され
る。この呼出し前にBLOBデータは格納されている
が、この処理が行われるまで、他の利用者はデータベー
スに登録されたBLOBデータを参照することはできな
い。
【0023】上述のINSERTのSQL文の場合に
は、DBMSは、指示された値の従業員番号および格納
されたBLOBデータに付けられた内部的な名前を持つ
レコードを,TABLE1と呼ばれる表に追加する。実
処理実行要求を処理した後、DBMSは、完了通知を発
行する。この完了通知は、サーバ処理部およびリクエス
タを経由して、アプリケーションに送られる。
は、DBMSは、指示された値の従業員番号および格納
されたBLOBデータに付けられた内部的な名前を持つ
レコードを,TABLE1と呼ばれる表に追加する。実
処理実行要求を処理した後、DBMSは、完了通知を発
行する。この完了通知は、サーバ処理部およびリクエス
タを経由して、アプリケーションに送られる。
【0024】図3はBLOBデータを持つ表の例を示す
図である。図示の例では、各行(レコード)は、従業員
番号の欄と,顔写真の欄を有している。顔写真のデータ
型はBLOBである。顔写真に対して、「AA」,「B
B」,…,「XX」などの内部的な名前が付けられてい
る。各行の顔写真の欄には、内部的な名前が記入されて
いる。
図である。図示の例では、各行(レコード)は、従業員
番号の欄と,顔写真の欄を有している。顔写真のデータ
型はBLOBである。顔写真に対して、「AA」,「B
B」,…,「XX」などの内部的な名前が付けられてい
る。各行の顔写真の欄には、内部的な名前が記入されて
いる。
【0025】図4はBLOBデータの格納位置の決定を
説明する図である。TABLE1と呼ばれるディレクト
リは、TABLE1と呼ばれる表のBLOBデータを管
理するものである。このディレクトリは複数のエントリ
を有しており、各エントリはデータの型がBLOBであ
ること、BLOBデータに付けられた内部的な名前,物
理的な格納位置,データの大きさ等を示す管理情報を記
憶している。
説明する図である。TABLE1と呼ばれるディレクト
リは、TABLE1と呼ばれる表のBLOBデータを管
理するものである。このディレクトリは複数のエントリ
を有しており、各エントリはデータの型がBLOBであ
ること、BLOBデータに付けられた内部的な名前,物
理的な格納位置,データの大きさ等を示す管理情報を記
憶している。
【0026】図3における従業員番号が888で,顔写
真の名前がXXである行が,上述のSQL文によって追
加されたものとする。このような行が追加されるまでの
過程を説明すると、次のようになる。
真の名前がXXである行が,上述のSQL文によって追
加されたものとする。このような行が追加されるまでの
過程を説明すると、次のようになる。
【0027】 DBMSは、準備実行要求を受け取る
と、顔写真のBLOBデータを格納するための領域を確
保し、この格納領域にXXと言う名前を付与し、この格
納領域を特定するために必要な管理情報をTABLE1
と言うディレクトリの空きエントリに書き込む。 DBMSは、BLOBデータが受け渡される度に、
渡されたBLOBデータを格納領域XXに格納する。 DBMSは、実処理実行要求を受け取ると、従業員
番号の値が888で,顔写真の値がXXである行を表
(TABLE1という名前の)に追加する。
と、顔写真のBLOBデータを格納するための領域を確
保し、この格納領域にXXと言う名前を付与し、この格
納領域を特定するために必要な管理情報をTABLE1
と言うディレクトリの空きエントリに書き込む。 DBMSは、BLOBデータが受け渡される度に、
渡されたBLOBデータを格納領域XXに格納する。 DBMSは、実処理実行要求を受け取ると、従業員
番号の値が888で,顔写真の値がXXである行を表
(TABLE1という名前の)に追加する。
【0028】上述の説明は格納のSQL文に関するもの
であるが、例えば「TABLE1という表において、従
業員番号の値が001である行の顔写真を更新せよ」と
言う更新のSQL文の場合には、DBMSは下記のよう
な処理を行う。 受け取ったデータのために、新たに例えばYYとい
う名前の格納領域を生成する。 DBMSは、BLOBデータが受け渡される度に、
渡されたBLOBデータを格納領域YYに格納する。 DBMSは、実処理実行要求を受け取ると、レコー
ド中のAAをYYに変更し、格納領域AAを削除する。
また、BLOBデータ以外のデータの更新を行う。ただ
し、上述のような内容のSQL文の場合には、BLOB
データ以外のデータの更新は行われない。
であるが、例えば「TABLE1という表において、従
業員番号の値が001である行の顔写真を更新せよ」と
言う更新のSQL文の場合には、DBMSは下記のよう
な処理を行う。 受け取ったデータのために、新たに例えばYYとい
う名前の格納領域を生成する。 DBMSは、BLOBデータが受け渡される度に、
渡されたBLOBデータを格納領域YYに格納する。 DBMSは、実処理実行要求を受け取ると、レコー
ド中のAAをYYに変更し、格納領域AAを削除する。
また、BLOBデータ以外のデータの更新を行う。ただ
し、上述のような内容のSQL文の場合には、BLOB
データ以外のデータの更新は行われない。
【0029】
【発明の効果】図5は本発明の効果を示す図である。従
来処理においては、サーバ処理部は、クライアントとの
間のデータ転送と、転送されて来たデータを自己に割り
当てられたディスク領域に格納する処理とを行う。デー
タの転送が終了すると、サーバ処理部はDBMSを呼出
す。DBMSは、BLOBデータをサーバ処理部のディ
スク領域から読み出して予め定められた格納位置に書き
込むと共に、レコード処理を行う。
来処理においては、サーバ処理部は、クライアントとの
間のデータ転送と、転送されて来たデータを自己に割り
当てられたディスク領域に格納する処理とを行う。デー
タの転送が終了すると、サーバ処理部はDBMSを呼出
す。DBMSは、BLOBデータをサーバ処理部のディ
スク領域から読み出して予め定められた格納位置に書き
込むと共に、レコード処理を行う。
【0030】本発明の処理においては、サーバ処理部は
クライアントとの間のデータ転送と、転送されて来たB
LOBデータをDBMSに引き渡す処理を行う。DBM
Sは、BLOBデータを受け取り、これを予め定められ
た格納位置に書き込む。BLOBデータの書込みが終了
した後、DBMSはレコード処理を行う。
クライアントとの間のデータ転送と、転送されて来たB
LOBデータをDBMSに引き渡す処理を行う。DBM
Sは、BLOBデータを受け取り、これを予め定められ
た格納位置に書き込む。BLOBデータの書込みが終了
した後、DBMSはレコード処理を行う。
【0031】図5から判るように、本発明によれば、ク
ライアント側から転送されて来たBLOBデータを一時
的に保存しておく必要がなくなるので、性能が向上す
る。また、本発明によれば、クライアント/サーバ間の
データ転送とDBMSへのデータ受渡しとが並行して動
作するため、多数のクライアントからの処理でも安定し
たレスポンスが得られる。
ライアント側から転送されて来たBLOBデータを一時
的に保存しておく必要がなくなるので、性能が向上す
る。また、本発明によれば、クライアント/サーバ間の
データ転送とDBMSへのデータ受渡しとが並行して動
作するため、多数のクライアントからの処理でも安定し
たレスポンスが得られる。
【図1】クライアント/サーバ・システムの構成例を示
す図である。
す図である。
【図2】データ格納の処理シーケンスを示す図である。
【図3】BLOBデータを持つ表の例を示す図である。
【図4】BLOBデータの格納位置を説明する図であ
る。
る。
【図5】本発明の効果を示す図である。
10 サーバ 11 DBMS 12 サーバ処理部 13 メモリ 14 ディスク 20 クライアント 21 リクエスタ 23 メモリ 24 メモリ 25 ディスク
Claims (2)
- 【請求項1】 クライアントと、 リレーショナル・データベースを有するサーバと、 サーバとクライアントを接続する回線とを有するクライ
アント/サーバ型のデータベース・システムであって、 サーバとクライアントの間で、SQL文の転送後に変数
データを転送するプロトコルが取り決められ、 サーバは、バイナリ型の長大データの追加または更新を
示すSQL文を受け取ったときには、当該バイナリ型の
長大データの格納位置を決定し、 バイナリ型の長大データを受け取ったときには、当該バ
イナリ型の長大データを上記決定した格納位置に格納す
ることを特徴とするクライアント/サーバ型のデータベ
ース・システム。 - 【請求項2】 サーバは、サーバ処理部およびデータベ
ース管理システムを有しており、 サーバ処理部は、バイナリ型の長大データの追加または
更新を示すSQL文を受け取った時には、データベース
管理システムに対して準備実行要求を発行し、データベ
ース管理システムは、準備実行要求が発行されたときに
は、上記バイナリ型の長大データの格納位置を決定し、 サーバ処理部は、バイナリ型の長大データを受け取った
時には、当該バイナリ型の長大データをデータベース管
理システムに渡し、データベース管理システムは、渡さ
れたバイナリ型の長大データを上記決定された格納位置
に格納することを特徴とする請求項1記載のクライアン
ト/サーバ型のデータベース・システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP8167336A JPH1011464A (ja) | 1996-06-27 | 1996-06-27 | クライアント/サーバ型のデータベース・システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP8167336A JPH1011464A (ja) | 1996-06-27 | 1996-06-27 | クライアント/サーバ型のデータベース・システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH1011464A true JPH1011464A (ja) | 1998-01-16 |
Family
ID=15847853
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP8167336A Pending JPH1011464A (ja) | 1996-06-27 | 1996-06-27 | クライアント/サーバ型のデータベース・システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH1011464A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001027778A1 (fr) * | 1999-10-13 | 2001-04-19 | Kabushiki Kaisha Visual Japan | Systeme d'emission de donnees et systeme de gestion de ventes |
WO2001048638A2 (en) * | 1999-12-29 | 2001-07-05 | Unisys Corporation | Database management system and method for databases having large objects |
US6487551B2 (en) | 1998-09-24 | 2002-11-26 | International Business Machines Corporation | Externalizing very large objects in a relational database client/server environment |
US7257592B2 (en) | 2003-06-26 | 2007-08-14 | International Business Machines Corporation | Replicating the blob data from the source field to the target field based on the source coded character set identifier and the target coded character set identifier, wherein the replicating further comprises converting the blob data from the source coded character set identifier to the target coded character set identifier |
JP2019525286A (ja) * | 2016-07-04 | 2019-09-05 | 光毅 陶 | 光ディスクに基づくデータベースデュアルコア記憶システム及びそれを用いた方法 |
-
1996
- 1996-06-27 JP JP8167336A patent/JPH1011464A/ja active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6487551B2 (en) | 1998-09-24 | 2002-11-26 | International Business Machines Corporation | Externalizing very large objects in a relational database client/server environment |
WO2001027778A1 (fr) * | 1999-10-13 | 2001-04-19 | Kabushiki Kaisha Visual Japan | Systeme d'emission de donnees et systeme de gestion de ventes |
US7363654B1 (en) | 1999-10-13 | 2008-04-22 | Kabushiki Kaisha Visual Japan | Data transmission system and sale managing system |
WO2001048638A2 (en) * | 1999-12-29 | 2001-07-05 | Unisys Corporation | Database management system and method for databases having large objects |
WO2001048638A3 (en) * | 1999-12-29 | 2003-04-17 | Unisys Corp | Database management system and method for databases having large objects |
US7257592B2 (en) | 2003-06-26 | 2007-08-14 | International Business Machines Corporation | Replicating the blob data from the source field to the target field based on the source coded character set identifier and the target coded character set identifier, wherein the replicating further comprises converting the blob data from the source coded character set identifier to the target coded character set identifier |
JP2019525286A (ja) * | 2016-07-04 | 2019-09-05 | 光毅 陶 | 光ディスクに基づくデータベースデュアルコア記憶システム及びそれを用いた方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6356912B1 (en) | Compensation for different connection and cursor characteristics among heterogeneous database management systems | |
US6243718B1 (en) | Building indexes on columns containing large objects | |
JP4799936B2 (ja) | 条件別スナップショット取得方法及びシステム | |
US6738790B1 (en) | Approach for accessing large objects | |
US6058394A (en) | Manager server selects an agent server to execute query based on availability of the server connections to data source and target | |
US7139783B2 (en) | Materialized view system and method | |
US20040267744A1 (en) | Changing the data structure which an application program in a computer system uses to access database systems | |
JP2001357062A (ja) | データベース検索方法及びデータベース検索システム並びにデータベース検索プログラムを記録した記録媒体 | |
US6366902B1 (en) | Using an epoch number to optimize access with rowid columns and direct row access | |
US8819088B2 (en) | Implementing storage management functions using a data store system | |
US6343293B1 (en) | Storing the uncompressed data length in a LOB map to speed substring access within a LOB value | |
JPH1011464A (ja) | クライアント/サーバ型のデータベース・システム | |
JP3330006B2 (ja) | 情報記憶システムを備えるネットワークシステム、該システムの入力システムならびに | |
JPS62131349A (ja) | デ−タベ−ス処理方式 | |
JP2912657B2 (ja) | ファイルアクセス処理装置 | |
JPS63138442A (ja) | 削除フアイル復元処理方式 | |
JPH1091503A (ja) | 情報資源管理制御方法及びシステム | |
JP2721034B2 (ja) | クラスタリング制御システム | |
JP3006527B2 (ja) | クライアント/サーバ型データベースシステム | |
JPH05313965A (ja) | データベース管理システム | |
JPH02187827A (ja) | 端末プログラムのパッチ実施方式 | |
JP2000311063A (ja) | メインフレームを含むクラスタ内ファイル共用方式 | |
JPH04250568A (ja) | レコード検索装置 | |
JPH07191898A (ja) | データベース排他制御装置 | |
JPH01189741A (ja) | ジャーナル出力方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040302 |