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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔概要〕 複数のデータベースが独立して存在するデータベース処
理装置における導出データベース処理方式に関し 複数のデータベースをアクセスする応用プログラム動作
を、あたかも１つのデータベースに対する運用の形態で
簡易に実現する手段を提供することを目的とし。

データベースの定義情報を記憶するディクショナリと、
導出データベースに対応させるデータベースの選択情報
２選択したデータベースの構成要素に関する選択情報等
をディクショナリに登録する導出データベース登録手段
と、操作対象が導出データベースである場合に、ディク
ショナリを参照し、必要なデータベースの構成要素を選
択するとともに、別名の置き換えを行うディクショナリ
情報掻作手段と、複数のデータベースの格納要素を部分
的に集めたものに対するデータベース処理手順を作成す
るデータベース処理手順作成手段とを備えるように構成
する。

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

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

〔従来の技術〕

例えば、データベース用の計算機言語として知られてい
るＳＱＬ言語の標準規格（例えば、データベース言語Ｓ
　Ｑ　Ｌ　ＪｒＳＸ３００５−１９９０）では、データ
ベースが１つの環境中で複数のスキーマによって定義さ
れるすべてのデータの集まりと定義されている。したが
って、１つの応用プログラムは１つのデータベースをア
クセスすることになる。

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

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

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

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

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

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

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

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

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

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

■　部門データベースと中央データベース間では。

部門間調整がきわめて困難である。

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

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

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

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

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

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

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

第１図において、１はＣＰＵおよびメモリなどからなる
処理装置、ｌＯはデータベース定義文を解釈し登録する
データベース定義部、１１は導出データベース登録部、
１２はデータベースに対するアクセス要求などを処理す
るデータベース操作部、１３はディクショナリ情報操作
部、１４は導出データベース解釈部、１５はデータベー
スおよび導出データベースの定義情報を記憶するディク
ショナリ、１６はデータベース格納装置、１７Ａ１７Ｂ
はデータベース、１日は導出データベース１９はデータ
ベース処理手順作成部を表す。

データベース１７Ａ、１７Ｂは、独立したデタベースで
ある。本発明では、これらのデータベースの構成要素を
部分的に集めたものを、導出データベース１８として定
義することができるようになっている。

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

データベース定義部１０の導出データベース登録部１１
は、そのような導出データベース１８の定義文を入力し
、その定義情報をディクショナリ１５に登録する処理を
行う。

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

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

データベース１７Ａ、−１７Ｂまたは導出データベース
１８に対するアクセス要求があると、データベース操作
部１２は、そのアクセス要求を処理するアクセススケジ
ュールを生成する。

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

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

〔作用〕

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

例えば、データベース１τＡか、テーブルＴＡＩ　　Ｔ
Ａ２．ＴＡ３から構成されるとする。またデータベース
１７Ｂが２テーブルＴＢ１．ＴＢ２ＴＢ３から構成され
るとする。

これらのデータベースにおいて、１つの応用プログラム
がテーブルＴＡ１．ＴＢＩ、ＴＢ２に同時にアクセスす
る運用が必要になった場合５導出データヘース（Ｃ）１
Ｂとして、データベース１７Ａとデータベース１７Ｂお
よびその構成要素であるテーブルＴＡＩ、ＴＢ１．ＴＢ
２を指定する導出データベース１８の定義を、導出デー
タベース登録部１１を通して登録する。この定義では。

導出データベース１８で扱うテーブル等の名標に元の名
標とは異なる名標を与えることを許す、これにより、も
しデータベース１７Ａにおけるテーブル等の名標とデー
タベース１７Ｂにおけるテーブル等の名標とが重複する
ような場合にも、一方に別名を与えることによって１名
標の衝突を回避できるようにする。

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

〔実施例〕

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

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

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

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

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

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

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

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

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

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

（２）部門データベースと中央データヘース間中央デー
タベースの他に、各部門データへ−スを独立に持つ運用
形態がある。中央データベースとは、集中的に管理され
たデータベースをいう。

部門データベースは、中央データベースと比較すると２
局所データであり１各部門ごとに管理されてデータベー
ス数も多い。

このような運用形態でも同時に部門と中央データベース
をアクセスしたい場合がある。同時アクセスには、３通
りの運用形態がある。１つは、中央データベースから部
門データベースにデータを取り出して、Ｗ集や加工処理
をする形態である。

２つ目は１部門データベースのデータを中央データベー
スに格納する形態である。３つ目は２部門間同士の複数
データベースを同時に扱う場合である。

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

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

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

共通データのデータベースのスキーマで、他のデータベ
ースに関連する情報には、この例では。

メーカ情報、メーカ商品属性情報、卸店台帳、小売店台
帳、消費者情報（家計簿調査２人口動態。

各種統計）がある。

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

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

小売データベースのスキーマのテーブル定義で他のデー
タベースに関連する情報には、ＰＯＳデータ、発７王デ
ータがある。

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

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

中央と部門データベース間では、メーカ部門。

卸部門、小売部門が消費者情報や商品情報５各種分析情
報を得るためのデータ共用がある。

例えば、中央データベースに情報を蓄積する場合には１
部門データベースの情報を参照するため。

導出データベースを定義する。逆に１部門データベース
から分析情報を得るためには、中央データベースの分析
情報を参照することもある。

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

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

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

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

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

企業内データベースにおいて、スキーマ定義が同型であ
っても、データが独立管理される場合がある。第４図に
示す例では、販売データベースを各地域に分けて運用し
ている。主な帝報は、売上情報、得意先情報からなる。

通常は、各地域ごとのデータベースを扱っているが、全
社売上を求める場合には、複数のデータベースを同時シ
こアクセスすることが必要になる。このような販売デー
タベース群の必要なテーブルやカラム等に、導出データ
ベースを定義することにより、この要求に容易に対応で
きるようになる。

（４）個人データベースと共用データベース間個人デー
タベースと１個人作業に必要なデータを蓄えている共用
データベースという関係では。

２通りの運用形態がある。１つは９共用データベースか
ら個人データベースにデータを取り出して。

編集や加工処理をする形態である。もう１つは個人デー
タベースの処理をするために、共用データベースを参照
する形態である。後者は、前述の（２）と同じ形態であ
る。

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

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

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

個人データベースには１個人の担当顧客情報があり、共
用データベースには、一般顧客情報や商品情報などがあ
る。地域別商品売上情報を参照したり、見積もり書作成
のために、新しい商品情報を個人データベースに取り出
したりする場合や。

個人データベースの担当顧客情報を、共用データベース
の一般顧客情報に反映させたりする場合。

個人データベースと共用データベース間とのデータ交換
が必要になる。このようなデータ連携を。

導出データベースを使用することにより、Ｎ単に実現す
ることができる。

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

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

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

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

第６図に示すように、メーカ情報、卸店台帳。

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

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

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

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

導出データベースでは、さらに、応用プログラム３０Ｃ
のように、複数のデータベース１Ａ１７Ｂの必要な部分
を導出データベース１８として、同時にアクセスするこ
とができる。

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

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

データベース定義部１０におけるデータベース登録部４
２は２通常のデータベース定義文４０を解釈し、その定
義情報をデイクシぢナリ１５に登録する。また、導出デ
ータベース登録部１１は。

導出データベース定義文４１を解釈し、その定義情報を
ディクショナリ１５に登録する。

データベース定義文４０および導出データベース定義文
４１のＢＮＦ形式は、以下の通りである。

なお９本実施例では、論理構造と格納構造とを切り離し
、論理構造表現のデータ単位（テーブルまたはその一部
）の１つを、複数の格納上の管理単位に対応づけて格納
するために、物理媒体上で独立構造を有するデータベー
スの基本的な構成要素として、格納構成単位（ＣＳ　：
　Ｃｏｍｐｏｓｉｔｅ　５Ｌｒｕｃｔｕｒｅ　）という
管理単位を使用している。Ｃ３はヒープ、Ｂ゛木、ハツ
シュなどの基本データ編成の組み合わせから作成した格
納構造であり、他の定義情報によって、１つのスキーマ
の１つのテーブル、複数のテーブルまたはテーブル内の
特定のカラム等に対応付けられるようになっている。言
うまでもなく、このようなＣ３の概念を用いなくても２
本発明を実施することは可能である。

［データベース定義文の記述形式］ 〈データベース定義＞：：＝　　ＣＲＥＡＴＥ　　ＤＢ
　　＜データベース塩〉［ＦＲＯＭ　＜ｃｓ指定〉］ くデータベース塩＞：：＝　　＜識別子〉＜ｃｓ指定＞
：：＝　＜Ｃ３名〉［（・＜ｃｓ名〉）・・・］′［構
文規則コ ＜ｃｓ名〉で指定された各Ｏ８のＣ５定義における　〈
データベース塩〉　は、　〈データベース　定義〉　中
の　くデータベース塩〉と一致していなければならない
。

［意味規則コ ＜ｃｓ指定〉の中の＜ｃｓ名〉で指定された各Ｃ３から
データベースを構成する。このデータベースは、＜デー
タベース塩〉で名前づけられる。　＜ｃｓ指定〉を省略
するならば、Ｏ３定義中のデータベース指定で当該〈デ
ータベース塩〉を指定するＣ５が構成要素となる。

［導出データベース定義文の記述形式］〈導出データベ
ース定義＞：：＝　　ＣＲＥＡＴＥ　　ＶＤＢ　　　＜
導出’ｉデータベース塩ＦＲＯＭ　　＜要素ＤＢ指定＞
　　［ＷＨＥＲＥ　＜置換リスト〉コく導出データベー
ス塩＞：：＝　＜識別子〉〈要素ＤＢ指定＞：：＝　＜
データベース塩＞［＜ｃｓリスト〉　］［（、〈データ
ベース　名＞［＜ｃｓリ　ス　ト〉　コ　）６１、　］
＜ＣＳリスト＞：：＝（＜ｃｓ名＞［（、＜ｃｓ　名＞
１．、、］）く置換リスト〉：：・〈置換要素〉 ［（、〈置換要素＞１．、、］） く置換要素＞：：＝　　＜スキーマ名１＞　　ＡＳ　　
＜スキーマ　名２〉（ＩＮ　　＜データベース塩〉 〈チー７１１名１＞ＡＳ＜テーブル名２〉　　０＼　〈
データ゛、−ス名〉：構文規則、 １）く要素Ｄｌｌ指定〉中の＜’ｔ−９へ一ス名〉で指
定されるデータヘースは、〈データベース定義〉または
く導出データベース定義〉で定義されていなければなら
ない。

２）＜ＣＳリスト〉で指定される各Ｃ５は、当該くＣＳ
リスト〉の直前↓こあるくデータベース塩〉で指定され
るデータヘースのくデータベース定義〉またはく導出デ
ータベース定義〉中に、陽にまたは暗に指定されていな
ければならない。

３）〈置換要素〉中のくスキーマ塩ｌ〉またはくテーブ
ル名１〉で指定されるスキーマまたはチーフルは１　〈
データベース塩〉で指定されるデータヘースの内包でな
ければならない。

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

［意味規則１ １）〈要素ＤＢ指定〉の中の＜データベース塩〉で指定
したデータヘースから＜ＣＳリスト〉中の＜Ｃ５名〉で
指定したＣ３を抽出じたデークベースを構成する。

このデータヘースは、　〈導出データベース塩〉で名前
づけられる。＜ＣＳリストを省略する’ｅｋ　”Ｊば指
定されたデータヘースのすべてのＣ８が指定されたと解
釈する。

２）〈置換要素〉中のくデータへ−ｙ、名〉で指定され
たデータヘース上で、　〈スキーマ塩ｌ〉で指定された
スキーマ（これは当富亥テ゛−タベースの内包である）
の識別子をくスキーマ塩２〉に置き換える。

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

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

このような仕様によるデータヘース定義文４０または導
出データヘース定義文４１の入力によりディクショナリ
１５には３次のような情報が格納される。

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

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

Ｃ）ＩＥＡＴＥ　ＤＢ中央ＤＢ　　ＦＩＩＩＯＭ（メー
カ情報ＣＳ、　メーカ商品属性情報ＣＳ、・・・） ＣＲＥＡＴＥ　ＤＢメーカＤＢ　ＦＲＯＭ（実績Ｃ５，
予算ＣＳ、・・・）ＣＲＥＡＴＥ　ＤＢ卸ＤＢ　　　Ｆ
ＲＯＭ（販売実績ＣＳ、・・・）導出データヘス識別子
外連情報の定義は５以下のとおりである。

ＣＲＥＡＴＥ　Ｃ５メーカＣ５ＴＹＰＥ　Ｂ□ＴＲＥＥ
Ｆ、ＲＯＭ　＜スキーマのテーブル名＞　ＯＮ　ＤＢＯ
ＬＡＬＬＯＣＡＴＥ　ＤＢ　ＤＢＯＩ　＜ＤＢエリア名
＞　Ｔ、Ｏメーカ情報ＣＳ＜ＤＢエリア名＞　Ｔｏ　　
メーカ商品属性情報ＣＳ同様に、　ＤＢＯ２はメーカＤ
Ｂに割り付け、　ＤＢＯ３は卸ＤＢに割り付ける。この
定義文の記述については同様であるので具体例を省略す
る。

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

ＣＲＥＡＴＥ　ＶＤ、Ｂ　　商品分析ＶＤＢ　　ＦＲＯ
ＭＤＢＯＩ　（メーカ情報ＣＳ、　メーカ商品属性情報
Ｃ３）ＤＢＯ２（実績ＣＳ、予算Ｃ３） ＤＢＯ３（販売実績Ｃ５） 次に、データヘス識別子の構成例を、第９図に従って説
明する。

第９図に示すバインド制御部５０の入力は、導出データ
ベース識別子またはデータベース識別子と、ＳＱＬ規格
のモジュールである。モジュールには　スキーマ塩とテ
ーブル名が記述しである。

このスキーマ名、テーブル名は、導出データヘス指定の
別名である場合がある。

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

ＢＩＮＤ　−ｍ　＜ＳＱＬのモジュールのファイル名〉
ｎ商品分析ＶＤＢ この＜ＳＱＬのモジュールのファイル名〉の中身で、Ｓ
ＱＬ文関連は、以下のように記述しである。

５ＥＬＥＣＴ　＊　ＦＲＯＭメーカ情報、メーカ商品属
性情報実績、予算、販売実績　・・・・・・ ここで、メーカ情報、・・・、販売実績は、ＳＱＬスキ
ーマ上のテーブル名とする。

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

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

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

）導出データヘース識別子から、データヘース識別子と
Ｃ３識別子をすべて求める。

１ｉ）Ｃ５識別子から関連する複数のテーブル名を求め
る。テーブル名から関連するスキーマ塩を求める。

ｉ［ｉ）テーブル名、スキーマ塩から別名を求める。

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

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

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

格納情報操作部５４は、格納構造情報操作部５５、ＣＳ
スペース情報操作部５６．ＣＳスペース・ＤＢエリア変
換部５７．ＤＢエリア情報管理部５８からなる。

格納構造情報操作部５５は、Ｃ３の要素であるデータ編
成のプリミティブの情報を管理する。Ｃ３の要素には、
ヒープ、Ｂ゛木、ハツシュなどの基本データ編成が含ま
れてくる。

ＣＳスペース情報操作部５６は、ｃｓに割り当てられて
いるスペース情報を管理する。ｃｓスペス・ＤＢエリア
変換部５７は、ＣＳスペースとＤＢエリアと呼ふエクス
テント情報の集まりの対応を関連づける機能を持つ。Ｄ
Ｂエリア情報管理部５．８は、ＤＢエリアに属するエク
ステント情報を管理する。このエクステント情報は、物
理媒体上のボリューム情報やボリューム内のエクステン
ト情報を含む。

格納情報操作部５４は、Ｏ３に含まれる格納構造に係る
データ編成を操作するプログラムを決定する。次に、Ｃ
Ｓスペース情報操作部５６．ＣＳスペース・ＤＢエリア
変換部５７．ＤＢエリア情報管理部５８により情報を取
り出して、実際にアクセスするボリュームのエクステン
ト情報を決定する。

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

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

、ディクショナリ情報操作部１３内の役割分担を変えて
もよい。例えば、最適化処理部５１から導出デークベー
ス解釈部１４を呼び出しでもよい巳、最適化処理部５１
から論理情報操作部５３を呼び出す場合二こ、スキーマ
名、チーフル名の他二こ、導出データヘース識別子また
はデータヘース識別子を入力じてもよい。

ＩＩ　　ディクノヨナリ１５は、リレーノヨナルデータ
ベースのテーブルでもよいし、独自の制御表構造からな
るディレクトリでもよい。

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

ｉ■、バインドは、データヘースへのアクセス実行段階
の前段階で機能してもよいし、実行段階に機能してもよ
い。

第１０図は１以上のようにして作成されたデータヘース
処理手順５２を含む応用プログラム６０に関する実行時
の動作構成例を示じでいる。

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

また、応用プログラム６０とデータヘースアクセス部６
２とを結合制御するストリング制御部６１が存在する。

データヘースアクセス部６２はデータヘース処理手順５
２によって決められているアクセスすべきデータ格納構
造、ＤＢスペース情報等に従って、データヘース格納装
置１６への入出力を実行する。なお、第１０図に示す例
は一例であり、従来技術と同様に構成できる。

〔発明の効果〕

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

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

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

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

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

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

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

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

【図面の簡単な説明】

第１図は本発明の原理説明区 第２図は本発明に係る導出データヘースの定義例 第３図は部門データヘースと中央データヘースの例 第４図は同しスキーマ構造を持つ独立運用ブタベースの
例 第５図は個人データヘースと共用データヘースの例 第６図はテストデータヘースの例 第７図は本発明に係る導出データヘースの役割を説明す
る図 第８図は本発明の一実施例による導出データヘースの登
録説明図。 第９図は本発明の一実施例によるデータヘース操作系の
構成例５ 第１０図は本発明の一実施例による実行時の動作構成例
を示す。 図中、１は処理装置、１０はデータヘース定義部２１１
は導出データヘース登録部、１２はデクヘース操作部、
１３はディクノヨナリ情報操作部、Ｉ４は導出データヘ
ース解釈部、１５はディクショナリ、１６はデータヘー
ス格納装置、１７Ａ、１７Ｂはデータヘース、１８は導
出データベース、１９はデータヘース処理手順作成部、
ＴＡ１〜ＴＡ３．ＴＢＩ〜ＴＢ３はテーブルを表す。

Claims (1)

1. 【特許請求の範囲】 ある目的でまとまったデータを複数の利用者から同時に
   共用するデータベースが複数独立して存在するデータベ
   ース処理装置において、 独立するデータベースの論理定義情報および二次記憶上
   のデータベースの格納情報を管理するディクショナリ（
   １５）と、 データベースに含まれるデータを定義するスキーマ定義
   で扱う名標の定義範囲を崩さずに、新たな名標の定義枠
   を規定し、データベースに含まれるテーブル間の意味的
   な関係の一貫性を保つ導出データベース（１８）に対応
   させるデータベースの選択情報、選択したデータベース
   の構成要素に関する選択情報およびデータベースで扱う
   名標を別名にする別名指定情報を前記ディクショナリに
   登録する導出データベース登録手段（１１）と、データ
   ベースの操作に対して、操作対象が導出データベースで
   ある場合に、前記ディクショナリを参照し、必要なデー
   タベースの構成要素を選択するとともに、別名指定があ
   れば、その別名を本来の名標に置き換えるディクショナ
   リ情報操作手段（１３）と、 データベースのアクセス経路を具体的に決定する最適化
   処理を行うバインド処理において、前記ディクショナリ
   に登録した導出データベースに関する情報に基づいて複
   数のデータベースの格納要素を部分的に集めたものに対
   するデータベース処理手順を作成するデータベース処理
   手順作成手段（１９）とを備え、 １つの応用プログラムから複数のデータベースをアクセ
   スするようにしたことを特徴とする導出データベース処
   理方式。