JP2837525B2 - 導出データベース処理方式 - Google Patents

Description

【発明の詳細な説明】 〔概要〕 複数のデータベースが独立して存在するデータベース
処理装置における導出データベース処理方式に関し， 複数のデータベースをアクセスする応用プログラム動
作を，あたかも１つのデータベースに対する運用の形態
で簡易に実現する手段を提供することを目的とし， データベースの定義情報を記憶するディクショナリ
と，導出データベースに対応させるデータベースの選択
情報，選択したデータベースの構成要素に関する選択情
報等をディクショナリに登録する導出データベース登録
手段と，操作対象が導出データベースである場合に，デ
ィクショナリを参照し，必要なデータベースの構成要素
を選択するとともに，別名の置き換えを行うディクショ
ナリ情報操作手段と，複数のデータベースの格納要素を
部分的に集めたものに対するデータベース処理手順を作
成するデータベース処理手順作成手段とを備えるように
構成する。

〔産業上の利用分野〕

本発明は，ある目的でまとまったデータを複数の利用
者から同時に共用するデータベースが複数独立して存在
するデータベース処理装置における導出データベース処
理方式に関する。

データベース管理システムに対する要求が高度化する
傾向にあり，拡張性，柔軟性に富むデータベースの運用
形態を実現する技術が必要とされている。

〔従来の技術〕

例えば，データベース用の計算機言語として知られて
いるSQL言語の標準規格（例えば，データベース言語SQL
JISX3005−1990）では，データベースが１つの環境中
で複数のスキーマによって定義されるすべてのデータの
集まりと定義されている。したがって,1つの応用プログ
ラムは１つのデータベースをアクセスすることになる。

しかしながら，実現のデータベースの利用形態（環
境）では,SQL規格のようなデータベースの概念の枠だけ
では無理が多い。すなわち，現実的な要請から，以下の
ような複数のデータベース間にわたる処理が求められる
場合がある。

独立に開発されたデータベース間 部門データベースと中央データベース間 同じスキーマ構造を持つ独立運用のデータベース間 個人データベースと共用データベース間 テスト用のデータと実運用データベース間 従来，このような複数のデータベースをアクセスする
運用形態では，適宜，状況に依存した解決策が採られて
きたのが実情である。

例えば，独立に開発された部門ごとのデータベースに
ついて，複数のデータベース上のデータをアクセスする
ような場合，従来方式では，次のような方法が用いられ
ている。

第１は，定義したスキーマを１つのデータベースに統
合して再構築する方法である。これによって応用プログ
ラムは，データを共用する。

第２は，定義したスキーマを部門ごとに独立したデー
タベースにする方法である。応用プログラムは部門ごと
に作成し，複数のデータベース間の応用プログラム間の
連携は，一般のファイルを経由してデータの受渡し処理
を行う。

以上の対処は，データベースの構築または応用プログ
ラムの開発に多大な負担をかけることになった。

すなわち，データベース化の目的は，データの共用，
データの冗長性，データ相互間の意味的な矛盾を解決す
ることである。したがって，定義したスキーマを１つの
データベースにまとめる方式が原則的に考えられる。し
かしながら，組織ごとの業務上の独立の程度や開発期間
・開発量で段階的にデータベースを分割開発せざるを得
ないのが現状であり，すべてのデータを１つのデータベ
ースにまとめることは，現実的に妥当でないことが多く
ある。

〔発明が解決しようとする課題〕

従来技術では,1つの応用プログラムからは同時に１つ
のデータベースしか扱えなかった。複数のデータベース
を同時に扱えないことから，次のような問題があった。

独立開発されたデータベース間では，データベース
間のテーブルの相互参照，データ移動，データ更新を，
同時に同じ応用プログラムから扱えない。

部門データベースと中央データベース間では，部門
間調整がきわめて困難である。

同じスキーマ構造を持つ独立運用データベース間で
は，複数データベースに分散された同一定義のテーブル
に含まれるデータを,1つの応用プログラムで扱えない。

個人用と共用データベース間においても,1つの応用
プログラムから同時に扱うことができないため，操作性
に悪影響を及ぼす。

テスト用のデータと実運用データベース間で，テス
ト用のデータをデータベースとし，実運用データベース
と混在させた形で，実運用データベースを利用したテス
トを実施することができない。

また，現実的に複数のデータベースを扱うことができ
るようにしようとすると，複数のデータベース間で重複
した名標が現れないようにしなければならないため，開
発段階から，他のデータベースにおける名標の使用に注
意を払わなければならず，個々とデータベースを独立に
開発することができなくなるという問題がある。

本発明は上記問題点の解決を図り，複数のデータベー
スをアクセスする応用プログラム動作を，あたかも１つ
のデータベースに対する運用の形態で簡易に実現する手
段を提供することを目的としている。

〔課題を解決するための手段〕

第１図は本発明の原理説明図である。

第１図において,1はCPUおよびメモリなどからなる処
理装置,10はデータベース定義文を解釈し登録するデー
タベース定義部,11は導出データベース登録部,12はデー
タベースに対するアクセス要求などを処理するデータベ
ース操作部,13はディクショナリ情報操作部,14は導出デ
ータベース解釈部,15はデータベースおよび導出データ
ベースの定義情報を記憶するディクショナリ,16はデー
タベース格納装置,17A,17Bはデータベース,18は導出デ
ータベース,19はデータベース処理手順作成部を表す。

データベース17A,17Bは，独立したデータベースであ
る。本発明では，これらのデータベースの構成要素を部
分的に集めたものを，導出データベース18として定義す
ることできるようになっている。

導出データベース18は，構文規則上の解釈では，デー
タベースに含まれているデータを定義するスキーマ定義
で扱う名標の定義範囲を崩さずに，“導出データベー
ス”という新たな枠で名標を定義するものであり，意味
規則上の解釈では，選択したテーブルに関連するスキー
マ定義でいう参照制約に対する処理を規定するものであ
る。

データベース定義部10の導出データベース登録部11
は，そのような導出データベース18の定義文を入力し，
その定義情報をディクショナリ15に登録する処理を行
う。

ディクショナリ15は，このデータベースを作るための
スキーマ定義および二次記憶上のデータベース格納装置
についての情報を一括管理する格納装置である。ディク
ショナリ15自体も１つのデータベースとして構築でき
る。

ディクショナリ15に登録する定義情報には，例えば導
出データベース18に対応させるデータベースの選択情
報，選択したデータベースの構成要素に関する選択情報
およびデータベースで扱う名標を，必要に応じて別名に
する別名指定情報などが含まれる。

データベース17A,17Bまたは導出データベース18に対
するアクセス要求があると，データベース操作部12は，
そのアクセス要求を処理するアクセススケジュールを生
成する。

ここで，ディクショナリ情報操作部13は，操作対象が
導出データベース18である場合に，ディクショナリ15を
参照し，導出データベース解釈部14によって，必要なデ
ータベース定義の論理・格納構成要素を選択するととも
に，別名指定があれば，その別名を本来の名標に置き換
える処理を行う。また，データベース処理手順作成部19
は，データベースのアクセス経路を具体的に決定する最
適化処理を行うバインド処理において，ディクショナリ
15に登録した導出データベースに関する情報に基づいて
複数のデータベースの格納要素を部分的に集めたものに
対するデータベース処理手順を作成する。

これにより，導出データベース18が，データベース処
理手順を通して，あたかも実体がある１つのデータベー
スであるかのように，応用プログラムに対して提示され
る。

〔作用〕

本発明の基本的なアイデアは，リレーショナルデータ
ベースのテーブルに対するビュー（view）の関係と同じ
く，データベースに対するデータベースのビューの考え
方を，複数のデータベース上に導入したことである。

例えば，データベース17Aが，テーブルTA1,TA2,TA3か
ら構成されるとする。また，データベース17Bが，テー
ブルTB1,TB2,TB3から構成されるとする。

これらのデータベースにおいて,1つの応用プログラム
がテーブルTA1,TB1,TB2に同時にアクセスする運用が必
要にあなった場合，導出データベース（Ｃ）18として，
データベース17Aとデータベース17Bおよびその構成要素
であるテーブルTA1,TB1,TB2を指定する導出データベー
ス18の定義を，導出データベース登録部11を通して登録
する。この定義では，導出データベース18で扱うテーブ
ル等の名標に，元の名標とは異なる名標を与えることを
許す。これにより，もしデータベース17Aにおけるテー
ブル等の名標とデータベース17Bにおけるテーブル等の
名標とが重複するような場合にも，一方に別名を与える
ことによって，名標の衝突を回避できるようにする。

データベース操作部12において，操作対象が導出デー
タベース18であることがわかると，ディクショナリ15の
登録情報に従って，導出データベース18に対応づけられ
ている構成要素であるデータ実体に関する格納構造など
のアクセス情報への変換を行うので，応用プログラムか
ら見ると，導出データベース18が１つの実体のあるデー
タベースのように見えることになり，複数のデータベー
ス17A,17Bに対しての統一的な処理を行うことができる
ようになる。

〔実施例〕

最初に，本発明に係る導出データベースの概念を明確
にするために，現実的に避けられない複数データベース
に運用に対して，導出データベースという統一的な考え
方による解決手段を，現実的な運用形態と対比しながら
説明する。

（１） 独立に開発されたデータベース間 部門ごとにデータベースが独立している運用形態があ
る。独立とは，データベース設計，応用プログラム開
発，データベース管理，および実行が部門ごとに行われ
ることをいう。

このような運用形態でも，他部門のデータベースにわ
たってデータをアクセスしたい場合がある。

従来方式では，このような場合，定義したスキーマを
１つのデータベースに統合し，これによって応用プログ
ラムがデータを共用する方法，または定義したスキーマ
を部門ごとのデータベースとし，応用プログラムは部門
ごとに作成して，一般のファイルを経由することによ
り，データを受渡し処理を行う方法などが採られてい
た。

これに対して，導出データベースでは，次のようなア
プローチを採ることができる。

ｉ）独立する部門間では，データベース設計が無関係に
行われるため，同一のスキーマ名，テーブル名が存在し
ても，相互に名前を修正することは極めて困難であるこ
とが多い。導出データベースでは，新たな名前を指定す
ることで，前述の同一名の衝突を，導出データベースの
定義を通して回避する手段を提供できる。

ii）他部門に対しては，必要なテーブルだけをアクセス
させたい場合が多い。これに対し，導出データベースで
は，複数のデータベースから必要なテーブルを選択する
ことができる。

第２図は，独立に開発されたデータベースと，導出デ
ータベースの定義例を示している。

勘定系と債権取引系を持つ銀行業務では，第２図に示
すように,2つのデータベースで運用することがある。こ
の場合でも，債権取引の応用プログラムが勘定系データ
ベースにおける口座テーブルの残高照会をしたり，債権
取引系データベースの取引明細テーブルの内容を使って
口座テーブルを更新したりすることが必要になる。

本実施例では，勘定系データベースの口座テーブル
と，債権取引系データベースとから，受渡し導出データ
ベースを定義する。応用プログラムは，この導出データ
ベースを通して，複数のデータベースにわたるアクセス
ができるようになる。

（２） 部門データベースと中央データベース間 中央データベースの他に，各部門データベースを独立
に持つ運用形態がある。中央データベースとは，集中的
に管理されたデータベースをいう。部門データベース
は，中央データベースと比較すると，局所データであ
り，各部門ごとに管理されてデータベース数も多い。

このような運用形態でも同時に部門と中央データベー
スをアクセスしたい場合がある。同時アクセスには,3通
りの運用形態がある。１つは，中央データベースから部
門データベースにデータを取り出して，編集や加工処理
をする形態である。２つ目は，部門データベースのデー
タを中央データベースに格納する形態である。３つ目
は，部門間同士の複数データベースを同時に扱う場合で
ある。

導出データベースでは，中央データベースと部門デー
タベース間の同時アクセスについても，前述の（１）と
同様に対応することができる。特に，部門ごとのデータ
ベース間を同時に扱う場合には，名標の衝突をあらかじ
め回避することは，部門の独立性から調整は困難であ
る。

第３図は，部門データベースと中央データベースの例
を示している。

例えば第３図に示すように，卸売業に関して，大まか
な論理構造である共通データ，メーカ，卸，小売の関係
を，中央データベースd1と部門データベースd2に対応づ
けることができる。共通データ，メーカ，卸，小売をそ
れぞれデータベースとすれば，中央・部門データベース
の関係は，共通とメーカ，共通と卸，共通と小売間の関
係に相当する。部門間では，メーカと卸，卸と小売の関
係とすることができる。

共通データのデータベースのスキーマで，他のデータ
ベースに関連する情報には，この例では，メーカ情報，
メーカ商品属性情報，卸店台帳，小売店台帳，消費者情
報（家計簿調査，人工動態，各種統計）がある。

メーカデータベースのスキーマのテーブル定義で，他
のデータベースに関連する情報には，メーカ社内実績，
予算計画表がある。

卸データベースのスキーマのテーブル定義で，他のデ
ータベースに関連する情報には，販売実績がある。

小売データベースのスキーマのテーブル定義で，他の
データベースに関連する情報には,POSデータ，発注デー
タがある。

部門間データベースのデータ共用には，メーカ部門が
商品別の情報を加工し，卸部門が商品別，メーカ別，
卸，小売の情報を加工し，小売部門が小売の情報を加工
する。

例えば，卸部門が自社で扱うメーカの商品別分析をす
るためには，商品分析導出データベースとして，中央デ
ータベースからメーカ情報とメーカ商品属性情報を，メ
ーカデータベースから実績情報と予算情報を，卸データ
ベースから販売実績を選択して，導出データベースの定
義を行う。

中央と部門データベース間では，メーカ部門，卸部
門，小売部門が消費者情報や商品情報，各種分析情報を
得るためのデータ共用がある。

例えば，中央データベースに情報を蓄積する場合に
は，部門データベースの情報を参照するため，導出デー
タベースを定義する。逆に，部門データベースから分析
情報を得るためには，中央データベースの分析情報を参
照することもある。

（３） 同じスキーマ構造を持つ独立運用のデータベー
ス間 データベース設計，応用プログラム開発，およびデー
タベース管理が集中して，部門ごとにデータベースが独
立している運用形態がある。

このような運用形態でも，応用プログラムが複数のデ
ータベースをアクセスする場合に，同一名を持つテーブ
ルのデータを集約することがある。

従来方式では，応用プログラムがデータベースごとに
独立してデータを抽出して，後でデータをマージしてい
た。

導出データベースでは，前述の（１）と同様に対応で
きるため，複数のデータベースに対して個別に処理しな
くてもよい。

第４図は，同じスキーマ構造を持つ独立運用データベ
ースの例を示している。

企業内データベースにおいて，スキーマ定義が同型で
あっても，データが独立管理される場合がある。第４図
に示す例では，販売データベースを各地域に分けて運用
している。主な情報は，売上情報，得意先情報からな
る。通常は，各地域ごとのデータベースを扱っている
が，全体売上を求める場合には，複数のデータベースを
同時にアクセスすることが必要になる。このような販売
データベース群の必要なテーブルやカラム等に，導出デ
ータベースを定義することにより，この要求に容易に対
応できるようになる。

（４） 個人データベースと共用データベース間 個人データベースと，個人作業に必要なデータを蓄え
ている共用データベースという関係では,2通りの運用形
態がある。１つは，共用データベースから個人データベ
ースにデータを取り出して，編集や加工処理をする形態
である。もう１つは，個人データベースの処理をするた
めに，共用データベースを参照する形態である。後者
は，前述の（２）と同じ形態である。

こうした問題に対して，従来方式では，まず共用デー
タベースからデータを取り出して，個人データベースで
編集や加工処理を行い，共用データベースへ戻す処理手
順を踏む必要がある。

導出データベースでは，同時に複数データベースをア
クセスできることによって，処理手順が単純になる。

第５図は，個人データベースと共用データベースの例
を示している。

個人データベースには，個人の担当顧客情報があり，
共用データベースには，一般顧客情報や商品情報などが
ある。地域別商品売上情報を参照したり，見積もり書作
成のために，新しい商品情報を個人データベースに取り
出したりする場合や，個人データベースの担当顧客情報
を，共用データベースの一般顧客情報に反映させたりす
る場合，個人データベースと共用データベース間とのデ
ータ交換が必要になる。このようなデータ連携を，導出
データベースを使用することにより，簡単に実現するこ
とができる。

（５） テスト用のデータと実運用データベース間 テストシステムでは，実運用データベースとテストデ
ータベースを同時に使ってテストすると言う形態があ
る。例えば，オンラインシステム運用中に新たな応用プ
ログラムを開発する場合などである。

従来方式では,2通りの方法が考えられる。１つは，同
一規模のテスト用のデータベースを別に作成する方法で
ある。この方法は，最大２倍の資源量が必要になる。も
う１つは，実運用データベースにテスト用のテーブルを
別名で追加して，応用プログラムを別名でテストし，テ
スト後の元の名前に書き戻す方法である。

導出データベースでは，実運用データベースとは別
に，被テストプログラムが更新するテーブルをテスト用
のデータベースに作成して，応用プログラムの変更なし
に，両方のデータベースを同時に扱うことが可能にな
る。

第６図は，そのテストデータベースの例を示してい
る。

第６図に示すように，メーカ情報，卸店台帳，小売店
台帳等からなる実運用データベースにより運用している
ときに，新しいメーカ情報についてテストしたい場合，
卸店台帳，小売店台帳については参照しか行わないとす
ると，導出データベース18として，テストデータベース
のメーカ情報と，実運用データベースの卸店台帳，小売
店台帳を含むうように定義することにより，その導出デ
ータベース18を使用して，メーカ情報のテストを簡単に
行うことができる。

以上のように導出データベースを用いることにより，
各種の運用形態に対して，柔軟に対応できるようにな
る。

導出データベースは，テーブルに対するビューの開発
と同様に，データベースに対する，いわばデータベース
レベルのビューであるといえる。

第７図に示すように，従来技術では，応用プログラム
30Aはデータベース17Aに，応用プログラム30Bはデータ
ベース17Bにというように，各々１つのデータベースに
アクセスできるだけであった。

導出データベースでは，さらに，応用プログラム30C
のように，複数のデータベース17A,17Bの必要な部分を
導出データベース18として，同時にアクセスすることが
できる。

このとき，複数のデータベース間に同一のテーブル名
Ｔが存在する場合には，別名T1というようにテーブル名
を変更することで，テーブルを一意に識別することを可
能にする。

第８図は，本発明の一実施例にかかる導出データベー
スの登録説明図である。

データベース定義部10におけるデータベース登録部42
は，通常のデータベース定義文40を解釈し，その定義情
報をディクショナリ15に登録する。また，導出データベ
ース登録部11は，導出データベース定義文41を解釈し，
その定義情報をディクショナリ15に登録する。

データベース定義文40および導出データベース定義文
41のBNF形式は，以下の通りである。なお，本実施例で
は，論理構造と格納構造とを切り離し，論理構造表現の
データ単位（テーブルまたはその一部）の１つを，複数
の格納上の管理単位に対応づけて格納するために，物理
媒体上で独立構造を有するデータベースの基本的な構成
要素として，格納構成単位（CS:Composite Structure）
という管理単位を使用している。CSは，ヒープ,B⁺木，
ハッシュなどの基本データ編成の組み合わせから作成し
た格納構造であり，他の定義情報によって,1つのスキー
マの１つのテーブル，複数のテーブルまたはテーブル内
の特定のカラム等に対応付けられるようになっている。
言うまでもなく，このようなCSの概念を用いなくても，
本発明を実施することは可能である。

［データベース定義文の記述形式］ ＜データベース定義＞::＝CREATE DB＜データベース名
［FROM ＜cs指定＞］ ＜データベース名＞::＝＜識別子＞ ＜cs指定＞::＝＜cs名＞［｛，＜cs名＞｝...］ ［構文規則］ ＜cs名＞で指定された各CSのCS定義における＜データ
ベース名＞は，＜データベース定義＞の中の＜データベ
ース名＞と一致していなければならない。

［意味規則］ ＜cs指定＞の中の＜cs名＞で指定された各CSからデー
タベースを構成する。このデータベースは，＜データベ
ース名＞で名前づけられる。＜cs指定＞を省略するなら
ば,CS定義中のデータベース指定で当該＜データベース
名＞を指定するCSが構成要素となる。

［導出データベース定義文の記述形式］ ＜導出データベース定義＞::＝CREATE VDB＜導出データ
ベース名＞FROM＜要素BD指定＞［WHERE＜置換リスト
＞］ ＜導出データベース名＞::＝＜識別子＞ ＜要素DB指定＞::＝＜データベース名＞［＜csリスト
＞］［｛，＜データベース名＞［＜csリスト
＞］｝...］ ＜CSリスト＞::＝（＜cs名＞［｛，＜cs名＞｝...］） ＜置換リスト＞::＝＜置換要素＞［｛，＜置換要素
＞｝...］） ＜置換要素＞::＝＜スキーマ名１＞AS＜スキーマ名２＞
ON＜データベース名＞｜＜テーブル名１＞AS＜テーブル
名２＞ON＜データベース名＞ ［構文規則］ １）＜要素DB指定＞中の＜データベース名＞で指定され
るデータベースは，＜データベース定義＞または＜導出
データベース定義＞で定義されていなければならない。

２）＜CSリスト＞で指定される各CSは，当該＜CSリスト
＞の直前にある＜データベース名＞で指定されるデータ
ベースの＜データベース定義＞または＜導出データベー
ス定義＞中に，陽にまたは暗に指定されていなければな
らない。

３） ＜置換要素＞中の＜スキーマ名１＞または＜テー
ブル名１＞で指定されるスキーマまたはテーブルは，＜
データベース名＞で指定されるデータベースの内包でな
ければならない。

４） ＜置換要素＞中の＜スキーマ名２＞または＜テー
ブル名２＞は，＜導出データベース定義＞中で一意でな
ければならない。

［意味規則］ １） ＜要素DB指定＞の中の＜データベース名＞で指定
したデータベースから＜CSリスト＞中の＜CS名＞で指定
したCSを抽出したデータベースを構成する。このデータ
ベースは，＜導出データベース名＞で名前づけられる。
＜CSリスト＞を省略するならば，指定されたデータベー
スのすべてのCSが指定されたと解釈する。

２） ＜置換要素＞中の＜データベース名＞で指定され
たデータベース上で，＜スキーマ名１＞で指定されたス
キーマ（これは当該データベースの内包である）の識別
子を＜スキーマ名２＞に置き換える。

同様に，＜置換要素＞中の＜データベース名＞で指定
されたデータベース上で，＜テーブル名１＞で指定され
たテーブル（これは当該データベースの内包である）の
識別子を＜テーブル名２＞に置き換える。

３） ＜置換リスト＞に指定されないスキーマまたはテ
ーブルについては，識別子の置き換えは行わない。

このような仕様によるデータベース定義文40または導
出データベース定義文41の入力により，ディクショナリ
15には，次のような情報が格納される。

ａ） データベース識別子などのデータベース情報 ｂ） データベースを構成する格納構成単位（CS）を識
別するCS識別子などの情報 ｃ） 導出データベース識別子と選択するデータベース
識別子に関する情報 ｄ） 導出データベースと選択するCSの対応関係情報 ｅ） データベース間に名前の重複がある場合など，ス
キーマ名またはテーブル名の別名と本名との対応情報 以下に部門データベースと中央データベースから商品
分析導出データベースを生成する例について，データベ
ース定義文等の具体例を挙げる。

この例では，データベース定義文は，中央データベー
ス，メーカ部門データベース，卸部門データベースの３
つがある。この定義文は，以下のように記述される。

CREATE DB 中央DB FROM（メーカ情報CS,メーカ商品属
性情報CS,…） CREATE DB メーカBD FROM（実績CS,予算CS,…） CREATE DB 卸DB FROM（販売実績CS,…） 導出データベース以外の関連情報の定義は，以下のと
おりである。

CREATE CS メーカCS TYPE B＋TREE FROM＜スキーマのテ
ーブル名＞ON DB01 ALLOCATE DB DB01＜DBエリア名＞T0 メーカ情報CS,＜D
Bエリア名＞T0 メーカ商品属性情報CS 同様に,DB02はメーカDBに割り付け,DB03は卸DBに割り
付ける。この定義文の記述については，同様であるので
具体例を省略する。

導出データベース定義文は，例えば以下のように記述
される。

CREATE VDB 商品分析VDB FROM DB01（メーカ情報CS,メーカ商品属性情報CS） DB02（実績CS,予算CS） BD03（販売実績CS） 次に，データベース操作系の構成例を，第９図に従っ
て説明する。

第９図に示すバインド制御部50の入力は，導出データ
ベース識別子またはデータベース識別子と,SQL規格のモ
ジュールである。モジュールには，スキーマ名とテーブ
ル名が記述してある。このスキーマ名，テーブル名は，
同種データベース指定の別名である場合がある。

バインド制御部50の入力は，例えば以下のような命令
である。

BIND−ｍ＜SQLのモジュールのファイル名＞ −ｎ商品分析VDB この＜SQLのモジュールのファイル名＞の中身で,SQL
文関連は，以下のように記述してある。

SELECT＊FROMメーカ情報，メーカ商品属性情報，実績予
算，販売実績 …… ここで，メーカ情報，…，販売実績は,SQLスキーマ上
のテーブル名とする。

バインド制御部50は，ディクショナリ情報操作部13内
の導出データベース解釈部14に対して，導出データベー
ス識別子またはデータベース識別子を通知する。

導出データベース解釈部14は，本バインド処理で扱う
ディクショナリ15の要素を決める。ディクショナリ要素
は，格納構造定義のCS識別子の並び，論理構造定義のス
キーマ名の並び，スキーマ内に含まれるテーブル名の並
び，スキーマ名の本名および別名，テーブル名の本名お
よび別名である。

処理内容は，以下のとおりである。

ｉ）導出データベース識別子から，データベース識別子
とCS識別子をすべて求める。

ii）CS識別子から関連する複数のテーブル名を求める。
テーブル名から関連するスキーマ名を求める。

iii）テーブル名，スキーマ名から別名を求める。

最適化処理部51は，ディクショナリ情報操作部13の論
理情報操作部53に対して，スキーマ名，テーブル名を入
力として，最適化処理のための処理情報と格納情報を取
得する。

論理情報操作部53は，導出データベース解釈部14に対
して，スキーマ名とテーブル名を入力すると,CS識別子
ともしも別名ならば本名を出力する。論理情報操作部53
は，テーブル情報から論理情報を抽出する。もしも，テ
ーブル間にSQLスキーマで定義している参照制約があれ
ば，そのテーブルの論理構造情報も抽出する。これによ
って参照制約に関連するテーブルに対して更新を行う場
合には，参照制約が保たれるように動作する。

また，論理情報操作部53は，格納情報操作部54に対し
て,CS識別子を入力することによって,CS情報以下の物理
情報までのメタ情報を抽出する。参照関係にある別テー
ブルが存在するならば，これらの格納情報を抽出する。

格納情報操作部54は，格納構造情報操作部55,CSスペ
ース情報操作部56,CSスペース・DBエリア変換部57,DBエ
リア情報管理部58からなる。

格納構造情報操作部55は,CSの要素であるデータ編成
のプリミティブの情報を管理する。CSの要素には，ヒー
プ,B⁺木，ハッシュなどの基本データ編成が含まれてく
る。

CSスペース情報操作部56は,CSに割り当てられている
スペース情報を管理する。CSスペース・DBエリア変換部
57は,CSスペースとDBエリアと呼ぶエクソテント情報の
集まりの対応を関連づける機能を持つ。DBエリア情報管
理部58は,DBエリアに属するエクステント情報を管理す
る。このエクステント情報は，物理媒体上のボリューム
情報やボリューム内のエクステント情報を含む。

格納情報操作部54は,CSに含まれる格納構造に係るデ
ータ編成を操作するプログラムを決定する。次に,CSス
ペース情報操作部56,CSスペース・DBエリア変換部57,DB
エリア情報管理部58により情報を取り出して，実際にア
クセスするボリュームのエクステント情報を決定する。

これらの結果により，最適化処理部51は，論理情報の
格納情報とに基づいて，データベースに対する処理コス
トが最良となるようなデータベース処理手順52を出力す
る。

また，次のように実施することも可能である。

1.ディクショナリ情報操作部13内の役割分担を変えても
よい。例えば，最適化処理部51から導出データベース解
釈部14を呼び出してもよいし，最適化処理部51から論理
情報操作部53を呼び出す場合に，スキーマ名，テーブル
名の他に，導出データベース識別子またはデータベース
識別子を入力してもよい。

ii.ディクショナリ15は，リレーショナルデータベース
のテーブルでもよいし，独自の制御表構造からなるディ
スクトリでもよい。

iii.ディクショナリ15上の導出データベース情報は，バ
インド時にアクセスできるデータベース上に存在すれば
よい。システムが物理的に分散している場合には，分散
データベース技術によって，重複配置や更新に伴う更新
がなされればよい。

iv.バインドは，データベースへのアクセス実行段階の
前段階で機能してもよいし，実行段階に機能してもよ
い。

第10図は，以上のようにして作成されたデータベース
処理手順52を含む応用プログラム60に関する実行時の動
作構成例を示している。

例えばＣ言語やCOBOL言語等のホスト言語で記述され
た応用プログラム60のオブジェクトと，データベース処
理手順52とを結合する。結合方法には，リンケージエデ
ィタによる事前結合や実行時の動的結合がある。

また，応用プログラム60とデータベースアクセス部62
とを結合制御するストリング制御部61が存在する。デー
タベースアクセス部62は，データベース処理手順52によ
って決められているアクセスすべきデータ格納構造,DB
スペース情報等に従って，データベース格納装置16への
入出力を実行する。なお，第10図に示す例は一例であ
り，従来技術と同様に構成できる。

〔発明の効果〕

以上説明したように，本発明によれば，複数の独立し
たデータベースを,1つの応用プログラムからアクセスす
ることができることにより，複雑化・高度化するユーザ
運用形態に，柔軟に対処できるようになる。複数のデー
タベースを１つの応用プログラムから同時に扱えること
から，具体的には，例えば次のような効果がある。

独立開発されたデータベース間では，データベース
間のテーブルの相互参照，データ移動，データ更新を，
同じ応用プログラムから扱うことができる。

部門データベースと中央データベース間では，一般
に部門間調整がきわめて困難であるが，名標置き換え機
能によって同時に部門間データベースを１つの応用プロ
グラムから扱え，部門データベースと中央データベース
間のデータ参照，データ移動を同時に１つの応用プログ
ラムから扱うことが可能になる。

同じスキーマ構造を持つ独立運用データベース間で
は，複数データベースに分散された同一定義のテーブル
に含まれる独立運用のデータベース間のテーブルのデー
タを,1つの応用プログラムで扱うことができる。

個人用と共用データベース間では，個人のデータベ
ースと共用データベースとを１つの応用プログラムから
同時に扱うことができる。

テスト用のデータと実運用データベース間では，テ
スト用データをテスト用データベースにして，実運用デ
ータベースと混在させて１つの応用プログラムから参照
アクセスすることによって，テストで実運用データベー
スを利用することができるようになる。

また，複数のデータベースから任意のテーブルを，導
出データベースに選択できることから，導出データベー
スに選択したテーブルだけをアクセス可能とすること
で，不慮のデータ破壊を防止することができる。

さらに，データベース間で重複する名標が存在して
も，導出データベースの定義により，別名を与えること
ができるので，既存のデータベースに手を加えることな
く，応用プログラムが処理対象とするデータの範囲を，
容易に拡張していくことができるという効果がある。

【図面の簡単な説明】

第１図は本発明の原理説明図， 第２図は本発明に係る導出データベースの定義例， 第３図は部門データベースと中央データベースの例， 第４図は同じスキーマ構造を持つ独立運用データベース
の例， 第５図は個人データベースと共用データベースの例， 第６図はテストデータベースの例， 第７図は本発明に係る導出データベースの役割を説明す
る図， 第８図は本発明の一実施例による導出データベースの登
録説明図， 第９図は本発明の一実施例によるデータベース操作系の
構成例， 第10図は本発明の一実施例による実行時の動作構成例を
示す。 図中,1は処理装置,10はデータベース定義部,11は導出デ
ータベース登録部,12はデータベース操作部,13はディク
ショナリ情報操作部,14は導出データベース解釈部,15は
ディクショナリ,16はデータベース格納装置,17A,17Bは
データベース,18は導出データベース,19はデータベース
処理手順作成部,TA1〜TA3,TB1〜TB3はテーブルを表す。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 三谷 政昭 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 林 知博 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 小幡 孝司 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 関根 裕 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 浦 満広 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 石井 卓二 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (56)参考文献 特開 平１−211121（ＪＰ，Ａ) 特開 平１−154222（ＪＰ，Ａ) Ｃ．Ｊ．Ｄａｔｅ著，藤原護訳「デー タベース・システム概論」（昭59．１. 30）丸善、ｐ163−184 (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 12/00 G06F 17/30

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】ある目的でまとまったデータを複数の利用
   者から同時に共用するデータベースが複数独立して存在
   するデータベース処理装置において， 複数の独立するデータベースについての各々の論理定義
   情報および二次記憶上の格納情報を記憶する手段と， 前記複数の独立するデータベースの部分集合から導出さ
   れる仮想的な導出データベースを定義するためのデータ
   ベースの選択情報，選択したデータベースの構成要素に
   関する情報およびデータベースで扱う名標を別名にする
   別名指定情報を登録する手段と， 登録された導出データベースの定義情報を記憶する手段
   と， データベースの操作に対して，操作対象が導出データベ
   ースである場合に，前記導出データベースの定義情報を
   参照し，必要なデータベースの構成要素を選択するとと
   もに，別名指定があれば，その別名を本来の名標に置き
   換える操作手段と， 前記導出データベースの定義情報に基づいて複数のデー
   タベースの格納要素を部分的に集めたものに対するデー
   タベース処理手順を作成する手段とを備えた ことを特徴とする導出データベース処理方式。