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)【要約】
【課題】 ディスクへの書込み処理を最小限にしてデー
タベースの格納または更新を行い得るようにすること。 【解決手段】 リクエスタは、最初にＳＱＬ文をサーバ
処理部に送り、次に変数データをサーバ処理部に送る。
ＢＬＯＢデータ（バイナリ型の長大データ）の追加また
は更新を示すＳＱＬ文を受け取ると、サーバ処理部は準
備実行要求をＤＢＭＳに対して発行する。準備実行要求
を受け取ると、ＤＢＭＳはＢＬＯＢデータの格納位置を
決定する。サーバ処理部は、ＢＬＯＢデータを受け取る
と、これををＤＢＭＳに渡す。ＤＢＭＳは渡されたＢＬ
ＯＢデータを決定された格納位置に格納する。
タベースの格納または更新を行い得るようにすること。 【解決手段】 リクエスタは、最初にＳＱＬ文をサーバ
処理部に送り、次に変数データをサーバ処理部に送る。
ＢＬＯＢデータ（バイナリ型の長大データ）の追加また
は更新を示すＳＱＬ文を受け取ると、サーバ処理部は準
備実行要求をＤＢＭＳに対して発行する。準備実行要求
を受け取ると、ＤＢＭＳはＢＬＯＢデータの格納位置を
決定する。サーバ処理部は、ＢＬＯＢデータを受け取る
と、これををＤＢＭＳに渡す。ＤＢＭＳは渡されたＢＬ
ＯＢデータを決定された格納位置に格納する。
Description
【０００１】
【発明の属する技術分野】本発明は、クライアント／サ
ーバ型のデータベース・システムにおいて、ＢＬＯＢ
（BINARY LARGE OBJECT ：バイナリ型の長大データ）を
扱う場合の高速化手法に関するものである。
ーバ型のデータベース・システムにおいて、ＢＬＯＢ
（BINARY LARGE OBJECT ：バイナリ型の長大データ）を
扱う場合の高速化手法に関するものである。
【０００２】
【従来の技術】従来のホスト・システムでの更新処理に
おけるデータベース・システムとアプリケーションとの
変数データの受渡しは、メモリまたはディスクに格納し
たデータを一度に指定するものであった。しかし、クラ
イアント／サーバ・システムでは、更新データはクライ
アントに存在するため、ＢＬＯＢのような巨大データを
一回で受け渡すと、大量の転送時間が必要となる。この
ような場合、従来のインタフェースでは、サーバ上のサ
ーバ処理部が全ての更新データを受け取った後でなけれ
ばＤＢＭＳを呼び出すことが出来ない。更に、ＤＢＭＳ
側では、受け取ったデータを格納するため、サーバ処理
部がディスクに格納したデータを再度転送して格納する
ことになり、結果的に二回のディスクへの格納処理が必
要になっていた。
おけるデータベース・システムとアプリケーションとの
変数データの受渡しは、メモリまたはディスクに格納し
たデータを一度に指定するものであった。しかし、クラ
イアント／サーバ・システムでは、更新データはクライ
アントに存在するため、ＢＬＯＢのような巨大データを
一回で受け渡すと、大量の転送時間が必要となる。この
ような場合、従来のインタフェースでは、サーバ上のサ
ーバ処理部が全ての更新データを受け取った後でなけれ
ばＤＢＭＳを呼び出すことが出来ない。更に、ＤＢＭＳ
側では、受け取ったデータを格納するため、サーバ処理
部がディスクに格納したデータを再度転送して格納する
ことになり、結果的に二回のディスクへの格納処理が必
要になっていた。
【０００３】
【発明が解決しようとする課題】本発明は、この点に鑑
みて創作されたものであって、ディスクへの書込み処理
を最小限にしてデータベースの格納または更新を行い得
るようになったクライアント／サーバ型のデータベース
・システムを提供することを目的としている。
みて創作されたものであって、ディスクへの書込み処理
を最小限にしてデータベースの格納または更新を行い得
るようになったクライアント／サーバ型のデータベース
・システムを提供することを目的としている。
【０００４】
【課題を解決するための手段】請求項１のクライアント
／サーバ型のデータベース・システムは、クライアント
と、リレーショナル・データベースを有するサーバと、
サーバとクライアントを接続する回線とを有するクライ
アント／サーバ型のデータベース・システムであって、
サーバとクライアントの間で、ＳＱＬ文の転送後に変数
データを転送するプロトコルが取り決められ、サーバ
は、バイナリ型の長大データの追加または更新を示すＳ
ＱＬ文を受け取ったときには、当該バイナリ型の長大デ
ータの格納位置を決定し、バイナリ型の長大データを受
け取ったときには、当該バイナリ型の長大データを上記
決定した格納位置に格納することを特徴とするものであ
る。
／サーバ型のデータベース・システムは、クライアント
と、リレーショナル・データベースを有するサーバと、
サーバとクライアントを接続する回線とを有するクライ
アント／サーバ型のデータベース・システムであって、
サーバとクライアントの間で、ＳＱＬ文の転送後に変数
データを転送するプロトコルが取り決められ、サーバ
は、バイナリ型の長大データの追加または更新を示すＳ
ＱＬ文を受け取ったときには、当該バイナリ型の長大デ
ータの格納位置を決定し、バイナリ型の長大データを受
け取ったときには、当該バイナリ型の長大データを上記
決定した格納位置に格納することを特徴とするものであ
る。
【０００５】請求項２のクライアント／サーバ型のデー
タベース・システムは、請求項１のクライアント／サー
バ型のデータベース・システムにおいて、サーバは、サ
ーバ処理部およびデータベース管理システムを有してお
り、サーバ処理部は、バイナリ型の長大データの追加ま
たは更新を示すＳＱＬ文を受け取った時には、データベ
ース管理システムに対して準備実行要求を発行し、デー
タベース管理システムは、準備実行要求が発行されたと
きには、上記バイナリ型の長大データの格納位置を決定
し、サーバ処理部は、バイナリ型の長大データを受け取
った時には、当該バイナリ型の長大データをデータベー
ス管理システムに渡し、データベース管理システムは、
渡されたバイナリ型の長大データを上記決定された格納
位置に格納することを特徴とするものである。
タベース・システムは、請求項１のクライアント／サー
バ型のデータベース・システムにおいて、サーバは、サ
ーバ処理部およびデータベース管理システムを有してお
り、サーバ処理部は、バイナリ型の長大データの追加ま
たは更新を示すＳＱＬ文を受け取った時には、データベ
ース管理システムに対して準備実行要求を発行し、デー
タベース管理システムは、準備実行要求が発行されたと
きには、上記バイナリ型の長大データの格納位置を決定
し、サーバ処理部は、バイナリ型の長大データを受け取
った時には、当該バイナリ型の長大データをデータベー
ス管理システムに渡し、データベース管理システムは、
渡されたバイナリ型の長大データを上記決定された格納
位置に格納することを特徴とするものである。
【０００６】
【発明の実施の形態】図１は本発明のクライアント／サ
ーバ・システムの構成例を示すものである。同図におい
て、１０はサーバ、１１はＤＢＭＳ（データベース管理
システム）、１２はサーバ処理部、１３はメモリ、１４
はディスク、２０はクライアント、２１はリクエスタ、
２３と２４はメモリ、２５はディスクを示している。
ーバ・システムの構成例を示すものである。同図におい
て、１０はサーバ、１１はＤＢＭＳ（データベース管理
システム）、１２はサーバ処理部、１３はメモリ、１４
はディスク、２０はクライアント、２１はリクエスタ、
２３と２４はメモリ、２５はディスクを示している。
【０００７】サーバ１０は例えばＤＳ／９０と呼ばれる
計算機であり、クライアント２０は例えば通常のパソコ
ンである。サーバ１０とクライアント２０は、回線で接
続されている。ＤＢＭＳ１１やサーバ処理部１２，リク
エスタ２１は、プログラムで実現されている。なお、図
示しないが、一般にサーバには回線を介して複数のクラ
イアントが接続されている。
計算機であり、クライアント２０は例えば通常のパソコ
ンである。サーバ１０とクライアント２０は、回線で接
続されている。ＤＢＭＳ１１やサーバ処理部１２，リク
エスタ２１は、プログラムで実現されている。なお、図
示しないが、一般にサーバには回線を介して複数のクラ
イアントが接続されている。
【０００８】サーバ１０は、ＤＢＭＳ１１やサーバ処理
部１２，メモリ１３，ディスク１４を有している。ＤＢ
ＭＳ１１は、データベースのアクセスを制御するもので
ある。サーバ処理部１２は、クライアント側から送られ
てきたＳＱＬ文やデータをＤＢＭＳ１１に渡すための処
理を行う。メモリ１３は、クライアント側からのデータ
を一時的に記憶するものである。ディスク１４には、リ
レーショナル・データベースのデータが格納されてい
る。
部１２，メモリ１３，ディスク１４を有している。ＤＢ
ＭＳ１１は、データベースのアクセスを制御するもので
ある。サーバ処理部１２は、クライアント側から送られ
てきたＳＱＬ文やデータをＤＢＭＳ１１に渡すための処
理を行う。メモリ１３は、クライアント側からのデータ
を一時的に記憶するものである。ディスク１４には、リ
レーショナル・データベースのデータが格納されてい
る。
【０００９】クライアント２０は、リクエスタ２１やア
プリケーション２２，メモリ２３，メモリ２４，ディス
ク２５を有している。リクエスタ２１は、アプリケーシ
ョンから処理要求やデータを受け取り、これら処理要求
やデータをサーバ側に送る。アプリケーション２２は、
リクエスタ２１に対して処理要求やデータを渡す。メモ
リ２３はアプリケーション２２に割り当てられており、
メモリ２４はリクエスタ２１に対して割り当てられてい
る。ディスク２５の中には、各種のデータが格納されて
いる。
プリケーション２２，メモリ２３，メモリ２４，ディス
ク２５を有している。リクエスタ２１は、アプリケーシ
ョンから処理要求やデータを受け取り、これら処理要求
やデータをサーバ側に送る。アプリケーション２２は、
リクエスタ２１に対して処理要求やデータを渡す。メモ
リ２３はアプリケーション２２に割り当てられており、
メモリ２４はリクエスタ２１に対して割り当てられてい
る。ディスク２５の中には、各種のデータが格納されて
いる。
【００１０】アプリケーション２２とリクエスタ２１と
の間のインタフェースは、例えばＯＤＢＣ(Open DataBa
se Connectivity:米国マイクロソフト社の商標）で定め
られているように、先ず処理要求を発行し、その後、必
要なデータを転送することが可能な方式であるものとす
る。
の間のインタフェースは、例えばＯＤＢＣ(Open DataBa
se Connectivity:米国マイクロソフト社の商標）で定め
られているように、先ず処理要求を発行し、その後、必
要なデータを転送することが可能な方式であるものとす
る。
【００１１】リクエスタ２１とサーバ処理部１２との間
には、ＳＱＬ文の転送後に変数データを転送すると言う
プロトコルが取り決められている。サーバ処理部１２
は、ＳＱＬ文を受け取ると、ＤＢＭＳ１１に対してデー
タ格納位置の決定を要求し、次いでデータをＤＢＭＳ１
１に渡す。データを複数回に分けて渡しても良い。
には、ＳＱＬ文の転送後に変数データを転送すると言う
プロトコルが取り決められている。サーバ処理部１２
は、ＳＱＬ文を受け取ると、ＤＢＭＳ１１に対してデー
タ格納位置の決定を要求し、次いでデータをＤＢＭＳ１
１に渡す。データを複数回に分けて渡しても良い。
【００１２】ＤＢＭＳ１１が格納するデータは、論理的
には複数の欄から成る行の集まりとして管理される。行
はレコードと呼ばれる物理的な単位でまとめて格納され
る。ただし、ＢＬＯＢデータについてはデータは別に格
納され、レコード中には位置（内部的な名前）のみが格
納される。ＤＢＭＳ１１は、受け取ったＢＬＯＢデータ
を予め処理要求が正常終了した時に格納される場所に転
送する。ただし、この結果は、全てのデータが受け渡さ
れ、最後にレコードが追加または更新されるまで外から
は見えない。
には複数の欄から成る行の集まりとして管理される。行
はレコードと呼ばれる物理的な単位でまとめて格納され
る。ただし、ＢＬＯＢデータについてはデータは別に格
納され、レコード中には位置（内部的な名前）のみが格
納される。ＤＢＭＳ１１は、受け取ったＢＬＯＢデータ
を予め処理要求が正常終了した時に格納される場所に転
送する。ただし、この結果は、全てのデータが受け渡さ
れ、最後にレコードが追加または更新されるまで外から
は見えない。
【００１３】図２はデータ格納処理シーケンスを説明す
るための図である。データ格納のためのＳＱＬ文は、例
えば INSERT INTO TABLE1 VALUES （：従業員番号，：顔写
真） と言うものである。顔写真はＢＬＯＢデータである。
るための図である。データ格納のためのＳＱＬ文は、例
えば INSERT INTO TABLE1 VALUES （：従業員番号，：顔写
真） と言うものである。顔写真はＢＬＯＢデータである。
【００１４】クライアント側のアプリケーションは、最
初にＳＱＬ文を登録する。ＳＱＬ文の登録は、具体的に
は例えばＯＤＢＣ ＡＰＩではＳＱＬＰｒｅｐａｒｅ関
数が対応する。リクエスタは、登録されたＳＱＬ文を記
憶し、後の実行に備える。登録されたＳＱＬ文は繰り返
して実行要求を行うことが出来る。
初にＳＱＬ文を登録する。ＳＱＬ文の登録は、具体的に
は例えばＯＤＢＣ ＡＰＩではＳＱＬＰｒｅｐａｒｅ関
数が対応する。リクエスタは、登録されたＳＱＬ文を記
憶し、後の実行に備える。登録されたＳＱＬ文は繰り返
して実行要求を行うことが出来る。
【００１５】アプリケーションは、ＳＱＬ文の登録を行
った後、変数（上記の例では、従業員番号と顔写真）の
宣言を行う。変数の宣言は、具体的には例えばＯＤＢＣ
ＡＰＩではＳＱＬＢｉｎｄＰａｒａｍｅｔｅｒ関数が
対応する。この処理は、変数データの型と長さを通知す
る処理である。この長さをもとに、リクエスタは最終デ
ータを判定する。
った後、変数（上記の例では、従業員番号と顔写真）の
宣言を行う。変数の宣言は、具体的には例えばＯＤＢＣ
ＡＰＩではＳＱＬＢｉｎｄＰａｒａｍｅｔｅｒ関数が
対応する。この処理は、変数データの型と長さを通知す
る処理である。この長さをもとに、リクエスタは最終デ
ータを判定する。
【００１６】アプリケーションは、変数の宣言を行った
後、ＳＱＬ文の実行を指示する。これは、具体的には例
えばＯＤＢＣ ＡＰＩではＳＱＬＥｘｅｃｕｔｅ関数が
対応する。ＳＱＬ文の実行が指示されると、リクエスタ
は、ＳＱＬ文（変数データの宣言を含む）をサーバ側に
送ると共に、アプリケーションに対してデータを要求す
る。
後、ＳＱＬ文の実行を指示する。これは、具体的には例
えばＯＤＢＣ ＡＰＩではＳＱＬＥｘｅｃｕｔｅ関数が
対応する。ＳＱＬ文の実行が指示されると、リクエスタ
は、ＳＱＬ文（変数データの宣言を含む）をサーバ側に
送ると共に、アプリケーションに対してデータを要求す
る。
【００１７】サーバ処理部は、ＳＱＬ文を受け取ると、
文内容を解析する。このＳＱＬ文は変数データとしてＢ
ＬＯＢデータを含んでいるので、データ処理部は、ＤＢ
ＭＳに対して準備実行要求を発行する。ＤＢＭＳは、準
備実行要求を受け取ると、サーバ処理部が受け取ったＳ
ＱＬ文を解析し、ＢＬＯＢデータの格納位置を決定す
る。
文内容を解析する。このＳＱＬ文は変数データとしてＢ
ＬＯＢデータを含んでいるので、データ処理部は、ＤＢ
ＭＳに対して準備実行要求を発行する。ＤＢＭＳは、準
備実行要求を受け取ると、サーバ処理部が受け取ったＳ
ＱＬ文を解析し、ＢＬＯＢデータの格納位置を決定す
る。
【００１８】アプリケーションは、リクエスタからのデ
ータの要求を受け取ると、データの受渡しを行う。リク
エスタは、渡されたデータの総計が転送最大サイズに達
するまでアプリケーションに対してデータの要求を行
い、転送最大サイズに達したならば、渡された全データ
をサーバ側に転送する。転送データには、データの型や
何番目の変数データかを示す制御データが付加されてい
る。なお、転送最大サイズは３２Ｋ〜１２８Ｋバイト程
度である。ＢＬＯＢデータとして、画像，音声，，動
画，長大なテキスト等があり、大きさは特に定まってい
ないが、例えば画像データは数十Ｋバイト〜数Ｍバイト
程度の大きさを持つ。
ータの要求を受け取ると、データの受渡しを行う。リク
エスタは、渡されたデータの総計が転送最大サイズに達
するまでアプリケーションに対してデータの要求を行
い、転送最大サイズに達したならば、渡された全データ
をサーバ側に転送する。転送データには、データの型や
何番目の変数データかを示す制御データが付加されてい
る。なお、転送最大サイズは３２Ｋ〜１２８Ｋバイト程
度である。ＢＬＯＢデータとして、画像，音声，，動
画，長大なテキスト等があり、大きさは特に定まってい
ないが、例えば画像データは数十Ｋバイト〜数Ｍバイト
程度の大きさを持つ。
【００１９】サーバ処理部は、クライアント側からの転
送データを受け取ると、その内のＢＬＯＢデータをＤＢ
ＭＳに受け渡し、受取りの完了をクライアントに対して
通知する。ＤＢＭＳは、渡されたＢＬＯＢデータを予め
決定された格納位置に格納する。なお、ＢＬＯＢ以外の
データは、実処理実行要求で纏めて渡される。
送データを受け取ると、その内のＢＬＯＢデータをＤＢ
ＭＳに受け渡し、受取りの完了をクライアントに対して
通知する。ＤＢＭＳは、渡されたＢＬＯＢデータを予め
決定された格納位置に格納する。なお、ＢＬＯＢ以外の
データは、実処理実行要求で纏めて渡される。
【００２０】リクエスタは受取りの完了を受け取ると次
のデータをサーバ側に転送し、サーバ処理部は転送デー
タを受け取って転送データ中のＢＬＯＢデータをＤＢＭ
Ｓに受け渡し、受取り完了をクライアントに対して通知
する。このような処理は、繰り返し行われる。
のデータをサーバ側に転送し、サーバ処理部は転送デー
タを受け取って転送データ中のＢＬＯＢデータをＤＢＭ
Ｓに受け渡し、受取り完了をクライアントに対して通知
する。このような処理は、繰り返し行われる。
【００２１】転送データが最後のものである場合には、
サーバ処理部は、その内のＢＬＯＢデータをＤＢＭＳに
受け渡し、その後で実処理実行要求をＤＢＭＳに対して
発行する。ＤＢＭＳは、上述のように渡されたＢＬＯＢ
データを予め決定された格納位置に格納する。
サーバ処理部は、その内のＢＬＯＢデータをＤＢＭＳに
受け渡し、その後で実処理実行要求をＤＢＭＳに対して
発行する。ＤＢＭＳは、上述のように渡されたＢＬＯＢ
データを予め決定された格納位置に格納する。
【００２２】また、ＤＢＭＳは、実処理実行要求を受け
取ると、再びＳＱＬ文を詳細に解析してＳＱＬ文で示さ
れた要求を実行する。ＢＬＯＢデータを含まない場合に
は、この呼出し一回だけでＳＱＬ文の処理が実行され
る。この呼出し前にＢＬＯＢデータは格納されている
が、この処理が行われるまで、他の利用者はデータベー
スに登録されたＢＬＯＢデータを参照することはできな
い。
取ると、再びＳＱＬ文を詳細に解析してＳＱＬ文で示さ
れた要求を実行する。ＢＬＯＢデータを含まない場合に
は、この呼出し一回だけでＳＱＬ文の処理が実行され
る。この呼出し前にＢＬＯＢデータは格納されている
が、この処理が行われるまで、他の利用者はデータベー
スに登録されたＢＬＯＢデータを参照することはできな
い。
【００２３】上述のＩＮＳＥＲＴのＳＱＬ文の場合に
は、ＤＢＭＳは、指示された値の従業員番号および格納
されたＢＬＯＢデータに付けられた内部的な名前を持つ
レコードを，ＴＡＢＬＥ１と呼ばれる表に追加する。実
処理実行要求を処理した後、ＤＢＭＳは、完了通知を発
行する。この完了通知は、サーバ処理部およびリクエス
タを経由して、アプリケーションに送られる。
は、ＤＢＭＳは、指示された値の従業員番号および格納
されたＢＬＯＢデータに付けられた内部的な名前を持つ
レコードを，ＴＡＢＬＥ１と呼ばれる表に追加する。実
処理実行要求を処理した後、ＤＢＭＳは、完了通知を発
行する。この完了通知は、サーバ処理部およびリクエス
タを経由して、アプリケーションに送られる。
【００２４】図３はＢＬＯＢデータを持つ表の例を示す
図である。図示の例では、各行（レコード）は、従業員
番号の欄と，顔写真の欄を有している。顔写真のデータ
型はＢＬＯＢである。顔写真に対して、「ＡＡ」，「Ｂ
Ｂ」，…，「ＸＸ」などの内部的な名前が付けられてい
る。各行の顔写真の欄には、内部的な名前が記入されて
いる。
図である。図示の例では、各行（レコード）は、従業員
番号の欄と，顔写真の欄を有している。顔写真のデータ
型はＢＬＯＢである。顔写真に対して、「ＡＡ」，「Ｂ
Ｂ」，…，「ＸＸ」などの内部的な名前が付けられてい
る。各行の顔写真の欄には、内部的な名前が記入されて
いる。
【００２５】図４はＢＬＯＢデータの格納位置の決定を
説明する図である。ＴＡＢＬＥ１と呼ばれるディレクト
リは、ＴＡＢＬＥ１と呼ばれる表のＢＬＯＢデータを管
理するものである。このディレクトリは複数のエントリ
を有しており、各エントリはデータの型がＢＬＯＢであ
ること、ＢＬＯＢデータに付けられた内部的な名前，物
理的な格納位置，データの大きさ等を示す管理情報を記
憶している。
説明する図である。ＴＡＢＬＥ１と呼ばれるディレクト
リは、ＴＡＢＬＥ１と呼ばれる表のＢＬＯＢデータを管
理するものである。このディレクトリは複数のエントリ
を有しており、各エントリはデータの型がＢＬＯＢであ
ること、ＢＬＯＢデータに付けられた内部的な名前，物
理的な格納位置，データの大きさ等を示す管理情報を記
憶している。
【００２６】図３における従業員番号が８８８で，顔写
真の名前がＸＸである行が，上述のＳＱＬ文によって追
加されたものとする。このような行が追加されるまでの
過程を説明すると、次のようになる。
真の名前がＸＸである行が，上述のＳＱＬ文によって追
加されたものとする。このような行が追加されるまでの
過程を説明すると、次のようになる。
【００２７】 ＤＢＭＳは、準備実行要求を受け取る
と、顔写真のＢＬＯＢデータを格納するための領域を確
保し、この格納領域にＸＸと言う名前を付与し、この格
納領域を特定するために必要な管理情報をＴＡＢＬＥ１
と言うディレクトリの空きエントリに書き込む。 ＤＢＭＳは、ＢＬＯＢデータが受け渡される度に、
渡されたＢＬＯＢデータを格納領域ＸＸに格納する。 ＤＢＭＳは、実処理実行要求を受け取ると、従業員
番号の値が８８８で，顔写真の値がＸＸである行を表
（ＴＡＢＬＥ１という名前の）に追加する。
と、顔写真のＢＬＯＢデータを格納するための領域を確
保し、この格納領域にＸＸと言う名前を付与し、この格
納領域を特定するために必要な管理情報をＴＡＢＬＥ１
と言うディレクトリの空きエントリに書き込む。 ＤＢＭＳは、ＢＬＯＢデータが受け渡される度に、
渡されたＢＬＯＢデータを格納領域ＸＸに格納する。 ＤＢＭＳは、実処理実行要求を受け取ると、従業員
番号の値が８８８で，顔写真の値がＸＸである行を表
（ＴＡＢＬＥ１という名前の）に追加する。
【００２８】上述の説明は格納のＳＱＬ文に関するもの
であるが、例えば「ＴＡＢＬＥ１という表において、従
業員番号の値が００１である行の顔写真を更新せよ」と
言う更新のＳＱＬ文の場合には、ＤＢＭＳは下記のよう
な処理を行う。 受け取ったデータのために、新たに例えばＹＹとい
う名前の格納領域を生成する。 ＤＢＭＳは、ＢＬＯＢデータが受け渡される度に、
渡されたＢＬＯＢデータを格納領域ＹＹに格納する。 ＤＢＭＳは、実処理実行要求を受け取ると、レコー
ド中のＡＡをＹＹに変更し、格納領域ＡＡを削除する。
また、ＢＬＯＢデータ以外のデータの更新を行う。ただ
し、上述のような内容のＳＱＬ文の場合には、ＢＬＯＢ
データ以外のデータの更新は行われない。
であるが、例えば「ＴＡＢＬＥ１という表において、従
業員番号の値が００１である行の顔写真を更新せよ」と
言う更新のＳＱＬ文の場合には、ＤＢＭＳは下記のよう
な処理を行う。 受け取ったデータのために、新たに例えばＹＹとい
う名前の格納領域を生成する。 ＤＢＭＳは、ＢＬＯＢデータが受け渡される度に、
渡されたＢＬＯＢデータを格納領域ＹＹに格納する。 ＤＢＭＳは、実処理実行要求を受け取ると、レコー
ド中のＡＡをＹＹに変更し、格納領域ＡＡを削除する。
また、ＢＬＯＢデータ以外のデータの更新を行う。ただ
し、上述のような内容のＳＱＬ文の場合には、ＢＬＯＢ
データ以外のデータの更新は行われない。
【００２９】
【発明の効果】図５は本発明の効果を示す図である。従
来処理においては、サーバ処理部は、クライアントとの
間のデータ転送と、転送されて来たデータを自己に割り
当てられたディスク領域に格納する処理とを行う。デー
タの転送が終了すると、サーバ処理部はＤＢＭＳを呼出
す。ＤＢＭＳは、ＢＬＯＢデータをサーバ処理部のディ
スク領域から読み出して予め定められた格納位置に書き
込むと共に、レコード処理を行う。
来処理においては、サーバ処理部は、クライアントとの
間のデータ転送と、転送されて来たデータを自己に割り
当てられたディスク領域に格納する処理とを行う。デー
タの転送が終了すると、サーバ処理部はＤＢＭＳを呼出
す。ＤＢＭＳは、ＢＬＯＢデータをサーバ処理部のディ
スク領域から読み出して予め定められた格納位置に書き
込むと共に、レコード処理を行う。
【００３０】本発明の処理においては、サーバ処理部は
クライアントとの間のデータ転送と、転送されて来たＢ
ＬＯＢデータをＤＢＭＳに引き渡す処理を行う。ＤＢＭ
Ｓは、ＢＬＯＢデータを受け取り、これを予め定められ
た格納位置に書き込む。ＢＬＯＢデータの書込みが終了
した後、ＤＢＭＳはレコード処理を行う。
クライアントとの間のデータ転送と、転送されて来たＢ
ＬＯＢデータをＤＢＭＳに引き渡す処理を行う。ＤＢＭ
Ｓは、ＢＬＯＢデータを受け取り、これを予め定められ
た格納位置に書き込む。ＢＬＯＢデータの書込みが終了
した後、ＤＢＭＳはレコード処理を行う。
【００３１】図５から判るように、本発明によれば、ク
ライアント側から転送されて来たＢＬＯＢデータを一時
的に保存しておく必要がなくなるので、性能が向上す
る。また、本発明によれば、クライアント／サーバ間の
データ転送とＤＢＭＳへのデータ受渡しとが並行して動
作するため、多数のクライアントからの処理でも安定し
たレスポンスが得られる。
ライアント側から転送されて来たＢＬＯＢデータを一時
的に保存しておく必要がなくなるので、性能が向上す
る。また、本発明によれば、クライアント／サーバ間の
データ転送とＤＢＭＳへのデータ受渡しとが並行して動
作するため、多数のクライアントからの処理でも安定し
たレスポンスが得られる。
【図１】クライアント／サーバ・システムの構成例を示
す図である。
す図である。
【図２】データ格納の処理シーケンスを示す図である。
【図３】ＢＬＯＢデータを持つ表の例を示す図である。
【図４】ＢＬＯＢデータの格納位置を説明する図であ
る。
る。
【図５】本発明の効果を示す図である。
１０ サーバ １１ ＤＢＭＳ １２ サーバ処理部 １３ メモリ １４ ディスク ２０ クライアント ２１ リクエスタ ２３ メモリ ２４ メモリ ２５ ディスク
Claims (2)
- 【請求項１】 クライアントと、 リレーショナル・データベースを有するサーバと、 サーバとクライアントを接続する回線とを有するクライ
アント／サーバ型のデータベース・システムであって、 サーバとクライアントの間で、ＳＱＬ文の転送後に変数
データを転送するプロトコルが取り決められ、 サーバは、バイナリ型の長大データの追加または更新を
示すＳＱＬ文を受け取ったときには、当該バイナリ型の
長大データの格納位置を決定し、 バイナリ型の長大データを受け取ったときには、当該バ
イナリ型の長大データを上記決定した格納位置に格納す
ることを特徴とするクライアント／サーバ型のデータベ
ース・システム。 - 【請求項２】 サーバは、サーバ処理部およびデータベ
ース管理システムを有しており、 サーバ処理部は、バイナリ型の長大データの追加または
更新を示すＳＱＬ文を受け取った時には、データベース
管理システムに対して準備実行要求を発行し、データベ
ース管理システムは、準備実行要求が発行されたときに
は、上記バイナリ型の長大データの格納位置を決定し、 サーバ処理部は、バイナリ型の長大データを受け取った
時には、当該バイナリ型の長大データをデータベース管
理システムに渡し、データベース管理システムは、渡さ
れたバイナリ型の長大データを上記決定された格納位置
に格納することを特徴とする請求項１記載のクライアン
ト／サーバ型のデータベース・システム。
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 |