JPH06251068A

JPH06251068A - データベース管理方法

Info

Publication number: JPH06251068A
Application number: JP5036343A
Authority: JP
Inventors: Kiyotaka Kibo; 清隆木保; Shunichi Torii; 俊一鳥居; Kazuyoshi Negishi; 和義根岸; Masashi Tsuchida; 正士土田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1993-02-25
Filing date: 1993-02-25
Publication date: 1994-09-09

Abstract

(57)【要約】【構成】通信ネットワークで接続された複数の処理装置
上で、データベース１０２をアクセスするバックエンド
サーバ１０１とジャーナルをアクセスするジャーナルサ
ーバ１０７とデータベース定義情報をアクセスする辞書
サーバ１０５とアプリケーションプログラム１０４から
の要求を受けて処理部に処理を依頼するフロントエンド
サーバ１０３にデータベース１０２管理システムの各処
理部を分割し、少なくとも各処理部一つ以上を各処理装
置上に配置する。【効果】構成変更の容易化並びに運用の簡便性を実現す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデータベース管理システ
ムを実現するための構成方法とその機能分散方法に関す
る。

【０００２】

【従来の技術】従来分散データベース管理システムは図
２に示す構造であった。即ち一つのノード（一つ以上の
処理装置で構成される計算機システム）上に、データベ
ース管理システム（２０４，２０５；以後ＤＢＭＳと略
す。）とデータ通信管理システム（２０６，２０７；以
後ＤＣＭＳと略す。）が存在し、それぞれの管理システ
ムが相互協調してアプリケーション（２０３；以下ＡＰ
と略す）の要求するデータベース操作処理を実行する。
ここでＤＢＭＳはデータベース、即ち、二次記憶装置上
に記録された構造化されたデータを管理し、ＤＣＭＳは
ノード間における処理単位間（この場合、ＤＢＭＳ間）
の通信を管理，制御する。

【０００３】同形態のＤＢＭＳではＤＢＭＳがデータベ
ース（２０８，２０９）並びにジャーナル（２１０，２
１１），辞書（２１２，２１３）等を保持する。ここで
データベースは構造化され、二次記憶装置上に記録され
た永続的なデータである。ジャーナルはＤＢＭＳがデー
タベースに対する操作時の変更履歴情報並びにトランザ
クションの状態制御情報を、二次記憶装置上に記録した
永続的なデータである。辞書は記憶装置上に記憶されて
いる個々のデータベースの構造に関する情報を記録す
る。

【０００４】本構成の特徴は、（１）データベース管理
システムがデータベース，ジャーナル，辞書等の資源を
一括集中管理しながらＡＰからの要求に対して処理を行
う、（２）各ノード単位に上記各資源が存在し、分散デ
ータベースアクセスの場合も、個々のノード上の各資源
を利用してデータベース処理を行う、という点である。

【０００５】

【発明が解決しようとする課題】例えば特定データベー
スに対して処理が集中する場合、負荷分散を行う。負荷
分散を行うには、各ノードの資源を増設するか、ノード
を分割して処理の集中を避ける必要がある。従来技術で
はノードの分割に伴って、分割したノード上にデータベ
ース，ジャーナル，辞書等の資源を再確保する必要があ
る。通常、特定の資源に対する負荷ネックが問題になる
ことが一般的であるのに、従来システムでは拡張したい
資源のみを分割することができない。

【０００６】また、従来の分散環境においてデータベー
ス，ジャーナル，辞書等の資源の運用を行う場合、ノー
ドの場所に依存して独立に運用する必要がある。例え
ば、分散データベース管理システムにおけるジャーナル
ファイルは、従来、個々のノード上に存在した。これは
ジャーナルの運用を考えた場合、個々のノードでジャー
ナルの掛け変え等の運用を行わなければならない。

【０００７】さらに、従来構成の場合、各ノード対応に
ＤＢＭＳに必要な実行時メモリ，二次記憶が増加する。
即ち個々のノードにおいてデータベース管理システムが
必要とする全ての資源を確保しなければならない。

【０００８】

【課題を解決するための手段】本発明は以下の構成によ
り上記課題を解決する。

【０００９】（１）通信ネットワークで接続された複数
の処理装置上で、データベースをアクセスするバックエ
ンド処理部とジャーナルをアクセスするジャーナル処理
部とデータベース定義情報をアクセスする辞書処理部と
アプリケーションプログラムからの要求を受けて上記処
理部に処理を依頼するフロントエンド処理部において、
各処理部を一つ以上、上記任意の処理装置上に配置し、
その配置に基づいてデータベース処理を行う。

【００１０】（２）（１）におけるデータベース管理方
法とそのシステムであって、各処理部の配置指示を任意
の処理装置上に保持し、その配置情報に基づいて各処理
部を配置指示する。

【００１１】（３）（２）におけるデータベース管理方
法とそのシステムであって、アプリケーションプログラ
ムが任意のフロントエンド処理部を選択し、フロントエ
ンド処理部はフロントエンド処理部の構成情報に指示さ
れた辞書処理部を選択し、フロントエンド処理部は辞書
処理部の保持する辞書情報からバックエンド処理部を選
択し、フロントエンド処理部並びにバックエンド処理部
はその構成情報に指示されたジャーナル処理部を選択
し、上記選択した各処理部を用いてデータベース処理を
行う。

【００１２】

【作用】本発明に於ては従来データベース管理システム
内に内在していた各機能を(１)フロントエンド処理部
（２）バックエンド処理部（３）ジャーナル処理部
（４）辞書処理部に分割し、それを任意の処理装置上に
任意に配置して、それぞれの処理部が相互協調して処理
を行う。本構成により従来一つのノードに一つのデータ
ベース管理システムという構成であったデータベース管
理システム構成を上記処理部毎に任意の処理装置上に配
置することを可能とする。

【００１３】

【実施例】図１の構成は本発明を適用した場合の各処理
部（以後サーバと呼ぶ。）の構成と、サーバと資源の対
応関連，ノード構成，通信路の位置づけを示す。フロン
トエンドサーバ１０３（以下ＦＥＳと略す。）はアプリ
ケーションプログラム104（以下ＡＰと略す。）からの
問い合わせを受信し、処理手順を生成する。バックエン
ドサーバ（以下ＢＥＳと略す）１０１はＦＥＳからの処
理手順を受信してデータベース１０２（以下ＤＢと略
す。）をアクセスしてデータを取得しＦＥＳに渡す。ジ
ャーナルサーバ１０７（以下ＪＳと略す。）はＦＥＳや
ＢＥＳが発生する変更履歴情報やトランザクションの状
態情報を記録する。データディクショナリサーバ１０５
（以下ＤＤＳと略す。）はＦＥＳやＢＥＳ（またはＪ
Ｓ）が利用するメタ情報、例えば関係データベースにお
ける表情報や各表のカラム情報をデータディクショナリ
（以後ＤＤと略す。）に保持する。

【００１４】図１の１１１から１２１はノードである。
ノードは一つ以上の処理装置と永続的な記録が可能な二
次記録装置からなる。通信路Xbus１０は通信を行う為の
通信バックボーンであり、各サーバ間での通信の媒介を
行う。ノードにはそのノード固有のノードアドレスが付
与される。ノードアドレスは物理的なノード識別子であ
りXbus上ではこのノードアドレスを指定した通信を行
う。

【００１５】通信路Xbusは通信システムにおけるプロト
コルの違いやネットワークインタフェースの違いを吸収
し、Xbus上に存在する全てのサーバに対して相手サーバ
を識別する為の識別子、即ち、サーバ識別子を指定して
送受信を行うことを可能とする。後述するネームサーバ
はサーバ識別子を持ち、各サーバから通信要求があった
場合にサーバ識別子をノードアドレス，サーバプロセス
番号に変換する。

【００１６】Xbus上でのサーバ間送受信はＳＥＮＤ，Ｒ
ＥＣＩＥＶＥ形式で行う。send，recieveは以下の形式
である。すなわち、 send（サーバ識別子，データ，データサイズ） recieve（サーバ識別子，データ，データサイズ）これらはXbus通信処理部において下記の形式に変換され
る。すなわち、 Xbussend（ノードアドレス．プロセス番号，データ，デ
ータサイズ） Xbusrecieve（ノードアドレス．プロセス番号，デー
タ，データサイズ）このデータ部は（１）処理要求（２）要求元サーバ識別
子（３）要求先サーバ識別子（４）パラメタ等で構成さ
れる。

【００１７】Xbus上で通信に参加するにはサーバまたは
ＡＰがXbusに関する情報を取り込む。同情報にはウェル
ノウンノードとそのノードアドレスが保持される。各Ａ
Ｐ，サーバはXbus上のウェルノウンノードアドレスを知
ることで、他のサーバのサーバ識別子を用いたXbus上の
通信が可能となる。

【００１８】次に図３を用いて本発明の構成例を示す。
図３において、３３１から３３６はノードである。ＦＥ
Ｓ３０２はＡＰ３０１との通信を行う。ＡＰ構成情報３
１９はＡＰがどのＦＥＳと通信を行うかの情報を持つ。
ＢＥＳ３１０，３１２はデータベースを保持する。ＪＳ
３１３はＦＥＳやＢＥＳが記録要求するジャーナルを記
録し、ＤＤＳ３１４はデータベースの定義情報を記録す
る。Xbus３００はサーバ間で通信を行うための通信路で
ある。Xbus通信３０３から３０９はXbusを利用して実際
に通信を行う処理部であり、各サーバに存在する。

【００１９】ネームサーバ３１５は前述のウェルノウン
なノード上に存在する。ウェルノウンなノードは本デー
タベース管理システムに存在する全てのノードがそのア
ドレスを知っているノードである。ノードどうしが通信
を行う場合、相手ノードに付与されたノードアドレスを
相互のノードが知っている必要がある。ウェルノウンノ
ードのネームサーバはこのノードアドレスの一覧表をシ
ステム開始時、収集するかまたはウェルノウンノード上
の二次記憶上に記録する。以降ではシステム開始時に前
述の情報を収集することを前提とする。この収集の結
果、ネームサーバは本システムに参加するサーバのサー
バ識別子とノードアドレス，プロセス番号の対応表を持
つ。

【００２０】構成情報サーバ３１７はウェルノウンノー
ド上に存在する各ノードの構成情報を管理するサーバで
ある。同サーバは構成情報３１８に保持されている各ノ
ードのサーバ構成情報を管理する。

【００２１】図４に本発明を適用した場合のデータベー
ス管理システムにおいて実現される構成情報３１８を示
す。図４に示した構成情報は図３に示した構成情報であ
る。

【００２２】構成情報は本システムに参加するノード識
別子とノードアドレスとシステム内一意のサーバ識別子
の一覧、各サーバ即ち（１）ＦＥＳ（２)ＢＥＳ（３)Ｄ
ＤＳ（４）ＪＳに関する情報が保持される。

【００２３】ノード識別子は各ノードに一意に付与され
た論理的な名前である。ＦＥＳに関する構成情報は
（１）ＦＥＳがアクセス対象とするＢＥＳ名の一覧（基
本的にはウェルノウンノードに登録された全てのＢＥＳ
である。）（２）ＦＥＳが扱うトランザクションに関す
る制御情報の出力先ＪＳの識別子（３）ＡＰから要求さ
れた問い合わせ中に定義された表，カラムに関する定義
情報を保持している辞書サーバ識別子が指定される。ま
たこの他にＦＥＳ自身に関する構成情報例えば同時処理
可能なＡＰの数やバッファの容量等の情報が保持され
る。

【００２４】ＢＥＳに関する構成情報は（１）ＢＥＳが
データベースに対して変更を行った場合にデータベース
の変更履歴情報を保持するＪＳ識別子の保持（２）デー
タベースをアクセスするために必要な定義情報を保持す
る辞書サーバ識別子を保持する。またＦＥＳ同様にＢＥ
Ｓ自身の構成情報を保持する。

【００２５】ＪＳに関する構成情報は基本的に各サーバ
との関連を持たない。ＪＳ自身の構成情報については他
のサーバ同様に保持される。

【００２６】ＤＤＳに関する構成情報は基本的に各サー
バとの関連情報は保持されない。

【００２７】ＤＤＳ自身の構成情報も保持される。

【００２８】図５から図７を用いて、次にシステム開始
時に上記構成情報を元に本データベース管理システムが
どのように起動されるかについて説明する。

【００２９】図５はネームサーバで利用するノードアド
レスとサーバ識別子のプロセス−サーバ対応表３１６で
ある。ノードアドレス５０１は各ノード固有に付与され
た番号である。プロセス番号５０２は各ノード上でサー
バが起動された時にＯＳが付与する順序番号でＯＳ起動
中に一意な番号が付与される。

【００３０】サーバ識別子５０４は各ノード固有に付与
された論理的な識別子であり、一般的には英数字による
文字列で代表される。

【００３１】次に本発明における各サーバ構成がどのよ
うに実現されるか図６と図７を用いて説明する。

【００３２】図６はウェルノウンノードにおけるシステ
ム開始処理である。ウェルノウンノードは前述のように
本システムに参加する全てのノードがそのノードアドレ
スを保持する。ネームサーバ３１５並びに構成情報サー
バ３１６を起動（６０１）する。次に構成情報サーバが
ウェルノウンノード上の二次記憶装置上に記録されてい
る構成情報３１７を読み込む。（６０２）処理要求受信６０３は各ノードからの開始要求並びに各
サーバからの開始完了要求を待つ。要求が各ノードから
送信されてくるまでウェルノウンノードは待ち状態とな
る。

【００３３】ノード開始が任意のノードから送信される
とノード開始か否かの判定(６０７)後、そのノードが取
るべき構成情報を前記で読み込んだ構成情報から取得
し、要求ノードへそのノード構成情報を送信（６０８）
する。

【００３４】次に処理要求受信６０３においてサーバ開
始要求が送信された場合(６０４)、送信されたデータ中
にサーバ識別子とノードアドレス，プロセス番号が転送
されるので、それをプロセス−サーバ対応表３１６の各
項目に設定する。

【００３５】もし全てのサーバの登録が完了したならば
（６０６）、システム開始が完了する。完了しない場
合、次の処理要求を受信する。

【００３６】処理要求受信６０３でその他の処理が受信
された場合（６０４でｎｏの場合）はその他の処理を行
う。

【００３７】システム開始完了後、ウェルノウンノード
上では処理要求受信６１０が行われ、処理要求がサーバ
識別子変換要求（６１１）の場合、プロセス−サーバ対
応表を参照し、要求されたサーバ識別子に対応するノー
ドアドレス，プロセス番号を要求元サーバへ送信する。
処理要求が完了の場合（６１３）ならば終了し、その他
の場合（６１３でｎｏ）の場合、処理要求に対応した処
理を行う（６１４）。

【００３８】次に図７を用いてウェルノウンノード以外
の一般ノード開始処理について説明する。

【００３９】一般ノード開始処理７００は該当するノー
ドが起動した時点でＯＳ等により開始される。最初に初
期プロセスが起動（７０１）され、ウェルノウンノード
に対して自分自身のノード構成情報取得要求を送信（７
０２）する。この登録要求はウェルノウンノード開始時
のノード開始処理６０７，６０８に対応し、その結果、
一般ノードは自分自身の構成情報つまりどのタイプのサ
ーバをどのような構成で起動するかについての情報を受
信し、ノード構成情報として保持（７０３）する。次に
構成情報中に指定された全サーバについて構成情報に基
づいて対応するサーバ起動（７０５）する。この起動時
にプロセス番号がＯＳから付与される。サーバ起動後、
ノードアドレスとそのサーバのプロセス番号並びにサー
バ識別子をウェルノウンノードのネームサーバへ送信
（７０６）する。これを各ノードのサーバ構成情報で指
定されているノード数分行う（７０４，７０８）。

【００４０】図６，図７の処理によりプロセス−サーバ
対応表３１６が完成される。各ノードが構成情報の関連
サーバと通信したい場合、サーバ識別子を指定して相手
サーバに対するデータのsend処理を行う。send処理では
一度ネームサーバに対してサーバ識別子を送り、ネーム
サーバはそれに対応するノードアドレスとプロセス番号
の対を返す。Xbus通信はノードアドレスとプロセス番号
の対の情報を元にXbus上で通信を行う。この対は各サー
バまたはノード上にキャッシュされていてもよい。この
方法で起動されたサーバは各ＡＰまたは任意のサーバか
らの要求を待つ。尚、ＦＥＳ並びにＢＥＳはシステム開
始時において後述するトランザクション管理表を作成す
る。

【００４１】図８から図１６を用いて本システム構成に
より起動されたデータベース管理の概要について述べ
る。

【００４２】図８にＢＥＳ，ＦＥＳが保持するトランザ
クション管理表３１２を示す。トランザクション管理表
はトランザクション情報８０１と関連ＢＥＳリストへの
ポインタ８０４とＢＥＳリスト８０５からなる。トラン
ザクション情報は各ＡＰが発生するトランザクションに
関する情報、詳細には対応するＡＰの位置情報やトラン
ザクション状態情報等を保持する。ＢＥＳリスト８０５
は、ＡＰが発生したトランザクション処理中にデータベ
ースアクセス要求したＢＥＳのリストを保持する。

【００４３】次に図９，図１０を用いてＡＰの処理につ
いて述べる。ＡＰ（９０１）はＡＰ開始要求をＡＰに付
加された処理部に対して要求する。ＡＰ開始９１０はＡ
Ｐ構成情報で指定されたＦＥＳ識別子のノードアドレス
とプロセス番号，ウェルノウンノード上のネームサーバ
から取得（９１１）する。次にその任意のＦＥＳに対し
てＡＰ開始要求を送信（９１２）した後、開始完了を受
信し、処理を完了する。つぎにＡＰはデータ操作言語
（以後ＤＭＬと略す。）によるデータベース操作要求、
即ち、ＤＭＬ要求９０３を行う。ＡＰ開始同様にＤＭＬ
処理はＡＰに付加された処理部へ渡される。ＤＭＬ処理
（９０３）は要求されたＤＭＬをＡＰ開始時点で決定し
たＦＥＳへ送信（1001）する。次にＦＥＳからの結果を
受信（１００２）しＤＭＬ処理を完了する。

【００４４】ＡＰは複数のＤＭＬを処理後、コミット要
求（９０４）を要求する。コミット要求９０４は前述の
ＦＥＳへコミット要求を送信（１０１１）し、処理完了
を受信（１０１２）し完了する。コミット要求を行った
ＡＰはＡＰ終了要求を行う。ＡＰ終了要求９０５はＦＥ
Ｓへ終了を送信（１０２１）した後、処理完了を受信
（１０２２）し、完了する。ＡＰは以上のような処理過
程を経て、データベースに関する処理が行える。

【００４５】次にＦＥＳの処理概要を図１１から１３を
用いて述べる。

【００４６】図１１はＦＥＳ処理概要を示す。ＡＰから
の処理要求を受信（１１０１）し、その処理を行う。Ａ
Ｐからの処理要求がＡＰ開始（１１０２）であれば対応
ＡＰ初期化処理（１１１１）を行う。ＡＰからの処理要
求がＤＭＬ要求であれば（１１０３）、ＤＭＬ処理（１
１１２）を行い、ＡＰからの処理要求がコミット要求で
あればコミット処理（１１１３）を行う。ＡＰからの処
理要求がＡＰ終了要求であればＡＰ終了処理（１１０
５）を行う。その他の要求の場合、ＦＥＳ終了としてFE
Sを完了する。

【００４７】次に図１２を用いてＤＭＬ処理の概要を説
明する。ＤＭＬ処理（１１０２）はＦＥＳ要求受信時に
受信したＤＭＬを解析（1201）し、そのＤＭＬが操作対
象とするデータベースに関する定義情報を、本ＦＥＳの
構成情報で指定されたＤＤＳから取得（１２０２）す
る。ここでＤＤＳ中のデータベース定義中にはＤＭＬに
指定されたＤＢがどのＢＥＳに格納されているかの情報
が保持されている。取得した定義情報から処理対象ＢＥ
Ｓを決定後、トランザクション表に決定したＢＥＳが存
在するか否かの判断後、存在しなければBESリストへ登
録（１２０３）する。次に、受信したＤＭＬを各ＢＥＳ
毎のＢＥＳ対応ＤＭＬに分割（１２０４）した後、各Ｂ
ＥＳへ分割したＢＥＳ対応ＤＭＬを実行要求（１２１
１，１２０６，１２１２，１２０５）する。

【００４８】その後、各ＢＥＳからの処理要求を受信
（１２０７，１２０８，１２１３，１２０９）した後、
その処理結果をＡＰへ送信（１２１０）する。

【００４９】次に、図１３を用いてＦＥＳにおけるコミ
ット処理の概要を示す。コミット処理（１１０７）はＤ
ＭＬ処理によって行われたデータベース操作を実際にデ
ータベースへ反映させる処理である。

【００５０】コミット要求を発行したＡＰが関連したＢ
ＥＳに対して、即ち、トランザクション表に登録されて
いるＢＥＳリスト上の全ＢＥＳに対してコミット準備要
求を送信（１３０１，１３０２，１３１５，１３０３）
する。次に送信したＢＥＳからの処理要求を受信（１３
０４，１３０５，１３０６，１３１６）する。全てのコ
ミット準備処理が正常ならば、コミット準備完了ジャー
ナルを、本ＦＥＳ構成情報に指定されたＪＳへ記録要求
（１３０７）する。

【００５１】次にコミット準備要求同様、関連ＢＥＳへ
コミット要求を送信（１３０８，１３１０）する。コミ
ット要求に対する結果を受信（１３１１から１３１３）
した後、コミット完了ジャーナルを本ＦＥＳ構成情報に
指定されたＪＳに対して記録（１３１４）した後、コミ
ット処理が完了する。

【００５２】次にＢＥＳの処理概要について説明する。

【００５３】ＢＥＳはデータベースに対するアクセス要
求を実行する。ＢＥＳはＦＥＳからの各要求を受信した
後、その要求に対応する処理を実行する。

【００５４】要求がＢＥＳ対応ＤＭＬ実行要求の場合
（１４０２）、ＢＥＳ対応ＤＭＬを実行しデータベース
に対する操作を行う。もしＢＥＳ対応ＤＭＬがデータベ
ースに対して更新を行った場合（１４１１）、変更前後
情報を本ＢＥＳ構成情報に指定されたＪＳに記録要求す
る。ＢＥＳ対応ＤＭＬの実行結果を要求元、即ち、ＦＥ
Ｓへ送信（１４１３）してＢＥＳ対応ＤＭＬ処理が完了
する。

【００５５】要求がコミット準備要求ならば（１４０
３）コミット準備ジャーナルを本BES構成情報に指定さ
れたＪＳへ記録する。要求がコミット要求ならば(１４
０６)、コミットジャーナルを本ＢＥＳ構成情報に指定
されたＪＳへ記録する。ＢＥＳ完了要求の場合（１４０
５）、ＢＥＳを完了する。その他の処理の場合（１４０
５でｎｏ）、その他の処理を行う。

【００５６】つぎに図１５を用いて辞書サーバの処理に
ついて述べる。他のサーバと同様の処理要求を受信（１
５０１）する。処理要求が定義情報取得ならば(１５０
２)、要求された定義情報をＤＤから検索，取得（１５
１０）し、その結果を要求元サーバへ転送する。

【００５７】ＤＤＳ完了要求の場合、ＤＤＳは完了す
る。その他の処理の場合、その他の処理を行う。

【００５８】次に、図１６を用いてＪＳの処理について
述べる。処理要求を受信（１６０１）する。処理要求が
ＪＳ記録要求であれば、ジャーナル記録処理（１６１
０）を行い、要求元へ処理結果を送信（１６１１）す
る。

【００５９】ＪＳ完了要求の場合（１６０３）、ＪＳは
完了し、その他の処理要求の場合、その他の処理（１６
０４）を行う。

【００６０】

【発明の効果】

（１）負荷に応じたサーバの構成変更データベース管理システムを上記処理部に分割すること
で、各処理部が管理する資源毎の負荷分散を可能とす
る。即ち、フロントエンドサーバであればＡＰ、バック
エンドサーバであればデータベース、ジャーナルサーバ
であればジャーナル、辞書サーバであれば辞書という単
位毎に分割を可能とする。ある処理装置上でジャーナル
サーバとデータベースサーバが運用されている場合に、
処理ネックになった場合には新たな処理装置を導入し、
いずれかのサーバを移動することで処理ネックの解消を
図ることが容易となる。

【００６１】（２）資源の運用方法の簡便化各処理部を独立したことにより、ある特定の処理装置群
に特定の資源を割り付けることで各資源に対する運用が
簡便となる。例えばジャーナル専用処理装置を特定の地
域に集中させることで、オペレータなどの人的資源の重
複を排除できる。

【００６２】（３）冗長な資源量の削減従来のシステムでは各ノード毎にデータベース管理シス
テムに必要な資源を必要とした。例えばデータベース管
理システム自身のオブジェクトコード，構成に必要なパ
ラメタ情報やデータベース，ジャーナル，辞書等の各資
源（二次記憶装置）等である。本発明により処理部分割
をすることで、その処理部に必要な資源のみを各処理装
置上に割り付ければよく、冗長な資源を排除することが
可能になる。

【図面の簡単な説明】

【図１】データベース管理システムのブロック図。

【図２】従来データベース管理システムのブロック図。

【図３】詳細なデータベース管理システムのブロック
図。

【図４】構成情報の説明図。

【図５】プロセス−サーバ対応表の説明図。

【図６】ウェルノウンノードシステム開始のフローチャ
ート。

【図７】一般ノードのシステム開始のフローチャート。

【図８】トランザクション表の説明図。

【図９】ＡＰ並びにＡＰ開始処理のフローチャート。

【図１０】ＤＭＬ処理並びにコミット処理，ＡＰ終了要
求のフローチャート。

【図１１】フロントエンドサーバ処理のフローチャー
ト。

【図１２】ＤＭＬ処理のフローチャート。

【図１３】コミット処理のフローチャート。

【図１４】バックエンドサーバ処理のフローチャート。

【図１５】辞書サーバ処理のフローチャート。

【図１６】ジャーナルサーバ処理のフローチャート。

【符号の説明】

１０１…バックエンドサーバ、１０２…データベース、
１０３…フロントエンドサーバ、１０４…アプリケーシ
ョンプログラム、１０５…辞書サーバ、１０６…辞書、
１０７…ジャーナルサーバ、１０８…ジャーナル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者土田正士神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内

Claims

【特許請求の範囲】

【請求項１】通信ネットワークで接続された複数の処理
装置上で、データベースをアクセスするバックエンド処
理部，ジャーナルをアクセスするジャーナル処理部，デ
ータベース定義情報をアクセスする辞書処理部，アプリ
ケーションプログラムからの要求を受けて上記各処理部
に処理を依頼するフロントエンド処理部のいずれかを上
記複数の処理装置のいずれかに配置し、その配置に基づ
いてデータベース処理を行うことを特徴とするデータベ
ース管理方法。
【請求項２】請求項１において、上記各処理部の配置指
示を任意の処理装置上に保持し、その配置情報に基づい
て各処理部を配置指示するデータベース管理方法。
【請求項３】請求項２において、アプリケーションプロ
グラムが任意のフロントエンド処理部を選択し、上記フ
ロントエンド処理部は上記フロントエンド処理部の構成
情報に指示された辞書処理部を選択し、上記フロントエ
ンド処理部は上記辞書処理部の保持する辞書情報からバ
ックエンド処理部を選択し、上記フロントエンド処理部
および上記バックエンド処理部はその構成情報に指示さ
れた上記ジャーナル処理部を選択し、上記選択した各処
理部を用いてデータベース処理を行うデータベース管理
方法。