JP2002007177A

JP2002007177A - マルチデータベース定義方法

Info

Publication number: JP2002007177A
Application number: JP2000187509A
Authority: JP
Inventors: Yuichi Yagawa; 雄一矢川; Mitsuhiko Yoshimura; 光彦吉村; Shigetoshi Hayashi; 重年林; Takashi Hatazawa; 孝畑沢
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2000-06-19
Filing date: 2000-06-19
Publication date: 2002-01-11

Abstract

(57)【要約】【課題】複数のデータベースが連携して動作するマルチ
データベースのスキーマを正しくかつ容易に定義する。【解決手段】マルチデータベース定義手段は，各データ
ベースの要素スキーマを登録し，表の名前を一意に定義
し，カラムを共通のデータ型に対応付ける。次に，アプ
リケーションの外部スキーマを定義・登録し，外部スキ
ーマから要素スキーマへのマップを定義する。次に，外
部スキーマを実体化する範囲を規定するレプリカ表スキ
ーマを定義・登録し，レプリカ表スキーマから外部スキ
ーマへのマップを定義する。マルチデータベースサーバ
に統合スキーマを出力する際には，外部スキーマが参照
する要素スキーマ及びレプリカ表スキーマが参照する外
部スキーマが正しく存在することを検査し，統合スキー
マ内で外部スキーマから参照されない要素スキーマのデ
ータを削除する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，データベースの定
義方法に関し，特に複数のデータベースが連携して動作
するマルチデータベースの定義方法に関する。

【０００２】

【従来の技術】従来のマルチデータベース定義方法で
は，まず，個別のデータベースのスキーマ（以下，要素
スキーマと呼ぶ）を取り込み，次に，この要素スキーマ
をシステム全体で共通のスキーマ（以下，統合スキーマ
と呼ぶ）に統合し，そして，この統合スキーマを参照し
ながらアプリケーション用のスキーマ（以下，外部スキ
ーマと呼ぶ）を定義していた。ここで，スキーマとは，
表やカラムなどデータベースの構成に関わる定義情報の
ことである。

【０００３】このマルチデータベース定義方法に関する
従来技術は，情報処理学会論文誌Vol.40 No.SIG8(TOD
4)「連邦データベースにおけるスキーマ構築の一方式」
（Nov.1999），米国特許５８０６０６６号「METHOD OF
INTEGRATING SCHEMA OF DISTRIBUTED HETEROGENEOUS DA
TABASES」に示されている。

【０００４】

【発明が解決しようとする課題】まず，図１は，本発明
に関わるマルチデータベースの概念イメージを表す。

【０００５】マルチデータベース10は，データベース
（以下，DBと略す）21〜23とアプリケーション（以下，
APと略す）41〜43をスポークとするハブ＆スポーク型の
アーキテクチャであり，AP41〜43からDB21〜23内に散在
するデータへの透過的なアクセスを可能にする。このた
め，ハブであるマルチデータベース10とスポークとなる
DB21〜23との間には，ハードウェア，オペレーティング
システム，データベース管理システム（以下，DBMSと呼
ぶ）の種類など，異種DB間の差異を吸収するデータベー
ス・アダプタ61〜63を設ける。データベース・アダプタ
61〜63では，DB21〜23からマルチデータベース10に向け
ては，主に文字コードやデータベース問合せ言語（以
下，SQLと呼ぶ）を統一化するように機能し，マルチデ
ータベース10からDB21〜23に向けては，共通の文字コー
ドやSQLを各DB固有の文字コード及びSQLに変換するよう
に機能する。同様に，ハブであるマルチデータベース10
とスポークとなるAP41〜43との間には，APからのアクセ
ス手段を共通のアプリケーション・プログラム・インタ
フェース（以下，APIと呼ぶ）に統一化するためのアプ
リケーション・アダプタ71〜73を設ける。ユーザは，組
織内に分散したデータや組織間にまたがるデータを論理
的に統合し，戦略的に活用するために，マルチデータベ
ース10を使用する。

【０００６】マルチデータベース10は，統合スキーマ12
に従って動作する。統合スキーマは，DB21〜23の構成を
定義した要素スキーマ24〜26と，AP41〜43が要求するデ
ータベースの論理構成を定義した外部スキーマ44〜46
と，各々のスキーマを統合スキーマに連結するためのス
キーマ・アダプタからなる。スキーマ・アダプタは，実
行環境におけるデータベース・アダプタ及びアプリケー
ション・アダプタと同じ位置付けにあり，要素スキーマ
間の差異を吸収するものと，外部スキーマから要素スキ
ーマへのマップを定義するものの二種類がある。

【０００７】本発明の第一の目的は，マルチデータベー
スを実行するために必要な統合スキーマをユーザが簡易
に定義するためのマルチデータベース定義方法を提供す
ることにある。

【０００８】また，上述した従来技術によると，ユーザ
が外部スキーマを定義する場合には，統合スキーマを参
照し，統合スキーマの範囲内でこれを定義する必要があ
った。このため，外部スキーマを柔軟に定義することが
難しく，結果的に、APの開発を効率よく行うことが出来
なかった。最近，情報技術を駆使して組織の意思決定を
タイミングよく行うことが求められており，AP開発を効
率化する意義は大きい。

【０００９】本発明の第二の目的は，マルチデータベー
ス定義方法において，外部スキーマの定義を柔軟に行え
るようにし、マルチデータベースを使用するアプリケー
ションの開発を効率化することにある。

【００１０】また，マルチデータベースでは，統合スキ
ーマの内容に基づいて動作するため，統合スキーマには
高い信頼性が求められる。例えば，統合スキーマがエラ
ーを含む状態では，マルチデータベースシステム全体で
正しい動作を保証することができない。また，統合スキ
ーマが冗長な情報を含む状態では，マルチデータベース
システム全体の性能が低下する。

【００１１】本発明の第三の目的は，マルチデータベー
ス定義方法において，信頼性の高い統合スキーマを出力
することにある。

【００１２】さらに，マルチデータベースでは，APから
見たデータへのアクセス性能を向上させるため，外部ス
キーマの全てまたは一部をあらかじめ実体化しておく。
外部スキーマを実体化した表をレプリカ表と呼び，レプ
リカ表の構成を表す定義情報をレプリカ表スキーマと呼
ぶ。

【００１３】本発明の第四の目的は，マルチデータベー
ス定義方法において，ユーザがレプリカ表スキーマを定
義する機能を提供することにある。

【００１４】

【課題を解決するための手段】まず，本発明に関わるマ
ルチデータベース定義手段では，コンバータ情報を登録
する機能と，要素スキーマを登録する機能と，外部スキ
ーマを定義または登録する機能を提供する。特に，要素
スキーマを登録する機能では，DB間で重複する可能性が
あるDB表名を一意に識別するためのDB表宣言名を定義
し，DB間で異なるデータ型や値の表現形式を統一するた
めのデータ項目として共通DB表カラムを定義する。ま
た，外部スキーマを定義または登録する機能では，外部
スキーマから要素スキーマへのマップを定義するデータ
項目として仮想表SQLを定義する。この結果，統合スキ
ーマ内で要素スキーマや外部スキーマの再利用性が高ま
り，結果的にマルチデータベース定義が容易になる。

【００１５】次に，マルチデータベース定義手段では，
AP開発手段などから外部スキーマを入力する機能を提供
する。また，ユーザがいつでも好きな時に，統合スキー
マとは独立に，外部スキーマを出力する機能を提供す
る。その結果，ユーザが外部スキーマを柔軟に定義でき
るようになる。また，AP開発手段などでは，統合スキー
マの定義と並行してAP開発を進めることが可能になるの
で，AP開発をスピードアップできる。

【００１６】次に，マルチデータベース定義手段では，
統合スキーマの信頼性を検査する機能を提供する。この
検査機能では，統合スキーマのデータモデルに従い，互
いに参照関係にあるデータが統合スキーマ内に正しく存
在することを保証する。具体的には，外部スキーマが参
照する要素スキーマ，及びレプリカ表スキーマが参照す
る外部スキーマが正しく存在することを検査する。ま
た，冗長なデータを除去し，統合スキーマを必要十分な
データからのみ構成されるようにする。具体的には，統
合スキーマ内で外部スキーマから参照されない要素スキ
ーマのデータを削除する。その結果，マルチデータベー
スサーバが正しく動作できるとともに，マルチデータベ
ースサーバの実行性能を確保することができる。

【００１７】さらに，マルチデータベース定義手段で
は，レプリカ表スキーマを定義または登録，及び出力す
る機能を提供する。レプリカ表スキーマを定義または登
録する機能では，外部スキーマ内で実体化する範囲を規
定するレプリカ表SQLを定義する。また，レプリカ表ス
キーマを出力する機能では，レプリカ表の構成とレプリ
カ表SQLをジョブ定義手段などに出力する。ジョブ定義
手段では，この定義情報を参照し，レプリカ表を作成・
更新するジョブを定義する。

【００１８】

【発明の実施の形態】以下，本発明の実施の形態につい
て図面を参照して説明する。

【００１９】図２は，開発環境と実行環境を含むマルチ
データベースシステム全体のソフトウェア構成を表す説
明図である。本実施例は，当該システムの開発環境に関
わり，特にマルチデータベース定義手段1に相当するソ
フトウェアを具体化するものである。以下，各構成要素
ごとに，マルチデータベース定義手段1との関係を中心
に説明する。

【００２０】まず，DB定義手段20では，DB21〜23から要
素スキーマ24〜26を取得する。一般に，要素スキーマは
DBのシステムテーブルと呼ばれる特別の表に格納してあ
るので，DB定義手段20は各DBのシステムテーブルにアク
セスして要素スキーマを取得することになる。また，マ
ルチデータベース定義手段1では，DB定義手段20より要
素スキーマを取得し，登録する。DB定義手段20とマルチ
データベース定義手段1とのインタフェースは実装上の
課題であり，ファイルやAPIのいずれであっても構わな
いが，本実施例ではファイルによる要素スキーマの受け
渡しを想定する。このファイルを要素スキーマファイル
と呼ぶ．また，マルチデータベース定義手段1が要素ス
キーマファイルを出力し，これをDB定義手段20が参照し
てDB21〜２３の要素スキーマ２４〜26を作成する処理の
流れも用意する。

【００２１】その他の実施の形態として，マルチデータ
ベース定義手段1が，DB定義手段20を介せず，DB21〜23
と直接データやファイルの受け渡しを行う構成がある。
当該実施の形態では，マルチデータベース定義手段1がD
B定義手段20の機能を兼ねる点で本実施例と異なるが，
基本的な処理の流れは同様である。

【００２２】次に，コンバータ開発手段30では，DB21〜
23からのデータを統一的な形式（データ型，値）に変換
するプログラムであるコンバータ31を開発し，これをマ
ルチデータベースサーバ10に登録する。マルチデータベ
ースサーバ10は，当該コンバータ31を用いてデータ型や
値を一意に統一する。このコンバータ31の名前（マルチ
データベースサーバ10からみた所在も含む）やパラメタ
及び機能など，コンバータ31のプログラム仕様に関する
情報をコンバータ情報と呼ぶ。マルチデータベース定義
手段1では，コンバータ情報をコンバータ開発手段30よ
り取得し，登録する。コンバータ開発手段30とマルチデ
ータベース定義手段1とのインタフェースは実装上の課
題であり，ファイルやAPIのいずれであっても構わない
が，本実施例ではファイルによるコンバータ情報の受け
渡しを想定する。具体的には，コンバータ31がマルチデ
ータベースサーバの外部ライブラリであると想定し，マ
ルチデータベース定義手段1ではこの外部ライブラリの
ヘッダファイルを登録することにより，コンバータ情報
を作成する。また，マルチデータベース定義手段1がコ
ンバータ31のヘッダファイルを出力し，これをコンバー
タ開発手段30が参照してコンバータを開発する処理の流
れも用意する。

【００２３】その他の実施の形態として，マルチデータ
ベースサーバがデータの型や値の変換に必要十分な機能
を備えており，コンバータ開発手段30を必要としない構
成がある。あるいは，マルチデータベース定義手段1が
コンバータ開発手段30の機能を兼ねる構成がある。いず
れの実施の形態も，本実施例と基本的な処理の流れは同
様である。

【００２４】次に，マルチデータベース定義手段1で
は，要素スキーマを登録し，これを統合スキーマに統合
する（要素スキーマ登録処理240）。また，外部スキー
マを定義または登録し，これを統合スキーマに統合する
（外部スキーマ登録処理250）。そして，統合スキーマ
をマルチデータベースサーバに出力する（統合スキーマ
出力処理300）。この際，統合スキーマの信頼性を検査
する処理320を設けた点に本実施例の特徴がある。編集
ファイル2は，マルチデータベース定義手段で定義途中
の統合スキーマを一時的に保存しておくためのファイル
である。マルチデータベース定義手段1におけるデータ
モデルと処理の流れの詳細については図４以降で説明す
る。

【００２５】次に，マルチデータベースサーバ10では，
マルチデータベース定義手段1が出力した統合スキーマ1
2を内部データベース11（以下，内部DBと呼ぶ）に格納
する。そして，実行時には，当該統合スキーマ12を参照
し，外部のDB21〜23にアクセスする。マルチデータベー
ス定義手段1とマルチデータベースサーバ10とのインタ
フェースは実装上の課題であり，ファイルやAPIのいず
れであっても構わないが，本実施例ではAPIによる統合
スキーマ12の受け渡しを想定する。また，マルチデータ
ベース定義手段1が内部DB11から現在の統合スキーマ12
を取得する処理の流れも用意する。

【００２６】次に，AP開発手段40では，外部スキーマ44
〜46をマルチデータベース定義手段1より取得し，登録
する。そして，外部スキーマ44〜46を参照するAP41〜43
を開発する。マルチデータベース定義手段1とAP開発手
段40のインタフェースは実装上の課題であり，ファイル
やAPIのいずれであっても構わないが，本実施例ではフ
ァイルによる外部スキーマの受け渡しを想定する。この
ファイルを外部スキーマファイルと呼ぶ。また，AP開発
手段40がAP41〜43から外部スキーマ44〜46を取得するな
どして，外部スキーマファイルを出力し，これをマルチ
データベース定義手段1が内部に登録する処理の流れも
用意する。

【００２７】その他の実施の形態として，マルチデータ
ベース定義手段1が，AP開発手段40を介せず，AP41〜43
と直接データやファイルの受け渡しを行う構成がある。
当該実施の形態では，マルチデータベース定義手段1がA
P開発手段40の機能を兼ねる点で本実施例と異なるが，
基本的な処理の流れは同様である。

【００２８】最後に，ジョブ定義手段50では，レプリカ
表スキーマをマルチデータベース定義手段1より取得
し，登録する。そして，レプリカ表を作成・更新するジ
ョブ51（以下，レプリカ表作成・更新ジョブと呼ぶ）と
同ジョブの実行スケジュールを定義する。マルチデータ
ベース定義手段1とジョブ定義手段50のインタフェース
は実装上の課題であり，ファイルやAPIのいずれであっ
ても構わないが，本実施例ではファイルによるレプリカ
表スキーマの受け渡しを想定する。このファイルをレプ
リカ表スキーマファイルと呼ぶ。また，ジョブ定義手段
50がレプリカ表スキーマファイルを出力し，これをマル
チデータベース定義手段1が内部に登録する処理の流れ
も用意する。

【００２９】その他の実施の形態として，マルチデータ
ベース定義手段1が，ジョブ定義手段50を介せず，直接
レプリカ表作成・更新ジョブを生成する構成がある。当
該実施の形態では，マルチデータベース定義手段1がジ
ョブ定義手段50の機能を兼ねる点で本実施例と異なる
が，基本的な処理の流れは同様である。

【００３０】図３は，マルチデータベースシステム全体
のハードウェア構成を表す説明図である。一般に，マル
チデータベース定義手段1，マルチデータベースサーバ1
0，及び図２に記載のその他の手段はソフトウェアとし
て実装されるが，各ソフトウェアのハードウェアへの配
置は，図３に記載する通りである。

【００３１】まず，マルチデータベースシステム100
は，ローカルエリアネットワーク101（以下，LANと呼
ぶ）で接続されたサーバ計算機121〜125とクライアント
計算機111からなる。また，マルチデータベースシステ
ム100は，インターネットなどワイドエリアネットワー
ク102（以下，WANと呼ぶ）を経由して，外部のクライア
ント計算機112からも接続可能である。

【００３２】DB定義手段20，コンバータ開発手段30，マ
ルチデータベース定義手段1，AP開発手段40，ジョブ定
義手段50は，クライアント計算機111に配置される。も
ちろん，各ソフトウェアが別々のクライアント計算機に
配置される構成も有り得る。

【００３３】マルチデータベースサーバ10は，サーバ計
算機121に配置される。また，当該サーバ計算機121は，
内部DB11を制御するため，DBMS131を含む構成となる。
また，レプリカ表作成・更新ジョブ51は，内部DB11にお
いてレプリカ表を作成・更新するので，当該サーバ計算
機121に配置される。もちろん，マルチデータベースサ
ーバ10と内部DB11が別々のサーバ計算機121に配置され
る構成であっても構わないが，その場合はマルチデータ
ベースサーバ10が内部DB11の所在を知っておく必要があ
る。

【００３４】DB21〜23は，サーバ計算機122〜124に配置
される。また，当該サーバ計算機122〜124は，DB21〜23
を制御するため，DBMS132〜134を含む構成となる。もち
ろん，DB21〜23が同一のサーバ計算機に重複して配置さ
れる構成も有り得る。

【００３５】本図では，APがWANを経由して外部のクラ
イアント計算機にサービスを提供する利用形態を想定し
ているので，APをAPサーバと呼んでいる。このAPサーバ
41〜43は，サーバ計算機125〜127に配置される。もちろ
ん，APサーバ41〜43が同一のサーバ計算機に重複して配
置される構成も有り得る。

【００３６】APサーバ41〜43からサービスを受けるAPク
ライアント135は，マルチデータベースシステム100とWA
N102を経由して接続されたクライアント計算機112に配
置される。通常，クライアント計算機112は，多数存在
する。また，APクライアント135の具体例は，WWW（Worl
d Wide Web）ブラウザである。

【００３７】図４は，マルチデータベース定義手段1の
データモデルを表す説明図である。以下，各データ項目
ごとに説明する。

【００３８】マルチデータベース定義手段1は，統合ス
キーマ12を定義するためのソフトウェアであるので，統
合スキーマ12をデータモデルの階層のトップに置く。統
合スキーマ12は，それぞれ複数のコンバータ情報150とD
Bシステム情報160とAPシステム情報170を包含する構成
である。

【００３９】コンバータ情報340は，コンバータの関数
仕様に関するデータ項目であり，コンバータの名前，マ
ルチデータベースサーバ10から見たコンバータの所在，
入出力パラメタに関する説明，機能の説明などを属性と
して保持する。

【００４０】DBシステム情報160は，マルチデータベー
スサーバ10がDBにアクセスするために必要な情報を保持
するデータ項目であり，統合スキーマ12内でユニークな
DB名，DBの所在，DBへのログイン識別子，DBMSの種別な
どの属性を保持する。また，DBシステム情報160は，複
数のDB表161を包含する構成である。

【００４１】DB表161は，DBシステム情報160が包含する
表に関するデータ項目であり，表名やDB表宣言名164な
どの属性を保持する。DB表宣言名164とは，統合スキー
マ内でユニークに与えられるDB表の別名であり，異なる
DB間で表名が同一のDB表がある場合に，これらを一意に
識別するために用いられる。本実施例では，DB表161がD
B表宣言名164を保持する点に特徴がある。DB表161は，
複数のDB表カラム162を包含する構成である。

【００４２】DB表カラム162は，DB表161が包含するカラ
ムに関するデータ項目であり，DB表内でユニークなカラ
ム名，カラムのデータ型，データ長，データのスケール
（位取り），NULL可であるか，主キーであるか，外部キ
ーであるか，といった属性を持つ。また，DB表カラム16
2は，一つの共通DB表カラム163を包含する構成である。

【００４３】共通DB表カラム163は，DB表カラム162をマ
ルチデータベースサーバ10のデータ型（以下，共通デー
タ型と呼ぶ）に対応付けるための情報を保持するデータ
項目である。DB表カラム162は，各DBMSごとに異なるデ
ータ型（以下，要素データ型と呼ぶ）を持つため，マル
チデータベースサーバ10ではこれを共通データ型に統一
する必要がある。共通DB表カラム163が保持する属性
は，共通データ型の名前，データ長，データのスケー
ル，要素データ型から共通データ型にデータを変換する
コンバータ情報150へのポインタ，逆に共通データ型か
ら要素データ型にデータを逆変換するコンバータ情報15
0へのポインタなどを保持する。データ型を変換するこ
とを型変換と呼び，また型変換を行うコンバータを型変
換コンバータと呼ぶ。もちろん，データ型の対応付けで
型変換を行う必要がない共通DB表カラム163では，コン
バータ情報150への各ポインタはNULLとなる。

【００４４】また，例えば，DB21では性別をM及びFの英
文字で表し，DB22では性別を0及び1の数字で表すなど，
本来は意味が同じであるはずのDB表カラムのデータの表
現形式を統一するための情報も共通DB表カラム163が保
持する。具体的には，DB表カラム162のデータ値を共通D
B表カラム163のデータ値に変換するコンバータ情報150
へのポインタ，逆に共通DB表カラム163のデータ値をDB
表カラム162のデータ値に逆変換するコンバータ情報150
へのポインタなどを保持する。データ値を変換すること
を値変換と呼び，値変換を行うコンバータを値変換コン
バータと呼ぶ。もちろん，値変換が必要ではない共通DB
表カラム163では，コンバータ情報150への各ポインタは
NULLとなる。

【００４５】要素スキーマ24は，DB表161とDB表カラム1
62から構成され，各DBシステム情報160単位に管理され
る。本実施例では，DB表カラム162が共通DB表カラム163
を包含する構成となっている点に特徴がある。共通DB表
カラム163は，概念的には，要素スキーマ間の差異を吸
収するスキーマ・アダプタとして機能する。

【００４６】なお，本実施例では，DB表カラム162が共
通DB表カラム163を一つ包含する構成としていたが，DB
表カラム162が複数の共通DB表カラム163を包含する実施
の形態も可能である。この実施の形態では，後述する仮
想表SQLが参照する共通DB表カラムを一意に決めるた
め，仮想表SQL内ではDB表カラム162ではなく，共通DB表
カラム163の名前を記述する。従って，図４のデータモ
デルの図でも，仮想表SQLは共通DB表カラムを直接参照
する構成となる。

【００４７】APシステム情報170は，マルチデータベー
スサーバ10がAPごとに外部スキーマ44を管理するために
必要なデータ項目であり，統合スキーマ12内でユニーク
なAP名などの属性を保持する。APシステム情報170は，
複数の仮想表171とレプリカ表181を包含する構成であ
る。

【００４８】仮想表171は，外部スキーマにおける論理
的な表を表すデータ項目であり，APシステム情報170内
でユニークな仮想表名などの属性を保持する。仮想表17
1は，複数の仮想表カラム172と一つの仮想表SQL173を包
含する構成である。

【００４９】仮想表カラム172は，仮想表が包含するカ
ラムに関するデータ項目であり，仮想表内でユニークな
カラム名，カラムのデータ型，データ長，データのスケ
ール（位取り），といった属性を持つ。また，NULL可で
あるか，主キーであるか，外部キーであるか，といった
その他の属性を保持する実施の形態も有り得る。

【００５０】仮想表SQL173は，外部スキーマ44から要素
スキーマ24へのマップを定義するデータ項目であり，マ
ップする要素スキーマの条件を定義した問合せ式（すな
わちSQL文）を属性として持つ。当該SQL文は，一般と同
様に，SELECT句，FROM句，WHERE句，GROUPBY句，HAVING
句などからなるが，FROM句ではDB表宣言名を用いて条件
を記述し，SELECT句，WHERE句，GROUPBY句，HAVING句で
はDB表カラム名を用いて条件を定義する点に本実施例の
特徴がある。

【００５１】外部スキーマ44は，仮想表171と仮想表カ
ラム172から構成され，各APシステム情報170単位に管理
される。本実施例では，仮想表171が仮想表SQL173を包
含する構成となっている点に特徴がある。仮想表SQL173
は，概念的には，外部スキーマから要素スキーマへのマ
ップを定義するスキーマ・アダプタとして機能する。

【００５２】レプリカ表181は，外部スキーマを実体化
する表を表すデータ項目であり，APシステム情報170内
でユニークなレプリカ表名，定義状況184などの属性を
保持する。ここで，定義状況184とは，レプリカ表の定
義が新規作成されたか，変更されたか，削除されたか，
または変更なしであるかを表すフラグである。マルチデ
ータベースサーバ10は，この定義状況184の属性を参照
することにより，内部DB11にあるレプリカ表13の実体を
有効にメンテナンスすることができる。例えば，「新
規」の場合は，マルチデータベースサーバ10が内部DB11
内に新規のレプリカ表を作成する。また，「変更」の場
合は，既存のレプリカ表を削除し，新たにレプリカ表を
作成する。また，「削除」の場合は，既存のレプリカ表
を削除する。そして，「変更なし」の場合は，既存のレ
プリカ表をそのまま使用する。本実施例では，この定義
状況184をレプリカ表181が属性として保持する点に特徴
がある。レプリカ表は，複数のレプリカ表カラム182と
一つのレプリカ表SQL183を包含する構成である。

【００５３】レプリカ表カラム182は，レプリカ表が包
含するカラムに関するデータ項目であり，レプリカ表内
でユニークなカラム名，カラムのデータ型，データ長，
データのスケール（位取り），といった属性を持つ。

【００５４】レプリカ表SQL183は，レプリカ表スキーマ
52から外部スキーマ44へのマップを定義するデータ項目
であり，マップする外部スキーマの条件を定義したSQL
文を属性として持つ。当該SQL文は，一般と同様に，SEL
ECT句，FROM句，WHERE句，GROUPBY句，HAVING句などか
らなるが，FROM句では仮想表名を用いて条件を記述し，
SELECT句，WHERE句，GROUPBY句，HAVING句では仮想表カ
ラム名を用いて条件を定義する点に本実施例の特徴があ
る。

【００５５】レプリカ表スキーマ52は，レプリカ表181
とレプリカ表カラム182とレプリカ表SQL183から構成さ
れ，各APシステム情報170単位に管理される。

【００５６】図５から図１９に記載の各図は，マルチデ
ータベース定義手段1の処理の流れを表す説明図であ
る。以下，各処理の流れについて説明する。

【００５７】図５は，マルチデータベース定義手段1に
おける全体の処理の流れを表す説明図である。

【００５８】まず，編集ファイル入力・新規作成処理20
0は，編集ファイルをオープン，または新規作成し，マ
ルチデータベース定義手段1の内部に統合スキーマを生
成する処理である。編集ファイルは，当該統合スキーマ
をシリアライズしたファイルであり，マルチデータベー
ス定義手段1への入出力ファイルである。ユーザは定義
の途中の統合スキーマを編集ファイルに保存し，再度編
集する場合は当該編集ファイルをマルチデータベース定
義手段1に入力する。

【００５９】次に，編集処理210は，マルチデータベー
ス定義手段1において，データを登録，編集する処理で
ある．詳細は図６で述べる。

【００６０】次に，反映処理60は，マルチデータベース
定義手段1内の統合スキーマをマルチデータベースサー
バなど外部に反映する処理である。詳細は図７で述べ
る。

【００６１】最後に，編集ファイル出力処理201では，
マルチデータベース定義手段1内の統合スキーマを編集
ファイルに上書き保存，または別名保存する処理であ
る。編集ファイルの出力は，一般のファイル出力インタ
フェースに従い，ユーザが名前を付けて保存，または上
書き保存する。

【００６２】以上は，マルチデータベース定義手段1に
おける全体の処理の典型的な流れを示すものであり，全
ての処理が上記に従うということではない。例えば，ユ
ーザが編集処理のみ行い，反映処理を行わない場合もあ
る。ユーザが数日間に渡って編集処理を繰り返す場合は
この流れになる。逆に，ユーザが反映処理のみ行い，編
集処理を行わない場合もある。ユーザがシステム全体の
運用から見たタイミングを見計らって反映処理を行いた
い場合にこの流れになることが多い。

【００６３】図６は，編集処理210の流れを表す説明図
である。

【００６４】まず，編集処理210ではユーザが処理対象
を選択することから開始する（ステップ211）。編集処
理の対象は，コンバータ情報登録処理230，要素スキー
マ登録処理240，外部スキーマ登録処理250，レプリカ表
スキーマ登録処理260のいずれかである。ユーザが各処
理を終了すると，関連データ変更処理270が起動され
る。ユーザは編集処理を随時繰り返すことができる。以
下，各処理ごとに説明する。

【００６５】コンバータ情報登録処理230は，コンバー
タ開発手段とのインタフェースを担う処理であり，具体
的には，ユーザがコンバータを含む外部ライブラリのヘ
ッダファイルを入力することにより，統合スキーマ内に
コンバータ情報を作成，または既に作成されているコン
バータ情報を更新する処理である。同じ外部ライブラリ
名を持つコンバータ情報が既に統合スキーマ内に存在す
る場合には，当該コンバータ情報を統合スキーマからす
べて削除し，ヘッダファイル内のコンバータ情報を新し
く作成する。名前が同一のコンバータ情報に関しては，
中身が編集されたとみなす。統合スキーマ内にあってヘ
ッダファイルにないコンバータ情報については，削除さ
れたものとみなす。ヘッダファイルにあって統合スキー
マ内にはなかったコンバータ情報については，新規に追
加されたものとみなす。新規に追加するコンバータ情報
と同じ名前のコンバータ情報が統合スキーマ内に既に存
在していたとしても，外部ライブラリ名が異なる場合に
は異なるコンバータ情報とみなしてそのまま追加する。
コンバータ情報は，要素スキーマ登録処理240におい
て，ユーザが必要に応じてコンバータを選択する場合に
参照される。

【００６６】要素スキーマ登録処理240は，DB定義手段
とのインタフェースを担う処理であり，具体的には，ユ
ーザが要素スキーマファイルを入力することにより，統
合スキーマ内に要素スキーマを生成する処理である。

【００６７】図２０は，要素スキーマ登録処理240の画
面を表す説明図である。要素スキーマ登録処理240で
は，要素スキーマ登録ウィンドウ500が表示される。当
該ウィンドウ500は，DB名とDB表名を階層的に表示する
要素スキーマ・ツリービュー501と，当該ツリービュー5
01で選択された項目が包含するデータ項目とその属性を
リスト形式で表示する要素スキーマ・リストビュー502
から構成される。特に，ツリービュー501でDB表が選択
された場合に，リストビュー502には，DB表カラムと共
通DB表カラムの属性がともに表示される点に本実施例の
特徴がある。図２０の例では，ツリービュー501でDB表
「RTable1」が選択された状態にあるので，リストビュ
ー502には「RTable1」が包含するDB表カラムの名前と要
素データ型，そして当該DB表カラムに対応付けられた共
通データ型が表示されている。

【００６８】図8は，要素スキーマ登録処理240の流れを
表す説明図である。以下，各ステップごとに説明する。
まず，ステップ241では，ユーザがGUIを使ってDBシステ
ム情報を定義，または既に定義されているDBシステム情
報を編集する。例えば，図２０の要素スキーマ登録ウィ
ンドウ500において，DB名「DB１」をダブルクリックす
るなどして，当該図には記載していない専用のダイアロ
グを表示する。当該ダイアログでは，「DB1」のDBシス
テム情報を編集可能な状態で表示する。表示するDBシス
テム情報の内容は，図４の説明で記載した通りである。
また，DBシステム情報は，DBへのログイン名とパスワー
ドを含むが，これらは高セキュリティ情報であるので，
中身が外部に漏れないよう隠蔽処理を施しておくととも
に，画面ではパスワードを隠蔽して表示する。

【００６９】ユーザが，便宜上，一つの物理DBを複数の
論理DBとみなしたい場合には，論理DBごとにDBシステム
情報を登録する。その際，物理的なシステム情報は同じ
であっても構わないが，DB名についてはそれぞれ異なる
名前を登録する。つまり，DB名はマルチデータベース定
義手段1でユニークである。また，ユーザは各々の論理D
Bに対応する要素スキーマも登録する。この論理的なDB
を登録する機能は，本実施例の特徴である。

【００７０】次に，ステップ242では，ユーザが指定し
た要素スキーマファイルを入力する。要素スキーマファ
イルには，DB表とDB表カラムのデータが，例えばCSV形
式で格納されているので，マルチデータベース定義手段
1はこれらのデータを読み込むことになる。そして，読
み込んだDB表とDB表カラムのデータを現在選択されてい
るDBシステム情報が包含するように設定する。この際の
操作方法としては，例えば，ユーザがDB名「DB1」を選
択し，メニューから「要素スキーマファイル入力」を実
行する。そして，図２０には記載していないファイル入
力ダイアログが表示されるので，ユーザが入力したい要
素スキーマファイルを選択し，入力を実行する。あと
は，自動的に要素スキーマファイルが当該「DB1」のDB
システム情報の下に展開される。

【００７１】この際，選択されたDBシステム情報に対し
て既にDB表やDB表カラムが割り当ててある場合には，マ
ルチデータベース定義手段1はその旨ユーザにメッセー
ジを表示し，既存のDB表とDB表カラムを上書きして良い
か確認する。ユーザが上書きを承認後，当該DB表とDB表
カラムを破棄し，入力されたファイルに含まれるDB表と
DB表カラムを新たに割り当てる。上書きではなく差分を
登録する実装では，既存のDB表及びDB表カラムと新規に
入力するDB表及びDB表カラムの差分を検出する処理を追
加する。

【００７２】次に，ステップ244では，入力後の全DB表
に統合スキーマ内でユニークなDB表宣言名を付与する。
デフォルトのDB表宣言名はDB表の名前と同じである。但
し，DB表名と同じDB表宣言名が統合スキーマ内にある場
合には，別のユニークな名前を割り当てる必要がある。
例えば，DB名は統合スキーマ内でユニークであるので，
当該DB名とDB表名を合わせてDB表宣言名にする。また
は，DB表名にシリアル番号を付与したものをDB表宣言名
にする。または，ユーザにユニークなDB表宣言名の入力
を促す。このDB表宣言名を定義する処理は，本実施例の
特徴である。

【００７３】次に，ステップ245〜247は，共通DB表カラ
ムを定義する処理である。まず，ステップ246では，入
力後の全DB表カラムを共通データ型に対応付ける。マル
チデータベース定義手段１は，共通データ型と要素デー
タ型との対応表を辞書として保持するので，これを活用
して対応付ける。この際，データ型によって値の範囲や
精度が異なる場合など，データ型を変換する処理が必要
な場合には，データ型の変換を行う適切なコンバータ情
報150を割り当てる。各々のデータ型の変換に必要なコ
ンバータについてもルール化しておき，先の対応表とと
もにマルチデータベース定義手段1がこれを保持する。
このため，コンバータ情報150は，例えば，コンバータ
が変換するデータ型の組み合わせなど，ルール化に必要
な情報を保持する。

【００７４】ユーザが共通DB表カラムの共通データ型を
変更することができる実施の形態もある。この形態で
は，ユーザがコンバータ情報を参照しながら，必要に応
じてコンバータを選択する。

【００７５】次に，ステップ247では，DB表カラムのデ
ータ値の表現形式を統一するために必要な値変換コンバ
ータをユーザが指定する。この際，ユーザが値変換コン
バータを選択しやすいように，画面にはコンバータ情報
が表示される。なお，値変換を行う必要がないDB表カラ
ムについては，本ステップ247はスキップされる。例え
ば，ユーザは画面で「キャンセル」ボタンを選択する。
また，要素スキーマファイルを入力後も，ユーザがDB表
カラムを選択し，随時，値変換コンバータを指定するこ
とができる。

【００７６】以上，共通DB表カラムを定義する処理は，
本実施例の特徴である。

【００７７】外部スキーマ登録処理250は，ユーザが外
部スキーマを定義，または外部スキーマファイルを入力
することにより，統合スキーマ内に外部スキーマを生成
する処理である。

【００７８】図２１は，外部スキーマ登録処理250の画
面を表す説明図である。外部スキーマ登録処理250で
は，外部スキーマ登録ウィンドウ510が表示される。当
該ウィンドウ510は，AP名と仮想表名を階層的に表示す
る外部スキーマ・ツリービュー511と，当該ツリービュ
ー511で選択された項目が包含するデータ項目とその属
性をリスト形式で表示する外部スキーマ・リストビュー
512と，仮想表SQL173を記述するための外部スキーマ・
テキストボックス513から構成される。特に，ツリービ
ュー511で仮想表が選択された場合に，リストビュー512
には，当該仮想表が包含する仮想表カラムとその属性が
表示され，テキストボックス513には，当該仮想表が包
含する仮想表SQLが表示される点に本実施例の特徴があ
る。図２１の例では，ツリービュー511で仮想表「VTabl
e1」が選択された状態にあるので，リストビュー512に
は「VTable1」が包含する仮想表カラムの名前とデータ
型，そしてコメントが表示されている。また，テキスト
ボックス513には，当該仮想表から要素スキーマへのマ
ップを定義する仮想表SQLが表示されている。テキスト
ボックス513には，SELECT句，FROM句，WHERE句までしか
記載していないが，GROUPBY句やHAVING句など，他の条
件を含む構成も当然有り得る。

【００７９】図９は，外部スキーマ登録処理250の流れ
を表す説明図である。以下，各ステップごとに説明す
る。

【００８０】まず，ステップ251では，ユーザがAPシス
テム情報を定義，または既に定義されているAPシステム
情報を編集する。ここで，APシステム情報の定義とは，
統合スキーマ内でユニークな名前を外部スキーマに与え
ることである。

【００８１】次に，ステップ252では，ユーザが仮想表
を定義，または既に定義されている仮想表を編集する。
ここで，仮想表の定義とは，外部スキーマ内でユニーク
な名前を仮想表に与えることである。

【００８２】また，他の実施の形態では，統合スキーマ
内でユニークな名前を仮想表に与える形態も有り得る。

【００８３】次に，ステップ253では，ユーザが仮想表
カラムを定義する。ここで，仮想表カラムの定義とは，
仮想表カラムの名前とデータ型を決めることである。

【００８４】以上のステップ251〜253の操作は，図面に
は記載しない専用のダイアログに各データ項目の属性を
表示し，これを編集することによって行う。

【００８５】ステップ254では，ユーザからの要求に応
じて，ステップ252〜253の代わりに，外部スキーマファ
イルを入力する。外部スキーマファイルには，仮想表と
仮想表カラムのデータが，例えばCSV形式で格納されて
いるので，マルチデータベース定義手段1はこれらのデ
ータを読み込むことになる。そして，読み込んだ仮想表
と仮想表カラムのデータを現在選択されているAPシステ
ム情報が包含するように設定する。この際の操作方法
は，前述の要素スキーマファイルを入力する場合と同様
である。

【００８６】ステップ255では，ユーザが仮想表SQLで条
件を記述する事によって，仮想表からDB表及びDB表カラ
ムへのマップを定義する。ユーザは，図２１の外部スキ
ーマ登録ウィンドウ510内のテキストボックス513におい
て，仮想表SQLを記述・編集する。この際，ユーザは要
素スキーマ登録ウィンドウ500を参照し，DB表やDB表カ
ラムの名前を確認しながら，仮想表SQLを記述する。ま
た，ユーザがDB表またはDB表カラムを選択し，テキスト
ボックス513にドラッグ＆ドロップすることによって，
仮想表SQL内に当該DB表またはDB表カラム名を自動的に
展開する操作方法も有り得る。この仮想表SQLを定義す
る処理は，本実施例の特徴である。

【００８７】レプリカ表スキーマ登録処理260は，ユー
ザがレプリカ表を定義，またはレプリカ表スキーマファ
イルを入力することにより，統合スキーマ内にレプリカ
表スキーマを生成する処理である。

【００８８】図２２は，レプリカ表スキーマ登録処理26
0の画面を表す説明図である。レプリカ表スキーマ登録
処理260では，レプリカ表スキーマ登録ウィンドウ520が
表示される。当該ウィンドウ520は，AP名とレプリカ表
名を階層的に表示するレプリカ表スキーマ・ツリービュ
ー521と，レプリカ表SQLを記述するためのレプリカ表ス
キーマ・テキストボックス523から構成される。特に，
ツリービュー521でレプリカ表が選択された場合に，テ
キストボックス523には当該レプリカ表が包含するレプ
リカ表SQLが表示される点に本実施例の特徴がある。図
２２の例では，ツリービュー521でレプリカ表「Replica
1」が選択された状態にあるので，テキストボックス523
には，当該レプリカ表から仮想表及び仮想表カラムへの
マップを定義するレプリカ表SQLが表示されている。テ
キストボックス523には，SELECT句，FROM句，WHERE句ま
でしか記載していないが，GROUPBY句やHAVING句など，
他の条件を含む構成も当然有り得る。

【００８９】図１０は，レプリカ表スキーマ登録処理26
0の流れを表す説明図である。以下，各ステップごとに
説明する。

【００９０】まず，ステップ261では，ユーザがAPシス
テム情報を選択する。以下の処理で定義するレプリカ表
は，当該APシステム情報に包含されることになる。

【００９１】次に，ステップ262では，ユーザがレプリ
カ表を定義，または既に定義されているレプリカ表を編
集する。ここで，レプリカ表の定義とは，当該APシステ
ム情報170が包含する全レプリカ表でユニークな名前を
当該レプリカ表に与えることである。レプリカ表が保持
する定義状況の属性は，編集処理210の時点ではデフォ
ルトの「変更なし」のままであり，反映処理220におい
て決定される。

【００９２】次に，ステップ263では，ユーザがレプリ
カ表SQLで条件を記述することによって，レプリカ表か
ら仮想表及び仮想表カラムへのマップを定義する。ユー
ザは，図２２のレプリカ表スキーマ登録ウィンドウ520
内のテキストボックス523において，レプリカ表SQLを記
述・編集する。この際，ユーザは外部スキーマ登録ウィ
ンドウ510を参照し，仮想表や仮想表カラムの名前を確
認しながら，レプリカ表SQLを記述する。また，ユーザ
が仮想表または仮想表カラムを選択し，テキストボック
ス523にドラッグ＆ドロップすることによって，レプリ
カ表SQL内に当該仮想表または仮想表カラム名を自動的
に展開する操作方法も有り得る。このレプリカ表SQLを
定義する処理は，本実施例の特徴である。

【００９３】ステップ264では，ユーザからの要求に応
じて，ステップ262〜263の代わりに，レプリカ表スキー
マファイルを入力する。レプリカ表スキーマファイルに
は，レプリカ表とレプリカ表SQLのデータが，例えばCSV
形式で格納されているので，マルチデータベース定義手
段1はこれらのデータを読み込むことになる。そして，
読み込んだレプリカ表とレプリカ表SQLのデータを現在
選択されているAPシステム情報が包含するように設定す
る。この際の操作方法は，前述の要素スキーマファイル
を入力する場合と同様である。

【００９４】レプリカ表カラムが保持する全属性は，編
集処理210の時点ではNULLのままであり，反映処理220に
おいて決定される。

【００９５】図４に示したように，統合スキーマ内のデ
ータは互いに関連する。このため，あるデータに対する
編集処理が他のデータに影響が及ぶ場合がある。関連デ
ータ変更処理270では，そのデータ間の関連に影響が及
ぶ編集処理が行われた場合に，データ間に矛盾が生じな
いように，マルチデータベース定義手段が特定のデータ
を自動的に変更する処理である。具体的には，図４のデ
ータモデルの包含関係にあるデータ項目間において，親
データが削除された場合に，子データも削除する処理で
ある。

【００９６】関連データ変更処理270の流れは，図１１
に記載する通りである。以下，各ステップごとに説明す
る。

【００９７】まず，ステップ271では，実行された編集
処理が親データを削除する処理であるかどうかを判断す
る。親データを削除する処理である場合に限ってステッ
プ272に進み，他の処理では関連データ変更処理270を終
了する。ステップ272では，当該親データに包含されて
いた子データを取得する。次に，ステップ273とステッ
プ274では，取得した子データをすべて削除する。

【００９８】他の実施の形態として，関連データを自動
的に変更する場合には必ずその旨メッセージを表示し，
ユーザの承認を得た後に実際の変更を行うとともに，ユ
ーザが承認しない場合には，編集処理そのものもキャン
セルする形態も有り得る。

【００９９】図７は，反映処理220の流れを表す説明図
である。

【０１００】まず，反映処理220ではユーザが処理対象
を選択することから開始する（ステップ221）。反映処
理220の対象は，統合スキーマ出力処理300，外部スキー
マ出力処理400，レプリカ表スキーマ出力処理410のいず
れかである。ユーザは反映処理220を逐次繰り返すこと
ができる。以下，各処理ごとに説明する。

【０１０１】統合スキーマ出力処理300は，マルチデー
タベース定義手段1からマルチデータベースサーバ10に
統合スキーマを出力する処理である。

【０１０２】図１２は，統合スキーマ出力処理300の流
れを表す説明図である。以下，各ステップごとに説明す
る。

【０１０３】まず，検査処理320では，統合スキーマ出
力そのものを行う前に，現在の統合スキーマ内にエラー
や冗長なデータが含まれていないかをチェックする。検
査処理320の詳細は図１３で述べる。

【０１０４】次に，ステップ301では，検査処理320でエ
ラーが検出されたかどうかを判断する。エラーが検出さ
れた場合には，ステップ305に移行し，エラーが検出さ
れなかった場合には，ステップ302に移行する。

【０１０５】ステップ302では，各レプリカ表の定義状
況の属性を設定する。まず，マルチデータベース定義手
段1で定義中のレプリカ表スキーマ（以下，新レプリカ
表スキーマと呼ぶ）をマルチデータベースサーバ10で現
在用いられているレプリカ表スキーマ（以下，現レプリ
カ表スキーマと呼ぶ）と比較し，新規に定義されたレプ
リカ表，属性が変更されたレプリカ表，削除されたレプ
リカ表をそれぞれ抽出する。新レプリカ表スキーマにあ
って現レプリカ表スキーマにないレプリカ表を「新規」
とみなす。現レプリカ表スキーマにあって新レプリカ表
スキーマにないレプリカ表を「削除」とみなす。新レプ
リカ表スキーマと現レプリカ表スキーマで同じ名前のレ
プリカ表においてレプリカ表SQLを比較し，異なってい
たら「変更」とみなす。そして，新レプリカ表スキーマ
内の各レプリカ表に対し，定義状況の属性に「新規」，
「変更」，「削除」のフラグ情報を付与する。ここで，
削除されたレプリカ表については，このままでは新レプ
リカ表スキーマに含まれていないので，現レプリカ表ス
キーマからコピーして作成する。新レプリカ表スキーマ
内の残りのレプリカ表については，定義状況にはデフォ
ルトの「変更なし」のフラグが設定されたままである。
この定義状況の属性を設定する処理は，本実施例の特徴
である。

【０１０６】同じく，ステップ302では，マルチデータ
ベース定義手段1がレプリカ表SQLのSELECT句を参照し，
レプリカ表カラムを生成する。具体的には，レプリカ表
カラムに対応する仮想表カラムがSELECT句に記載されて
いるので，当該仮想表カラムと同一の名前とデータ型を
レプリカ表カラムに与える。SELECT句に式が記載されて
いる場合には，レプリカ表内で重複しない名前をマルチ
データベース定義手段が設定し，データ型については当
該式から判断するものとする。

【０１０７】次に，ステップ303では，マルチデータベ
ース定義手段１がマルチデータベースサーバ10に接続
し，統合スキーマを出力する。統合スキーマ12の容量が
大きい場合には，この出力が長時間に及ぶ場合があるの
で，現在の出力の実行状況を示すダイアログを表示し，
ユーザに安心感を与える。

【０１０８】ステップ301においてエラーが検出された
場合には，ステップ305に移行する。ステップ305では，
ユーザがエラーに対する対処を「自動解決」，「自動除
去」，「ユーザ自身による解決」の三種類の中から選択
する。ユーザが「自動解決」を選択した場合には，エラ
ー自動解決処理360に移行する。ユーザが「自動除去」
を選択した場合には，エラー自動除去処理390に移行す
る。ユーザが「ユーザ自身による解決」を選択した場合
には，そのまま統合スキーマ出力処理300を終了する。

【０１０９】ここで，エラーは，図４のデータモデルの
参照関係にあるデータ項目間において，参照先のデータ
項目が存在しない場合に起きる。ちなみに，包含関係に
ついては，関連データ変更処理270が編集時に発生する
矛盾を解消するように機能するので，エラーが発生しな
い。つまり，マルチデータベース定義手段1が参照先の
データ項目を用意するか，あるいは参照元のデータ項目
を削除すれば，エラーは解消する。参照先のデータ項目
を用意する処理がエラー自動解決処理360であり，参照
元のデータ項目を削除する処理がエラー自動除去処理39
0である。

【０１１０】エラー自動解決処理360については，図１
５〜１６で説明する。エラー自動解決処理360の後は，
統合スキーマ出力処理300を終了する。

【０１１１】エラー自動除去処理390については，図１
７で説明する。エラーの元となったデータが除去される
ので，そのままステップ302に移行し，統合スキーマ出
力処理300を継続する。

【０１１２】以上から分かるように，マルチデータベー
ス定義手段1では，エラーが解消されない限り，統合ス
キーマをマルチデータベースサーバ10に出力することが
できない。統合スキーマ出力処理300におけるこの制約
は，本実施例の特徴である。

【０１１３】図１３は，検査処理320の流れを表す説明
図である。以下，各処理ごとに説明する。

【０１１４】ステップ321では，全ての共通DB表カラム1
63において，型変換と値変換の定義内容をチェックす
る。具体的には，ステップ322において，DB表カラムの
要素データ型と共通DB表カラムで定義された共通データ
型との型変換に対して，正しい型変換コンバータが選択
されているかをチェックする。また，編集処理210で
は，コンバータ情報そのものが削除される場合もあるの
で，参照するコンバータ情報がそもそも正しく存在する
かどうかもチェックする。同様に，ステップ323におい
ても，値変換コンバータの入力パラメータと出力パラメ
ータのそれぞれのデータ型がDB表カラムの要素データ型
と共通DB表カラムの共通データ型に合致するか，参照す
るコンバータ情報が正しく存在するか，などをチェック
する。

【０１１５】次に，ステップ324では，全ての仮想表SQL
に対して構文チェック325及び意味チェック340を行う。
構文チェック325では，仮想表SQLがNULLではないことを
確認した上で，構文解析等を用い，仮想表SQLが文法的
に正しいかどうかをチェックする。意味チェック340で
は，仮想表SQLに記載された内容が意味的に正しいかど
うかをチェックする。意味チェック340は，図１４で説
明する。

【０１１６】同様に，ステップ324においても，全ての
レプリカ表SQLに対して構文チェック325及び意味チェッ
ク340を行う。構文チェック325では，レプリカ表SQLがN
ULLではないことを確認した上で，構文解析等を用い，
レプリカ表SQLが文法的に正しいかどうかをチェックす
る。意味チェック340では，レプリカ表SQLに記載された
内容が意味的に正しいかどうかをチェックする。意味チ
ェック340は，図１４で説明する。

【０１１７】次に，ステップ327では，これまでの処理
でエラーが検出されたかどうかをチェックする。エラー
が検出された場合には，ステップ329に移行する。エラ
ーが検出されなかった場合には，ステップ328に移行す
る。

【０１１８】ステップ328では，統合スキーマ内で冗長
なデータ（以下，フラグメントと呼ぶ）を検出する。フ
ラグメントの例としては，いずれの共通DB表カラムから
も参照されないコンバータ情報，いずれの仮想表SQLか
らも参照されないDB表，などがある。マルチデータベー
スサーバ10は，実行時に必要な定義情報を統合スキーマ
から素早く検索できなければならないので，当該統合ス
キーマは実行時に必要な定義情報のみ保持するようにす
る。このため，マルチデータベース定義手段1がマルチ
データベースサーバ10に出力する統合スキーマからはフ
ラグメントを除去する。なお，マルチデータベース定義
手段１内の統合スキーマにフラグメントが存在する状態
であっても，当該ステップ328においてフラグメントを
除去することが可能なので，ユーザにはフラグメントが
存在することを警告するのみとし，統合スキーマ出力処
理全体はそのまま継続することができる。

【０１１９】図２３は，検査結果の画面を表す説明図で
ある。ステップ329では，以上の処理の結果としてエラ
ーメッセージや警告メッセージを検査ウィンドウ530に
一覧表示する。当該ウィンドウ531は検査結果・リスト
ビュー531からなるので，ユーザは随時エラーメッセー
ジや警告メッセージを確認できる。エラーメッセージや
警告メッセージの例は，図２３に示す通りである。ま
た，検査の結果，エラーや警告が検出されなかった場合
には，その旨メッセージを表示する。

【０１２０】以上述べてきた検査処理320は，本実施例
の特徴である。

【０１２１】図１４は，意味チェック処理340の流れを
表す説明図である。以下，各処理ごとに説明する。な
お，下記処理で使用する表名やカラム名は構文チェック
325時にSQLの構文解析を行う際に取得しておく。

【０１２２】まず，ステップ341では，SQL文のFROM句に
記載する表が統合スキーマ内に存在することをチェック
する。仮想表SQLの場合にはDB表が存在すること，レプ
リカ表SQLの場合には仮想表が存在することをチェック
する。当該表が統合スキーマ内に存在する場合にはステ
ップ342に移行し，存在しない場合には，ステップ348に
移行する。

【０１２３】次に，ステップ342では，SQL文のSELECT
句，WHERE句，GROUPBY句，HAVING句などに記載するカラ
ムがFROM句に記載する表に存在することをチェックす
る。仮想表SQLの場合にはDB表カラムがDB表内に存在す
ること，レプリカ表SQLの場合には仮想表カラムが仮想
表内に存在することをチェックする。当該カラムが表内
に存在する場合にはステップ343に移行し，存在しない
場合には，ステップ348に移行する。

【０１２４】次に，ステップ343では，仮想表SQL文のSE
LECT句に記載するDB表カラムまたは式の数が，仮想表に
包含される仮想表カラム（表要素のカラム）の数と一致
することをチェックする。レプリカ表SQLの場合は，レ
プリカ表SQLからレプリカ表カラムが生成されるので，
同様のチェックを行う必要はない。当該DB表カラム数ま
たは式が仮想表カラム数と一致する場合にはステップ34
4に移行し，一致しない場合には，ステップ348に移行す
る。

【０１２５】次に，ステップ344では，仮想表SQL文のSE
LECT句に記載するDB表カラムまたは式のデータ型が，仮
想表に包含される仮想表カラム（表要素のカラム）のデ
ータ型と同一またキャスト可能であることをチェックす
る。レプリカ表SQL183の場合は，レプリカ表SQLからレ
プリカ表カラムが生成されるので，同様のチェックを行
う必要はない。データ型が同一またはキャスト可能であ
る場合にはステップ345に移行し，一致しない場合に
は，ステップ348に移行する。

【０１２６】次に，ステップ345では，SQL文のWHERE
句，GROUPBY句，HAVING句などの条件式に記載されるカ
ラムや定数のデータ型が正しいことをチェックする。具
体的には，同じ条件式にあるカラムや定数のデータ型が
互いに同一またはキャスト可能であることをチェック
し，同一またはキャスト可能である場合にはステップ34
6に移行し，一致しない場合には，ステップ348に移行す
る。

【０１２７】次に，ステップ346では，同じくSQL文のWH
ERE句，GROUPBY句，HAVING句などの条件式に記載される
カラムや定数の値の範囲が正しいことをチェックする。
値の範囲が正しい場合にはステップ347に移行し，一致
しない場合には，ステップ348に移行する。

【０１２８】次に，ステップ347では，全てのチェック
をパスしたので，正常を返す。また，ステップ348で
は，いずれかのチェックでエラーが発生したので，エラ
ーを返す。

【０１２９】図１５と図１６は，エラー自動解決処理36
0の流れを表す説明図である。以下，各処理ごとに説明
する。

【０１３０】ステップ361〜366は，共通DB表カラムにお
けるエラーを解決する処理である。ここでは，共通DB表
カラムが正しいコンバータ情報を参照していないために
生じるエラーを解決する。

【０１３１】まず，ステップ362では，共通DB表カラム
に適切なコンバータ情報を検索する。例えば，型変換コ
ンバータを検索する場合には，要素データ型と共通デー
タ型をキーに検索する。

【０１３２】ステップ363では，適切なコンバータ情報
が統合スキーマ12内に存在した場合にステップ366に移
行し，存在しない場合にステップ364に移行する。

【０１３３】ステップ364では，型変換や値変換の条件
に合致するコンバータ情報を作成する。例えば，型変換
コンバータを作成する場合には，コンバータ情報の入出
力パラメータのデータ型に要素データ型及び共通データ
型を設定する。なお，ここでは，コンバータそのものを
作成するわけではなく，コンバータの外部仕様であるコ
ンバータ情報を作成することに注意する。

【０１３４】ステップ365では，当該コンバータ情報を
コンバータのヘッダファイルとして出力する。丁度，コ
ンバータ情報を登録する場合と逆の処理である。ユーザ
は，このヘッダファイルに基づき，コンバータを開発す
る必要がある。

【０１３５】ステップ366では，検索または作成した当
該コンバータ情報をエラーとなった共通DB表カラムに設
定する。

【０１３６】以上の処理により，マルチデータベース定
義手段1では，共通DB表カラムのエラーが解消される
が，コンバータ情報をヘッダファイルとして出力する場
合，当該ヘッダファイルに基づいてコンバータが開発さ
れない限り，システム全体としてはエラー状態のままで
ある。

【０１３７】次に，図１６に記載するステップ371〜377
は，仮想表SQLにおけるエラーを解決する処理である。
ここでは，仮想表SQLに記載するDB表またはDB表カラム
が統合スキーマ内に存在しないために生じるエラーを解
決する。

【０１３８】まず，ステップ372では，仮想表SQLに記載
のDB表とDB表カラムを統合スキーマに未登録（すなわち
統合スキーマ外）のDBの要素スキーマから検索する。こ
の時，DB表やDB表カラムの名前だけでなく，DB表カラム
のデータ型や値の範囲も適切であるものを検索する。こ
の場合の検索手段としては，DB定義手段を使用する場合
と，マルチデータベース定義手段1が直接，各DBのシス
テムテーブルを検索する場合がある。

【０１３９】ステップ373では，適切なDB表やDB表カラ
ムが統合スキーマ外の要素スキーマに存在した場合にス
テップ374に移行し，存在しない場合にステップ375に移
行する。

【０１４０】ステップ374では，当該要素スキーマを統
合スキーマに登録する。この時の処理は，要素スキーマ
登録処理240と同一である。

【０１４１】ステップ375では，統合スキーマ外にも存
在しなかったDB表とDB表カラムを統合スキーマ内に作成
する。なお，ここでは，DB表とDB表カラムそのものを作
成するわけではなく，DB表とDB表カラムの定義情報を作
成することに注意する。

【０１４２】ステップ376では，新たに作成した当該DB
表とDB表カラムの定義情報を要素スキーマファイルとし
て出力する。丁度，要素スキーマを登録する場合と逆の
処理である。ユーザは，この要素スキーマファイルに基
づき，実際のDBを作成する必要がある。

【０１４３】ステップ377では，先にエラーとなってい
る仮想表SQLを当該DB表とDB表カラムを使ってそのまま
再定義する。

【０１４４】以上の処理により，マルチデータベース定
義手段1では，仮想表SQLのエラーが解消されるが，要素
スキーマを出力する場合，当該要素スキーマファイルに
基づいてDBが開発されない限り，システム全体としては
エラー状態のままである。

【０１４５】次に，図１６に記載するステップ381〜383
は，レプリカ表SQLにおけるエラーを解決する処理であ
る。ここでは，レプリカ表SQLに記載する仮想表または
仮想表カラムが統合スキーマ内に存在しないために生じ
るエラーを解決する。

【０１４６】まず，ステップ382では，レプリカ表SQLに
記載の仮想表及び仮想表カラムを統合スキーマ内に作成
する。なお，ここでは，仮想表と仮想表カラムそのもの
を作成するわけではなく，仮想表と仮想表カラムの定義
情報を作成することに注意する。

【０１４７】ステップ383では，先にエラーとなってい
るレプリカ表SQLを当該仮想表と仮想表カラムを使って
そのまま再定義する。

【０１４８】以上の処理により，マルチデータベース定
義手段1では，レプリカ表SQLのエラーが解消されるが，
作成された仮想表と仮想表カラムが統合スキーマ内で定
義されない限り，システム全体としてはエラー状態のま
まである。

【０１４９】以上述べたエラー自動解決処理360は，本
実施例の特徴である。

【０１５０】図１７は，エラー自動除去処理390の流れ
を表す説明図である。以下，各処理ごとに説明する。

【０１５１】まず，ステップ392では，エラーとなった
全ての共通DB表カラムとそれを包含するDB表カラムを統
合スキーマから削除する。ここで，統合スキーマからDB
表カラムを削除しても，DBの要素スキーマからDB表カラ
ムを除去するわけではないので，DBに対する影響はまっ
たく生じない。次に，ステップ393では，当該DB表カラ
ムを参照する仮想表SQLをエラーに再設定する。

【０１５２】同様に，ステップ395では，エラーとなっ
た全ての仮想表SQLとそれを包含する仮想表を統合スキ
ーマから削除する。また，仮想表が包含する仮想表カラ
ムも結果的に削除される。次に，ステップ396では，当
該仮想表及び仮想表カラムを参照するレプリカ表SQLを
エラーに再設定する。

【０１５３】同様に，ステップ398では，エラーとなっ
た全てのレプリカ表SQLとそれを包含するレプリカ表を
統合スキーマから削除する。

【０１５４】以上の処理の結果，統合スキーマからエラ
ーとなったデータ項目を除去することができ，論理的に
は統合スキーマは正しいデータ項目のみを含むことにな
る。

【０１５５】また，他の実施の形態として，ステップ39
2，395，398において，データを自動的に削除する場合
には必ずその旨メッセージを表示し，ユーザの承認を得
た後に実際の削除を行うとともに，ユーザが承認しない
場合には，エラー自動除去処理390そのものもキャンセ
ルする形態も有り得る。

【０１５６】エラー自動除去処理390は，本実施例の特
徴である。

【０１５７】外部スキーマ出力処理400は，AP開発手段
とのインタフェースを担う処理であり，具体的には，外
部スキーマファイルを出力する処理である。AP開発手段
では，外部スキーマをAP開発に活用する。

【０１５８】図１８は，外部スキーマ出力処理400の流
れを表す説明図である。以下，各処理ごとに説明する。

【０１５９】まず，ステップ401では，ユーザがAPシス
テム情報を選択する。次に，ステップ402では，当該AP
システム情報が包含する仮想表及び仮想表カラムの定義
情報を例えばCSV形式などでファイル出力する。そし
て，ステップ403では，APシステム情報の外部スキーマ
出力済フラグをオンにする。この外部スキーマ出力済フ
ラグは，外部スキーマ出力後にユーザが当該外部スキー
マに含まれる仮想表や仮想表カラムを編集しようとした
場合に警告メッセージを出力するために用いられる。警
告メッセージの内容は，例えば，「外部スキーマが既に
出力されています。このまま仮想表の編集を継続する
と，アプリケーションに影響が及ぶ場合があります．」
などである。

【０１６０】外部スキーマ出力処理400の操作方法とし
ては，例えば，ユーザが図２１の外部スキーマ・ツリー
ビュー511でAP名「AP1」を選択し，メニューから「外部
スキーマファイル出力」を実行する。そして，図２１に
は記載していないファイル出力ダイアログが表示される
ので，ユーザがファイル名を入力し，ファイルの出力を
実行する。

【０１６１】レプリカ表スキーマ出力処理410は，ジョ
ブ定義手段とのインタフェースを担う処理であり，具体
的には，レプリカ表スキーマファイルを出力する処理で
ある。ジョブ定義手段では，レプリカ表スキーマをレプ
リカ表作成・更新ジョブの定義に活用する。

【０１６２】図１９は，レプリカ表スキーマ出力処理41
0の流れを表す説明図である。以下，各処理ごとに説明
する。

【０１６３】まず，ステップ411では，ユーザがAPシス
テム情報を選択する。次に，ステップ412では，当該AP
システム情報が包含するレプリカ表とレプリカ表SQLの
定義情報を例えばCSV形式などでファイル出力する。そ
して，ステップ413では，APシステム情報のレプリカ表
スキーマ出力済フラグをオンにする。このレプリカ表ス
キーマ出力済フラグは，レプリカ表スキーマ出力後にユ
ーザが当該レプリカ表スキーマに含まれるレプリカ表や
レプリカ表SQLを編集しようとした場合に警告メッセー
ジを出力するために用いられる。警告メッセージの内容
は，例えば，「レプリカ表スキーマが既に出力されてい
ます。このままレプリカ表の編集を継続すると，レプリ
カ表を作成・更新するジョブに影響が及ぶ場合がありま
す．」などである。

【０１６４】レプリカ表スキーマ出力処理410の操作方
法としては，例えば，ユーザが図２２の外部スキーマ・
ツリービュー511でAP名「AP1」を選択し，メニューから
「レプリカ表スキーマファイル出力」を実行する。そし
て，図２２には記載していないファイル出力ダイアログ
が表示されるので，ユーザがファイル名を入力し，ファ
イルの出力を実行する。

【０１６５】以上に述べた本発明のマルチデータベース
定義方法を実行するプログラムを計算機で読取り可能な
記録媒体に格納し、メモリに読み込んで実行することも
可能である。

【０１６６】

【発明の効果】本発明により，マルチデータベースを実
行するために必要な統合スキーマをユーザが簡易に定義
できるようになる。また，マルチデータベースを使用す
るアプリケーションの開発を効率化できるようになる。
また，信頼性の高い統合スキーマを出力することができ
るので，マルチデータベースシステム全体の信頼性が高
まる。さらに，ユーザがレプリカ表スキーマを定義する
ことができるので，外部スキーマをあらかじめ実体化し
ておくことが可能になり，結果的にAPから見たデータへ
のアクセス性能が向上する。

【図面の簡単な説明】

【図１】ハブ＆スポーク型のアーキテクチャに基づくマ
ルチデータベースの概念モデルを表す説明図である。

【図２】本発明の一実施例に関わるマルチデータベース
システム全体のソフトウェア構成を表す説明図である。

【図３】本発明の一実施例に関わるマルチデータベース
システム全体のハードウェア構成を表す説明図である。

【図４】本発明の一実施例に関わるマルチデータベース
定義手段1のデータモデルを表す説明図である。

【図５】本発明の一実施例に関わるマルチデータベース
定義手段1における全体の処理の流れを表す説明図であ
る。

【図６】本発明の一実施例に関わるマルチデータベース
定義手段1における編集処理210の流れを表す説明図であ
る。

【図７】本発明の一実施例に関わるマルチデータベース
定義手段1における反映処理220の流れを表す説明図であ
る。

【図８】本発明の一実施例に関わるマルチデータベース
定義手段1における要素スキーマ登録処理240の流れを表
す説明図である。

【図９】本発明の一実施例に関わるマルチデータベース
定義手段1における外部スキーマ登録処理250の流れを表
す説明図である。

【図１０】本発明の一実施例に関わるマルチデータベー
ス定義手段1におけるレプリカ表スキーマ登録処理260の
流れを表す説明図である。

【図１１】本発明の一実施例に関わるマルチデータベー
ス定義手段1における関連データ変更処理270の流れを表
す説明図である。

【図１２】本発明の一実施例に関わるマルチデータベー
ス定義手段1における統合スキーマ出力処理300の流れを
表す説明図である。

【図１３】本発明の一実施例に関わるマルチデータベー
ス定義手段1における検査処理320の流れを表す説明図で
ある。

【図１４】本発明の一実施例に関わるマルチデータベー
ス定義手段1における意味チェック処理340の流れを表す
説明図である。

【図１５】本発明の一実施例に関わるマルチデータベー
ス定義手段1におけるエラー自動解決処理360の流れを表
す説明図（その１）である。

【図１６】本発明の一実施例に関わるマルチデータベー
ス定義手段1におけるエラー自動解決処理360の流れを表
す説明図（その２）である。

【図１７】本発明の一実施例に関わるマルチデータベー
ス定義手段1におけるエラー自動除去処理390の流れを表
す説明図である。

【図１８】本発明の一実施例に関わるマルチデータベー
ス定義手段1における外部スキーマ出力処理400の流れを
表す説明図である。

【図１９】本発明の一実施例に関わるマルチデータベー
ス定義手段1におけるレプリカ表スキーマ出力処理410の
流れを表す説明図である。

【図２０】本発明の一実施例に関わるマルチデータベー
ス定義手段1における要素スキーマ登録画面を表す説明
図である。

【図２１】本発明の一実施例に関わるマルチデータベー
ス定義手段1における外部スキーマ登録画面を表す説明
図である。

【図２２】本発明の一実施例に関わるマルチデータベー
ス定義手段1におけるレプリカ表スキーマ登録画面を表
す説明図である。

【図２３】本発明の一実施例に関わるマルチデータベー
ス定義手段1における検査結果の画面を表す説明図であ
る。

【符号の説明】

1…マルチデータベース定義手段，2…編集ファイル，10
…マルチデータベースサーバ，11…内部データベース
（内部DB），12…統合スキーマ，13…レプリカ表，20…
データベース定義手段（DB定義手段），21〜23…データ
ベース（DB），24〜26…要素スキーマ，30…コンバータ
解決手段，31…コンバータ，40…アプリケーション開発
手段（AP開発手段），41〜43…アプリケーション（A
P），44〜46…外部スキーマ，50…ジョブ定義手段，51
…レプリカ表作成・更新ジョブ，61〜63…データベース
・アダプタ，71〜73…アプリケーション・アダプタ，10
0…マルチデータベースシステム，101…LAN，102…WA
N，111〜112…クライアント計算機，121〜127…サーバ
計算機，131〜134…データベース管理システム（DBM
S），135…アプリケーションクライアント（APクライア
ント），150…コンバータ情報，160…データベースシス
テム情報（DBシステム情報），161…データベース表（D
B表），162…データベース表カラム（DB表カラム），16
3…共通DB表カラム，164…DB表宣言名，170…アプリケ
ーションシステム情報（APシステム情報），171…仮想
表，172…仮想表カラム，173…仮想表SQL，181…レプリ
カ表，182…レプリカ表カラム，183…レプリカ表SQL，1
84…定義状況，210…編集処理，220…反映処理，230…
コンバータ情報登録処理，240…要素スキーマ登録処
理，250…外部スキーマ登録処理，260…レプリカ表スキ
ーマ登録処理，270…関連データ変更処理，300…統合ス
キーマ出力処理，320…検査処理，340…意味チェック処
理，360…エラー自動解決処理，390…エラー自動除去処
理，400…外部スキーマ出力処理，410…レプリカ表スキ
ーマ出力処理，500…要素スキーマ登録ウィンドウ，501
…要素スキーマ・ツリービュー，502…要素スキーマ・
リストビュー，510…外部スキーマ登録ウィンドウ，511
…外部スキーマ・ツリービュー，512…外部スキーマ・
リストビュー，513…外部スキーマ・テキストボック
ス，520…レプリカ表スキーマ登録ウィンドウ，521…レ
プリカ表スキーマ・ツリービュー，523…レプリカ表ス
キーマ・テキストボックス，530…検査ウィンドウ，531
…検査結果・リストビュー

───────────────────────────────────────────────────── フロントページの続き (72)発明者林重年神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウェア事業部内 (72)発明者畑沢孝秋田県南秋田郡天王町天王字長沼64 アキタ電子株式会社内Ｆターム(参考） 5B082 GA06 GA07

Claims

【特許請求の範囲】

【請求項１】複数のデータベースが連携して動作するマ
ルチデータベースの定義方法であって，各データベース
の物理的な構成情報を取得し，アプリケーションが参照
する論理的なデータベースの構成情報を定義し，前記論
理的な構成情報から物理的な構成情報に対する参照関係
を定義し，マルチデータベースの実行手段に定義情報を
格納する際には，当該参照関係を検査し，参照先のデー
タの有無に応じて，定義情報の格納を制御することを特
徴とするマルチデータベース定義方法。
【請求項２】請求項１において，各データベースの物理
的な構成情報を登録する際には，定義情報の中でデータ
ベース表の宣言名を一意に定義し，前記参照関係では、
当該宣言名を用いて定義することを特徴とする請求項１
記載のマルチデータベース定義方法。
【請求項３】請求項１において、各データベースの物理的な構成情報を取得する際には、
データベース表カラムのデータ型を共通のデータ型に対
応付けることを特徴とする請求項１記載のマルチデータ
ベース定義方法。
【請求項４】請求項３において，各データベースの物理
的な構成情報を登録する際には，データベース表カラム
のデータ値を変換する関数を対応付けることを特徴とす
る請求項３記載のマルチデータベース定義方法。
【請求項５】請求項１において，マルチデータベースの
実行手段に定義情報を格納する際には，前記参照関係を
検査し，他のデータから参照されているデータのみを抽
出して格納することを特徴とする請求項１記載のマルチ
データベース定義方法。
【請求項６】請求項１において，参照先のデータが存在
しない参照関係をもとにデータベースの物理的な構成情
報を作成することを特徴とする請求項１記載のマルチデ
ータベース定義方法。
【請求項７】請求項１において，参照先のデータが存在
しない参照関係をもとにアプリケーションが参照する論
理的なデータベースの構成情報を変更することを特徴と
する請求項１記載のマルチデータベース定義方法。
【請求項８】請求項１において、アプリケーションが参
照する論理的なデータベースのうち実体化する範囲を定
義し、マルチデータベースの実行手段に定義情報を格納する際
には、当該実行手段が現在使用中の定義情報と比較し、
前記実体化する範囲の定義の差異点を検出することを特
徴とする請求項１記載のマルチデータベース定義方法。
【請求項９】複数のデータベースが連携して動作するマ
ルチデータベースの定義方法であって，各データベース
の要素スキーマを登録し，表の宣言名を一意に定義し，
カラムを共通のデータ型に対応付け，アプリケーション
の外部スキーマを定義・登録し，前記宣言名を使って外
部スキーマから要素スキーマへのマップを定義し，外部
スキーマを実体化する範囲を規定するレプリカ表スキー
マを定義・登録し，レプリカ表スキーマから外部スキー
マへのマップを定義し、マルチデータベースサーバに全
スキーマを出力する際には，外部スキーマが参照する要
素スキーマ及びレプリカ表スキーマが参照する外部スキ
ーマが正しく存在することを検査し，全スキーマ内で外
部スキーマから参照される要素スキーマのデータのみを
抽出して出力することを特徴とするマルチデータベース
定義方法。
【請求項１０】複数のデータベースが連携して動作する
マルチデータベースの定義方法を実行するプログラムを
格納した、計算機で読取り可能な記録媒体であって、前
記定義方法は，各データベースの物理的な構成情報を取
得し，アプリケーションが参照する論理的なデータベー
スの構成情報を定義し，前記論理的な構成情報から物理
的な構成情報に対する参照関係を定義し，マルチデータ
ベースの実行手段に定義情報を格納する際には，当該参
照関係を検査し，参照先のデータの有無に応じて，定義
情報の格納を制御することを特徴とする記録媒体。