JP2002149468A - マルチデータベース統合システムのアクセス権管理方法 - Google Patents
マルチデータベース統合システムのアクセス権管理方法Info
- Publication number
- JP2002149468A JP2002149468A JP2000342373A JP2000342373A JP2002149468A JP 2002149468 A JP2002149468 A JP 2002149468A JP 2000342373 A JP2000342373 A JP 2000342373A JP 2000342373 A JP2000342373 A JP 2000342373A JP 2002149468 A JP2002149468 A JP 2002149468A
- Authority
- JP
- Japan
- Prior art keywords
- access right
- database
- virtual table
- user name
- dbms
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
(57)【要約】
【課題】システム構築を行なう際、マルチデータベース
統合システム上にて構築されるアプリケーション(AP)
側と統合対象データベース管理システム(DBMS)側の管
理組織が異なる場合がある。こうした場合、AP側と統合
対象DBMS間の接続を行なうには、それぞれ独立した形態
でシステム構築作業を進められることが望ましい。 【解決手段】本発明では、仮想表アクセス権、スポーク
DBアクセス権、およびこれらを対応づけるアクセス権マ
ッピング情報を定義する手段と管理する手段を設ける。
そして上記情報の定義内容を用いることにより、仮想表
レベルでのアクセス権判定を行なう処理部と、仮想表ア
クセス権からスポークDBアクセス権への変換処理部を設
ける。本発明により、容易にAP側と統合対象DBMSのシス
テム構築作業を並列に行なうことができ、システム構築
作業の負荷を低減する。
統合システム上にて構築されるアプリケーション(AP)
側と統合対象データベース管理システム(DBMS)側の管
理組織が異なる場合がある。こうした場合、AP側と統合
対象DBMS間の接続を行なうには、それぞれ独立した形態
でシステム構築作業を進められることが望ましい。 【解決手段】本発明では、仮想表アクセス権、スポーク
DBアクセス権、およびこれらを対応づけるアクセス権マ
ッピング情報を定義する手段と管理する手段を設ける。
そして上記情報の定義内容を用いることにより、仮想表
レベルでのアクセス権判定を行なう処理部と、仮想表ア
クセス権からスポークDBアクセス権への変換処理部を設
ける。本発明により、容易にAP側と統合対象DBMSのシス
テム構築作業を並列に行なうことができ、システム構築
作業の負荷を低減する。
Description
【0001】
【発明の属する技術分野】本発明は、マルチデータベー
ス統合システムにおけるアクセス権管理方法に関する。
ス統合システムにおけるアクセス権管理方法に関する。
【0002】
【従来の技術】従来技術として、複数のデータベース管
理システム(以下、DBMSと略す)を一つのデータベース
に統合するマルチデータベース統合システムが知られて
いる。例えば、特開平8−16439「異なるデータベ
ースシステム間でのデータ共有装置及び方法」に述べら
れている。こうしたマルチデータベース統合システムを
利用することにより、複数DBMSを利用したアプリケーシ
ョン(以下APと略す)を容易に開発できる。マルチデー
タベース統合システムに対してのみ検索処理を行なうこ
とにより、複数DBMSからの検索結果を取得できる。こう
したマルチデータベース統合システムでは、実際のデー
タ取得を統合対象となる複数データベースから得るため
に、統合対象となるデータベースに対するアクセス制御
を行なう必要がある。
理システム(以下、DBMSと略す)を一つのデータベース
に統合するマルチデータベース統合システムが知られて
いる。例えば、特開平8−16439「異なるデータベ
ースシステム間でのデータ共有装置及び方法」に述べら
れている。こうしたマルチデータベース統合システムを
利用することにより、複数DBMSを利用したアプリケーシ
ョン(以下APと略す)を容易に開発できる。マルチデー
タベース統合システムに対してのみ検索処理を行なうこ
とにより、複数DBMSからの検索結果を取得できる。こう
したマルチデータベース統合システムでは、実際のデー
タ取得を統合対象となる複数データベースから得るため
に、統合対象となるデータベースに対するアクセス制御
を行なう必要がある。
【0003】従来のマルチデータベース統合システムで
は、マルチデータベース統合システムに対するユーザ名
を、統合対象となるデータベースのユーザ名に変換する
ことにより、統合対象データベースとの接続および表へ
のアクセス制御を行なっている。この際、マルチデータ
ベース統合システムに対するアクセス権が成立するか否
かは、変換されたユーザ名がおのおのの統合対象DBMSに
てアクセスできるか否かに基づいて行なわれる。Intern
ational Standardization Organization(以下ISOと略
す)で定めるDatabase LangageSQLのSQL/MEDの規格で
は、マルチデータベース統合システムに対するユーザ名
を、統合対象となるデータベースのユーザ名に対応させ
るマッピング定義について述べられている。
は、マルチデータベース統合システムに対するユーザ名
を、統合対象となるデータベースのユーザ名に変換する
ことにより、統合対象データベースとの接続および表へ
のアクセス制御を行なっている。この際、マルチデータ
ベース統合システムに対するアクセス権が成立するか否
かは、変換されたユーザ名がおのおのの統合対象DBMSに
てアクセスできるか否かに基づいて行なわれる。Intern
ational Standardization Organization(以下ISOと略
す)で定めるDatabase LangageSQLのSQL/MEDの規格で
は、マルチデータベース統合システムに対するユーザ名
を、統合対象となるデータベースのユーザ名に対応させ
るマッピング定義について述べられている。
【0004】
【発明が解決しようとする課題】システム構築を行なう
際、マルチデータベース統合システム上にて構築される
AP側と統合対象DBMS側の管理組織が異なる場合がある。
こうした場合、AP側と統合対象DBMS間の接続を行なうに
は、それぞれ独立した形態でシステム構築作業を進めら
れることが望ましい。しかし従来システムでは、マルチ
データベース統合システムに対するユーザ名を、統合対
象DBMS上のユーザ名に直接対応づけるため、統合対象ユ
ーザ統合対象側DBMSのアクセス権が定義できない限り、
AP側の利用形態に応じたアクセス権定義がおこなえな
い。このため、AP側と統合対象DBMSのシステム構築作業
を独立にすすめることができず、効率的なシステム開発
を行なえない場合がある。
際、マルチデータベース統合システム上にて構築される
AP側と統合対象DBMS側の管理組織が異なる場合がある。
こうした場合、AP側と統合対象DBMS間の接続を行なうに
は、それぞれ独立した形態でシステム構築作業を進めら
れることが望ましい。しかし従来システムでは、マルチ
データベース統合システムに対するユーザ名を、統合対
象DBMS上のユーザ名に直接対応づけるため、統合対象ユ
ーザ統合対象側DBMSのアクセス権が定義できない限り、
AP側の利用形態に応じたアクセス権定義がおこなえな
い。このため、AP側と統合対象DBMSのシステム構築作業
を独立にすすめることができず、効率的なシステム開発
を行なえない場合がある。
【0005】また、従来のアクセス権管理方法では、統
合対象DBMS 側のログ情報を用いて、AP側のユーザを区
別するための設定が煩雑な場合がある。例えば、「同一
組織内のAPからマルチデータベース統合システム上を経
由して統合対象DBMSを利用するユーザ」と、「他組織の
APからマルチデータベース統合システムを経由して統合
対象DBMSを利用するユーザ」を区別するための設定を行
なうには、AP側と統合対象DBMSのユーザ設計を同時に行
なう必要がある。こうした作業の煩雑さのため、上記区
別を行なうための設定が行なわれず、このためスポーク
DB側でセキュリティ上の問題が発生した場合には、捜査
対象となるユーザグループの分類を行なえない場合があ
る。
合対象DBMS 側のログ情報を用いて、AP側のユーザを区
別するための設定が煩雑な場合がある。例えば、「同一
組織内のAPからマルチデータベース統合システム上を経
由して統合対象DBMSを利用するユーザ」と、「他組織の
APからマルチデータベース統合システムを経由して統合
対象DBMSを利用するユーザ」を区別するための設定を行
なうには、AP側と統合対象DBMSのユーザ設計を同時に行
なう必要がある。こうした作業の煩雑さのため、上記区
別を行なうための設定が行なわれず、このためスポーク
DB側でセキュリティ上の問題が発生した場合には、捜査
対象となるユーザグループの分類を行なえない場合があ
る。
【0006】また、マルチデータベース統合システム上
にて構築されるAP側と統合対象DBMS側の管理組織が異な
る場合には、統合対象DBMS上のユーザ名に対して表操作
権限の変更や、ユーザ名そのものの削除などが、AP利用
者に通知されないまま、行なわれることがあるが、従来
技術では、こうした際に生じる不整合を検出し、修復す
る手段をもっていない。
にて構築されるAP側と統合対象DBMS側の管理組織が異な
る場合には、統合対象DBMS上のユーザ名に対して表操作
権限の変更や、ユーザ名そのものの削除などが、AP利用
者に通知されないまま、行なわれることがあるが、従来
技術では、こうした際に生じる不整合を検出し、修復す
る手段をもっていない。
【0007】本発明の目的は、AP側と結合対象DBM
Sのシステム構築を独立に進めることができるマルチデ
ータベース統合システムのアクセス権管理方法を提供す
ることにある。
Sのシステム構築を独立に進めることができるマルチデ
ータベース統合システムのアクセス権管理方法を提供す
ることにある。
【0008】
【課題を解決するための手段】本発明は、マルチデータ
ベース統合部の定義情報を定義する定義部、定義部の定
義情報を格納する定義DB、複数データベースの統合を行
なうマルチデータベース統合部よりなる。
ベース統合部の定義情報を定義する定義部、定義部の定
義情報を格納する定義DB、複数データベースの統合を行
なうマルチデータベース統合部よりなる。
【0009】定義部は、アクセス権マッピング定義部
と、定義時アクセス権マッピングの整合性チェック部よ
りなる。アクセス権マッピング定義部は、マルチデータ
ベース統合部上にて管理する仮想表に対するアクセス権
と、統合対象DBMS上の実表に対するアクセス権とを対応
づけ、対応関係を保存する処理を行なう。定義時アクセ
ス権マッピングの整合性チェック部は、上記で定義した
対応づけ関係に基づいて仮想表に対するアクセス権と、
実表に対するアクセス権間で不整合が生じていないかを
判定し、不整合を検出した場合には定義処理をおこなっ
ているユーザにその旨を通知し、不整合の修復を支援す
る。
と、定義時アクセス権マッピングの整合性チェック部よ
りなる。アクセス権マッピング定義部は、マルチデータ
ベース統合部上にて管理する仮想表に対するアクセス権
と、統合対象DBMS上の実表に対するアクセス権とを対応
づけ、対応関係を保存する処理を行なう。定義時アクセ
ス権マッピングの整合性チェック部は、上記で定義した
対応づけ関係に基づいて仮想表に対するアクセス権と、
実表に対するアクセス権間で不整合が生じていないかを
判定し、不整合を検出した場合には定義処理をおこなっ
ているユーザにその旨を通知し、不整合の修復を支援す
る。
【0010】定義DBは、DBMS情報、ユーザ情報、仮想表
定義、仮想表アクセス権、アクセス権マッピングを保持
する。DBMS情報では、統合対象DBMSの管理情報を保持す
る。ユーザ情報では、仮想表ユーザを管理する。仮想表
定義では、仮想表の定義を格納する。仮想表アクセス権
では、仮想表に対するアクセス権を管理する。アクセス
権マッピングでは、仮想表アクセス権と統合対象DBMSの
アクセス権との対応関係を保持する。
定義、仮想表アクセス権、アクセス権マッピングを保持
する。DBMS情報では、統合対象DBMSの管理情報を保持す
る。ユーザ情報では、仮想表ユーザを管理する。仮想表
定義では、仮想表の定義を格納する。仮想表アクセス権
では、仮想表に対するアクセス権を管理する。アクセス
権マッピングでは、仮想表アクセス権と統合対象DBMSの
アクセス権との対応関係を保持する。
【0011】マルチデータベース統合部は、実行時アク
セス権マッピングの整合性チェック部、仮想表アクセス
権判定部、アクセス権変換部よりなる。実行時アクセス
権マッピングの整合性チェック部では、実行時の環境に
おいて、定義したアクセス権マッピングに不整合がない
かを検出し、不整合を検出した場合には可能な範囲での
修復処理を行なう。仮想表アクセス権判定部では、AP側
で利用する仮想表に対するアクセス権判定を行なう。ア
クセス権変換部では、仮想表アクセス権を統合対象とな
るDBMSへのアクセス権に変換する処理を行なう。
セス権マッピングの整合性チェック部、仮想表アクセス
権判定部、アクセス権変換部よりなる。実行時アクセス
権マッピングの整合性チェック部では、実行時の環境に
おいて、定義したアクセス権マッピングに不整合がない
かを検出し、不整合を検出した場合には可能な範囲での
修復処理を行なう。仮想表アクセス権判定部では、AP側
で利用する仮想表に対するアクセス権判定を行なう。ア
クセス権変換部では、仮想表アクセス権を統合対象とな
るDBMSへのアクセス権に変換する処理を行なう。
【0012】
【発明の実施の形態】本実施例のアクセス権制御システ
ムは、マルチデータベース統合システムにおける仮想表
へのアクセス権制御を実現するシステムである。ここで
いうマルチデータベースシステムとは、複数のデータベ
ース管理システム(以下DBMSと略す)に格納した表を組
み合わせ、仮想表と呼ぶ一つの表を定義し、システム利
用者がこの仮想表に対してDBMSの操作言語であるSQLな
どを用いることで、レコード情報の検索(SELECT)、更
新(UPDATE)、削除(DELETE)、新規作成(INSERT)な
どの問い合わせ処理を行なうシステムのことである。従
来のDBMSでは、実データを格納している表に対して、複
数の表を仮想的に組み合わすビューとよばれる概念があ
る。マルチデータベースシステムの仮想表は、異なるDB
MS上の表に対するビューとして定義する。更にマルチデ
ータベースシステムでは、上述した仮想表に対して、従
来のDBMSと同様に仮想表に対する操作権限をもつユーザ
や表操作権限の種別を対応づけ、仮想表に対するアクセ
ス権情報の管理を行なう。なお、ここでいうアクセス権
情報とは、表、ビュー、および仮想表、に対して、DBMS
もしくはマルチデータベースシステムのユーザが、どの
ようなSQL操作種別(SELECT、UPDATE、DELETE、INSER
T)を行なえばよいかを対応づけた情報のことである。
特に仮想表に対するアクセス権情報のことを、仮想表ア
クセス権と呼ぶことにする。そして統合対象のDBMS上の
表およびビューに対するアクセス権をDBMSアクセス権と
よぶことにする。
ムは、マルチデータベース統合システムにおける仮想表
へのアクセス権制御を実現するシステムである。ここで
いうマルチデータベースシステムとは、複数のデータベ
ース管理システム(以下DBMSと略す)に格納した表を組
み合わせ、仮想表と呼ぶ一つの表を定義し、システム利
用者がこの仮想表に対してDBMSの操作言語であるSQLな
どを用いることで、レコード情報の検索(SELECT)、更
新(UPDATE)、削除(DELETE)、新規作成(INSERT)な
どの問い合わせ処理を行なうシステムのことである。従
来のDBMSでは、実データを格納している表に対して、複
数の表を仮想的に組み合わすビューとよばれる概念があ
る。マルチデータベースシステムの仮想表は、異なるDB
MS上の表に対するビューとして定義する。更にマルチデ
ータベースシステムでは、上述した仮想表に対して、従
来のDBMSと同様に仮想表に対する操作権限をもつユーザ
や表操作権限の種別を対応づけ、仮想表に対するアクセ
ス権情報の管理を行なう。なお、ここでいうアクセス権
情報とは、表、ビュー、および仮想表、に対して、DBMS
もしくはマルチデータベースシステムのユーザが、どの
ようなSQL操作種別(SELECT、UPDATE、DELETE、INSER
T)を行なえばよいかを対応づけた情報のことである。
特に仮想表に対するアクセス権情報のことを、仮想表ア
クセス権と呼ぶことにする。そして統合対象のDBMS上の
表およびビューに対するアクセス権をDBMSアクセス権と
よぶことにする。
【0013】以下では、図1を用いて本発明におけるマ
ルチデータベース統合システムの概略動作説明を行う。
ルチデータベース統合システムの概略動作説明を行う。
【0014】図1の定義部10では、定義DB20に対し
て、アクセス権マッピング25などの定義情報を登録す
る。登録するにあたっては、アクセス権マッピング25
に不整合がないかのチェックを行う。
て、アクセス権マッピング25などの定義情報を登録す
る。登録するにあたっては、アクセス権マッピング25
に不整合がないかのチェックを行う。
【0015】図1のマルチデータベース統合部30で
は、実行時のデータベース統合処理を行なう。図1のAP
60は仮想表を利用したアプリケーションを示してい
る。AP60からマルチデータベース統合部30に対し
て、仮想表に対する操作を行うに当たっては、まずユー
ザ名、パスワードを用いたログイン処理を行う。図1で
はAPUser1というユーザ名を用いて、AP60とマルチデ
ータベース統合部30の間で接続処理を行っている。マ
ルチデータベース統合部30では、定義DB20のユーザ
情報22に、ユーザ名APUser1およびパスワードが存在
するか否かを確認し、ユーザ情報22に該当ユーザが存
在した場合に、AP60とマルチデータベース統合部30
間の接続を確立する。
は、実行時のデータベース統合処理を行なう。図1のAP
60は仮想表を利用したアプリケーションを示してい
る。AP60からマルチデータベース統合部30に対し
て、仮想表に対する操作を行うに当たっては、まずユー
ザ名、パスワードを用いたログイン処理を行う。図1で
はAPUser1というユーザ名を用いて、AP60とマルチデ
ータベース統合部30の間で接続処理を行っている。マ
ルチデータベース統合部30では、定義DB20のユーザ
情報22に、ユーザ名APUser1およびパスワードが存在
するか否かを確認し、ユーザ情報22に該当ユーザが存
在した場合に、AP60とマルチデータベース統合部30
間の接続を確立する。
【0016】上記接続が確立した後、AP60からはマル
チデータベース統合部30に対して仮想表に対する表操
作処理を要求する。表操作処理の要求には、通常のDBMS
操作言語であるSQLを用いて行う。例えば、仮想表VT1に
対するSQLとして「SELECT* FROM VT1」を要求する。
AP60からの前記SQLを受け付けたデータベース統合部
30では、仮想表アクセス権判定32において、APUser
1に対して、仮想表VT1に対しするSELECT操作権限が、与
えられているか否かを判定する。この仮想表に対するア
クセス権の判定処理には、定義DB20の仮想表アクセス
権24を用いる。図1の仮想表アクセス権24では、AP
User1のVT1に対するSELECT、UPDATE権限が定義されお
り、前述したSQLに対しては、仮想表アクセス権が成立
するものと判定する。
チデータベース統合部30に対して仮想表に対する表操
作処理を要求する。表操作処理の要求には、通常のDBMS
操作言語であるSQLを用いて行う。例えば、仮想表VT1に
対するSQLとして「SELECT* FROM VT1」を要求する。
AP60からの前記SQLを受け付けたデータベース統合部
30では、仮想表アクセス権判定32において、APUser
1に対して、仮想表VT1に対しするSELECT操作権限が、与
えられているか否かを判定する。この仮想表に対するア
クセス権の判定処理には、定義DB20の仮想表アクセス
権24を用いる。図1の仮想表アクセス権24では、AP
User1のVT1に対するSELECT、UPDATE権限が定義されお
り、前述したSQLに対しては、仮想表アクセス権が成立
するものと判定する。
【0017】仮想表アクセス権が成立した場合、仮想表
を構成するための実データを統合対象DBMSから取得する
ための前処理として、マルチデータベース統合部30と
統合対象DBMS間の接続確立を行う必要がある。図1で
は、DBMS1(40)、DBMS2 (50)が統合対象のDBMSになって
いる。ここで注意する点は、マルチデータベース統合部
30と統合対象DBMS間の接続に必要となるユーザ名、パ
スワードは、AP60とマルチデータベース統合部30間
の接続を確立するのに用いたユーザ名APUser1と異なる
ことである。仮想表アクセス権変換33において、仮想
表アクセス権を統合対象DBMSのアクセス権に変換する処
理を行なうことにより、マルチデータベース統合部30
と統合対象DBMS間の接続に必要なユーザ名が取得する。
仮想表アクセス権変換33を行うにあたっては、定義DB
20上アクセス権マッピング25を参照する。
を構成するための実データを統合対象DBMSから取得する
ための前処理として、マルチデータベース統合部30と
統合対象DBMS間の接続確立を行う必要がある。図1で
は、DBMS1(40)、DBMS2 (50)が統合対象のDBMSになって
いる。ここで注意する点は、マルチデータベース統合部
30と統合対象DBMS間の接続に必要となるユーザ名、パ
スワードは、AP60とマルチデータベース統合部30間
の接続を確立するのに用いたユーザ名APUser1と異なる
ことである。仮想表アクセス権変換33において、仮想
表アクセス権を統合対象DBMSのアクセス権に変換する処
理を行なうことにより、マルチデータベース統合部30
と統合対象DBMS間の接続に必要なユーザ名が取得する。
仮想表アクセス権変換33を行うにあたっては、定義DB
20上アクセス権マッピング25を参照する。
【0018】仮想表アクセス権変換33により、DBMS接
続に必要なユーザ名を取得した後には、マルチデータベ
ース統合部30と統合対象DBMS間の接続を確立し、マル
チデータベース統合部30が、個々の統合対象DBMSに対
して検索処理などの表操作処理を行い、個々の統合対象
DBMSからの得た結果を、マルチデータベースシステム側
で統合し、アプリケーション側に応答する。
続に必要なユーザ名を取得した後には、マルチデータベ
ース統合部30と統合対象DBMS間の接続を確立し、マル
チデータベース統合部30が、個々の統合対象DBMSに対
して検索処理などの表操作処理を行い、個々の統合対象
DBMSからの得た結果を、マルチデータベースシステム側
で統合し、アプリケーション側に応答する。
【0019】以上が、マルチデータ統合システム30の
動作概略である。
動作概略である。
【0020】本発明は特に上記処理の内アクセス権制御
にかかわるものである。特に本発明では、アクセス権変
換として、以下の3方式について説明を行なう。これら
の方式の構成を図4、図5、図6に示す。
にかかわるものである。特に本発明では、アクセス権変
換として、以下の3方式について説明を行なう。これら
の方式の構成を図4、図5、図6に示す。
【0021】(1)仮想表単位に統合対象DBMS上のユー
ザ名を対応づける方式。図4の例では、仮想表VT1に対
して統合対象DBMS上のユーザ名DB1_User1、DB2_User1を
対応づける。
ザ名を対応づける方式。図4の例では、仮想表VT1に対
して統合対象DBMS上のユーザ名DB1_User1、DB2_User1を
対応づける。
【0022】(2)マルチデータベースのユーザ単位に
統合対象DBMS上のユーザ名を対応づける方式。図5の例
では、マルチデータベースシステムのユーザAPUser1に
対して統合DBMS上のユーザ名DB1_User1、DB2_User1を対
応づける。
統合対象DBMS上のユーザ名を対応づける方式。図5の例
では、マルチデータベースシステムのユーザAPUser1に
対して統合DBMS上のユーザ名DB1_User1、DB2_User1を対
応づける。
【0023】(3)統合対象DBMS単位に固定ユーザ名を
対応づける方式。図6に示すように、統合DBMS単位に固
定のユーザ名DB1_User1、DB2_User1を対応づける。
対応づける方式。図6に示すように、統合DBMS単位に固
定のユーザ名DB1_User1、DB2_User1を対応づける。
【0024】以下ではまず、上記(1)の方式に基づく
実施例1の形態を説明する。概略説明に用いた図1に対
し、再度詳細な説明を行う。図1に示すように実施例1
の処理ブロック図は、定義部10、定義DB20、マルチ
データベース統合部30、DBMS1 40、DBMS2 50、 A
P 60より構成される。
実施例1の形態を説明する。概略説明に用いた図1に対
し、再度詳細な説明を行う。図1に示すように実施例1
の処理ブロック図は、定義部10、定義DB20、マルチ
データベース統合部30、DBMS1 40、DBMS2 50、 A
P 60より構成される。
【0025】定義部10では、マルチデータベース統合
部30で用いる一連の定義情報の登録・修正を行なう。
定義部10での登録・修正結果は、定義DB20に保存さ
れる。定義部は、アクセス権マッピング定義11と、定
義時アクセス権マッピングの整合性チェック12よりな
る。アクセス権マッピング定義11は、マルチデータベ
ース統合部上にて管理する仮想表アクセス権と、統合対
象DBMS上のDBMSアクセス権とを対応づけ、対応関係を保
存する処理を行なう。定義時アクセス権マッピングの整
合性チェック12は、仮想表に対するアクセス権と、実
表に対するアクセス権のマッピングにおいて不整合が生
じていないかを判定し、不整合の発生しているマッピン
グを、通常と異なる形態で画面表示することにより、ユ
ーザに通知する。図14に画面例を示す。
部30で用いる一連の定義情報の登録・修正を行なう。
定義部10での登録・修正結果は、定義DB20に保存さ
れる。定義部は、アクセス権マッピング定義11と、定
義時アクセス権マッピングの整合性チェック12よりな
る。アクセス権マッピング定義11は、マルチデータベ
ース統合部上にて管理する仮想表アクセス権と、統合対
象DBMS上のDBMSアクセス権とを対応づけ、対応関係を保
存する処理を行なう。定義時アクセス権マッピングの整
合性チェック12は、仮想表に対するアクセス権と、実
表に対するアクセス権のマッピングにおいて不整合が生
じていないかを判定し、不整合の発生しているマッピン
グを、通常と異なる形態で画面表示することにより、ユ
ーザに通知する。図14に画面例を示す。
【0026】マルチデータベース統合部30では、定義
DB20に保存された定義情報を用いて、DBMS1 (40)、
DBMS2 (50)のデータ統合処理を行なう。マルチデータ
ベース統合部30は、実行時アクセス権マッピングの整
合性チェック31、仮想表アクセス権判定32、仮想表
アクセス権変換33よりなる。実行時アクセス権マッピ
ングの整合性チェック31では、実行時の環境におい
て、定義したアクセス権マッピングに不整合がないか検
出し、不整合を検出した場合には、一定のルールに基づ
いた修復処理を行なう。仮想表アクセス権判定32で
は、AP側で利用する仮想表に対するアクセス権判定を行
なう。仮想表アクセス権変換33では、仮想表アクセス
権を統合対象となるDBMSへのアクセス権に変換する処理
を行なう。AP60からマルチデータベース統合部30に
対して仮想表に対する表操作要求を行なうと、マルチデ
ータベース統合部ではこの仮想表に対する要求をDBMS1
(40)、DBMS2 (50)、に対する表操作要求へと変換す
る。AP 60からマルチデータベース統合部30に対す
る表操作要求は、データベース操作の標準言語であるSQ
Lを用い、マルチデータベース統合部30からDBMS1 (4
0)、DBMS2 (50)への操作にもSQLを用いる。
DB20に保存された定義情報を用いて、DBMS1 (40)、
DBMS2 (50)のデータ統合処理を行なう。マルチデータ
ベース統合部30は、実行時アクセス権マッピングの整
合性チェック31、仮想表アクセス権判定32、仮想表
アクセス権変換33よりなる。実行時アクセス権マッピ
ングの整合性チェック31では、実行時の環境におい
て、定義したアクセス権マッピングに不整合がないか検
出し、不整合を検出した場合には、一定のルールに基づ
いた修復処理を行なう。仮想表アクセス権判定32で
は、AP側で利用する仮想表に対するアクセス権判定を行
なう。仮想表アクセス権変換33では、仮想表アクセス
権を統合対象となるDBMSへのアクセス権に変換する処理
を行なう。AP60からマルチデータベース統合部30に
対して仮想表に対する表操作要求を行なうと、マルチデ
ータベース統合部ではこの仮想表に対する要求をDBMS1
(40)、DBMS2 (50)、に対する表操作要求へと変換す
る。AP 60からマルチデータベース統合部30に対す
る表操作要求は、データベース操作の標準言語であるSQ
Lを用い、マルチデータベース統合部30からDBMS1 (4
0)、DBMS2 (50)への操作にもSQLを用いる。
【0027】DBMS1 (40)およびDBMS2 (50)は統合対
象となるDBMSである。仮想表に対するアクセス権情報
は、仮想表アクセス権24として定義DB上に格納されて
いるが、統合DBMS上に格納されている実表に対するアク
セス権は、図1のDBMSアクセス権41に示すように、統
合対象DBMS上に格納されている。DBMSアクセス権41
は、ID101、実表名102、ユーザ名103、表操作
権限104よりなる。なお、統合対象DBアクセス権41
の実装レベルでの詳細は各DBMS毎に異なるが、いずれの
DBMSにおいてもDBMSアクセス権41と同様な項目を内部
情報として管理している。そこで本実施例では、説明の
簡略化を行なうため、いずれのDBMS上においても統合対
象DBアクセス権41の構造によって、実表に対するアク
セス権を管理しているものと仮定して説明を行なう。実
際には、DBMSアクセス権41と異なり形態の表およびフ
ァイル等で管理されていてもかまわない。
象となるDBMSである。仮想表に対するアクセス権情報
は、仮想表アクセス権24として定義DB上に格納されて
いるが、統合DBMS上に格納されている実表に対するアク
セス権は、図1のDBMSアクセス権41に示すように、統
合対象DBMS上に格納されている。DBMSアクセス権41
は、ID101、実表名102、ユーザ名103、表操作
権限104よりなる。なお、統合対象DBアクセス権41
の実装レベルでの詳細は各DBMS毎に異なるが、いずれの
DBMSにおいてもDBMSアクセス権41と同様な項目を内部
情報として管理している。そこで本実施例では、説明の
簡略化を行なうため、いずれのDBMS上においても統合対
象DBアクセス権41の構造によって、実表に対するアク
セス権を管理しているものと仮定して説明を行なう。実
際には、DBMSアクセス権41と異なり形態の表およびフ
ァイル等で管理されていてもかまわない。
【0028】定義DB20には、マルチデータベース統合
部30を制御するための定義情報を格納する。定義DB2
0は、DBMS情報21、ユーザ情報22、仮想表定義2
3、仮想表アクセス権24、アクセス権マッピング25
を保持する。DBMS情報21では、統合対象DBMSの管理情
報を保持する。ユーザ情報22では、仮想表ユーザを管
理する。仮想表定義23では、仮想表の定義を格納す
る。仮想表アクセス権24では、仮想表に対するアクセ
ス権を管理する。アクセス権マッピング25では、仮想
表アクセス権と、統合対象DBMSのアクセス権との対応関
係を保持する。実施例1では、図4に詳細を示すアクセ
ス権マッピング25を用いる。
部30を制御するための定義情報を格納する。定義DB2
0は、DBMS情報21、ユーザ情報22、仮想表定義2
3、仮想表アクセス権24、アクセス権マッピング25
を保持する。DBMS情報21では、統合対象DBMSの管理情
報を保持する。ユーザ情報22では、仮想表ユーザを管
理する。仮想表定義23では、仮想表の定義を格納す
る。仮想表アクセス権24では、仮想表に対するアクセ
ス権を管理する。アクセス権マッピング25では、仮想
表アクセス権と、統合対象DBMSのアクセス権との対応関
係を保持する。実施例1では、図4に詳細を示すアクセ
ス権マッピング25を用いる。
【0029】以上で、実施例1のブロック図の説明を終
える。
える。
【0030】以下では、図1の定義DB20に格納されて
いる各情報についての詳細説明を、図3を用いて行な
う。
いる各情報についての詳細説明を、図3を用いて行な
う。
【0031】DBMS情報21は、統合対象となるDBMSを管
理するための情報を格納するものであり、図3に示すよ
うにDBMS配置情報380、DBMSユーザ情報310、実表
情報320、実カラム情報330、の4つの表よりな
る。
理するための情報を格納するものであり、図3に示すよ
うにDBMS配置情報380、DBMSユーザ情報310、実表
情報320、実カラム情報330、の4つの表よりな
る。
【0032】図3のDBMS配置情報380は、DBMS名 3
81、DBMSタイプ 382、ホスト名383よりなる。D
BMS名 381には、統合対象となるDBMS名を格納する。
DBMSタイプ 382には、DBMSの種別を格納する。例え
ばDBMSの製品名などを格納する。ホスト名 383に
は、DBMSが配置されている計算機を表わすホスト名を格
納する。
81、DBMSタイプ 382、ホスト名383よりなる。D
BMS名 381には、統合対象となるDBMS名を格納する。
DBMSタイプ 382には、DBMSの種別を格納する。例え
ばDBMSの製品名などを格納する。ホスト名 383に
は、DBMSが配置されている計算機を表わすホスト名を格
納する。
【0033】図3のDBMSユーザ情報310は、DBMS_UID
311、DBMS名 312、DB接続ユーザ名 313、パ
スワード 314よりなる。DBMS_UID 311には、DBMS
ユーザ情報310のレコードを一意に識別する識別値を
格納する。DBMS名 312には、DBMS名381に対応す
る値を格納する。DBMS接続ユーザ名 313、パスワー
ド 314には、統合対象となるDBMSにたいしアクセス
を行なうためのユーザ名およびパスワードを格納する。
311、DBMS名 312、DB接続ユーザ名 313、パ
スワード 314よりなる。DBMS_UID 311には、DBMS
ユーザ情報310のレコードを一意に識別する識別値を
格納する。DBMS名 312には、DBMS名381に対応す
る値を格納する。DBMS接続ユーザ名 313、パスワー
ド 314には、統合対象となるDBMSにたいしアクセス
を行なうためのユーザ名およびパスワードを格納する。
【0034】図3の実表情報320は、RTBL_ID 32
1、実表名322、DBMS名 323よりなる。RTBL_ID
321には、実表情報320のレコードを一意に識別す
る識別値を格納する。実表名322には、DBMS上に存在
する実表の名称を格納する。DBMS名 323には、DBMS
配置情報380のDBMS名 382に格納されている値の
うち、対応する値を格納する。
1、実表名322、DBMS名 323よりなる。RTBL_ID
321には、実表情報320のレコードを一意に識別す
る識別値を格納する。実表名322には、DBMS上に存在
する実表の名称を格納する。DBMS名 323には、DBMS
配置情報380のDBMS名 382に格納されている値の
うち、対応する値を格納する。
【0035】図3の実カラム情報330は、RC_ID 33
1、実カラム名332、データ型333、RTBL_ID33
4、よりなる。RC_ID 331には、実カラム情報330
のレコードを一意に識別する識別値を格納する。実カラ
ム名332には、実表のカラム名称を格納する。データ
型333には、実カラム名332の実表におけるデータ
型を格納する。RTBL_ID334には、実カラム名333
を保持する実表名に対応した、実表情報320上のRTBL
_ID321の値を格納する。
1、実カラム名332、データ型333、RTBL_ID33
4、よりなる。RC_ID 331には、実カラム情報330
のレコードを一意に識別する識別値を格納する。実カラ
ム名332には、実表のカラム名称を格納する。データ
型333には、実カラム名332の実表におけるデータ
型を格納する。RTBL_ID334には、実カラム名333
を保持する実表名に対応した、実表情報320上のRTBL
_ID321の値を格納する。
【0036】図1の仮想表定義22は、図3に示すよう
に仮想表−表定義340、仮想表−カラム定義350、
の2つの表よりなる。
に仮想表−表定義340、仮想表−カラム定義350、
の2つの表よりなる。
【0037】図3の仮想表−表定義情報340には、仮
想表を定義するための情報を格納する。仮想表−表定義
情報340は、仮想表名341、仮想表名定義SQL34
2よりなる。仮想表名341には、仮想表名を格納す
る。仮想表名定義SQL342には、仮想表を定義するた
めのSQL文を格納する。このSQL文は統合対象となるDB
MS上の表を対象として記述されるものである。なお、
仮想表を定義する方法は、SQLを用いる手段に限ら
ず、他の手段を用いてもよい。
想表を定義するための情報を格納する。仮想表−表定義
情報340は、仮想表名341、仮想表名定義SQL34
2よりなる。仮想表名341には、仮想表名を格納す
る。仮想表名定義SQL342には、仮想表を定義するた
めのSQL文を格納する。このSQL文は統合対象となるDB
MS上の表を対象として記述されるものである。なお、
仮想表を定義する方法は、SQLを用いる手段に限ら
ず、他の手段を用いてもよい。
【0038】図3の仮想表−カラム定義情報350に
は、仮想表上の項目を管理する情報を格納する。仮想表
−カラム定義情報350は、VC_ID351、仮想表名3
52、仮想表カラム名353、RC_ID354よりなる。V
C_ID351には、仮想表項目情報350のレコードを一
意に識別する識別値を格納する。仮想表名352には、
仮想表名341の値のうち対応する値を格納する。仮想
表カラム名353には、仮想表のカラム名称を格納す
る。RC_ID354には、仮想表カラムと対応する実カラ
ムの識別子として、実カラム情報330におけるRC_ID
331の値を格納する。
は、仮想表上の項目を管理する情報を格納する。仮想表
−カラム定義情報350は、VC_ID351、仮想表名3
52、仮想表カラム名353、RC_ID354よりなる。V
C_ID351には、仮想表項目情報350のレコードを一
意に識別する識別値を格納する。仮想表名352には、
仮想表名341の値のうち対応する値を格納する。仮想
表カラム名353には、仮想表のカラム名称を格納す
る。RC_ID354には、仮想表カラムと対応する実カラ
ムの識別子として、実カラム情報330におけるRC_ID
331の値を格納する。
【0039】図1のユーザ情報23は、仮想表に対する
ユーザ名、パスワードを管理するものであり、図3のユ
ーザ情報23に示すように、ユーザ情報23のレコード
を一意に識別するUID371と、ユーザ名372、パス
ワード373よりなる。
ユーザ名、パスワードを管理するものであり、図3のユ
ーザ情報23に示すように、ユーザ情報23のレコード
を一意に識別するUID371と、ユーザ名372、パス
ワード373よりなる。
【0040】図1の仮想表アクセス権24は、図3に示
すようにVA_ID361、仮想表名362、ユーザ名36
3、仮想表操作権限364よりなる。VA_ID361に
は、仮想表アクセス権24のレコードを一意に識別する
識別値を格納する。仮想表名362には、アクセス権対
応の対象となる仮想表名を格納する。この仮想表名は仮
想表−表定義340の仮想表名341に格納されている
仮想表名のうち、該当するものを格納する。ユーザ名3
63には、ユーザ情報23に格納されているユーザ名3
72のうち、仮想表に対するアクセス権を対応づけるも
のを格納する。仮想表操作権限364には、仮想表表に
対するSQL操作種別のSELECT、DELETE、UPDATE、INSERT
のいずれが許可されているかを示す値を格納する。図3
の例では、仮想表VT1に対してユーザAPUser1が、SELECT
とUPDATEの操作が許可されていることを示している。
すようにVA_ID361、仮想表名362、ユーザ名36
3、仮想表操作権限364よりなる。VA_ID361に
は、仮想表アクセス権24のレコードを一意に識別する
識別値を格納する。仮想表名362には、アクセス権対
応の対象となる仮想表名を格納する。この仮想表名は仮
想表−表定義340の仮想表名341に格納されている
仮想表名のうち、該当するものを格納する。ユーザ名3
63には、ユーザ情報23に格納されているユーザ名3
72のうち、仮想表に対するアクセス権を対応づけるも
のを格納する。仮想表操作権限364には、仮想表表に
対するSQL操作種別のSELECT、DELETE、UPDATE、INSERT
のいずれが許可されているかを示す値を格納する。図3
の例では、仮想表VT1に対してユーザAPUser1が、SELECT
とUPDATEの操作が許可されていることを示している。
【0041】アクセス権マッピング情報25は、すでに
説明したように、仮想表に対して定義したアクセス権
と、統合対象となるDBMS上で定義されているアクセス権
を対応づけるものである。実施例1におけるアクセス権
マッピング情報25を図4に示す。アクセス権マッピン
グ情報25は、M_ID401、仮想表名402、DBMS名4
03、DBMS_UID404よりなる。M_ID401には、アク
セス権マッピング情報25のレコードを一意に識別する
値を格納する。仮想表名402には、図3の仮想表名3
41のうち対応する値を格納する。DBMS名403には、
対応するDBMS名381の値を格納する。DBMS_UID404
には、対応するDBMS_UIDの値を格納する。DBMS_UIDから
は、DBMSユーザ情報310を参照することにより、DBMS
ユーザ名を取得できるため、結果的には、DBMSのこのア
クセス権マッピング情報25を用いることにより、仮想
表と統合対象DBMSのユーザ名とを対応づける。統合対象
DBMS上では、ユーザ名を含むアクセス権情報が管理され
ているため、結果的にアクセス権マッピング情報25
は、仮想表アクセス権24とDBMSアクセス権41,51
とを対応づける。図1、図4にこの関連を示す。
説明したように、仮想表に対して定義したアクセス権
と、統合対象となるDBMS上で定義されているアクセス権
を対応づけるものである。実施例1におけるアクセス権
マッピング情報25を図4に示す。アクセス権マッピン
グ情報25は、M_ID401、仮想表名402、DBMS名4
03、DBMS_UID404よりなる。M_ID401には、アク
セス権マッピング情報25のレコードを一意に識別する
値を格納する。仮想表名402には、図3の仮想表名3
41のうち対応する値を格納する。DBMS名403には、
対応するDBMS名381の値を格納する。DBMS_UID404
には、対応するDBMS_UIDの値を格納する。DBMS_UIDから
は、DBMSユーザ情報310を参照することにより、DBMS
ユーザ名を取得できるため、結果的には、DBMSのこのア
クセス権マッピング情報25を用いることにより、仮想
表と統合対象DBMSのユーザ名とを対応づける。統合対象
DBMS上では、ユーザ名を含むアクセス権情報が管理され
ているため、結果的にアクセス権マッピング情報25
は、仮想表アクセス権24とDBMSアクセス権41,51
とを対応づける。図1、図4にこの関連を示す。
【0042】なお、本発明での定義DB20上の表スキー
マについては、図3、図4に示したものに限らない。図
3、図4と同等の情報を管理するのであれば、異なる形
態で表スキーマの定義を行なってもかまわない。またDB
MSを用いず、独自設計フォーマットのファイルシステム
の形態で、定義DB20を実現してもよい。
マについては、図3、図4に示したものに限らない。図
3、図4と同等の情報を管理するのであれば、異なる形
態で表スキーマの定義を行なってもかまわない。またDB
MSを用いず、独自設計フォーマットのファイルシステム
の形態で、定義DB20を実現してもよい。
【0043】上記の実施例では、図3に示した仮想表ア
クセス権24によって表単位にアクセス権を設定する場
合を示したが、さらに、図3に示すように、仮想表カラ
ムアクセス権26によって仮想表の中のカラム単位でア
クセス権を設定できる。仮想表カラムアクセス権26
は、仮想表を特定するVAC_ID381と仮想表名382、
アクセス権を設定する仮想表カラム名383、アクセス
権限を与えられるユーザ名384、及びアクセス権の内
容を示す仮想表操作権限385からなる。仮想表カラム
アクセス権26を設けることにより、上記の実施例のよ
うに複数のDBMSを表単位で統合した仮想表の中のカラム
単位でアクセス権を設定できるが、さらに、複数のDBMS
をカラム単位で統合した仮想表の場合、図3に示した仮
想表カラムアクセス権26によってカラム単位にアクセ
ス権を設定する必要がある。
クセス権24によって表単位にアクセス権を設定する場
合を示したが、さらに、図3に示すように、仮想表カラ
ムアクセス権26によって仮想表の中のカラム単位でア
クセス権を設定できる。仮想表カラムアクセス権26
は、仮想表を特定するVAC_ID381と仮想表名382、
アクセス権を設定する仮想表カラム名383、アクセス
権限を与えられるユーザ名384、及びアクセス権の内
容を示す仮想表操作権限385からなる。仮想表カラム
アクセス権26を設けることにより、上記の実施例のよ
うに複数のDBMSを表単位で統合した仮想表の中のカラム
単位でアクセス権を設定できるが、さらに、複数のDBMS
をカラム単位で統合した仮想表の場合、図3に示した仮
想表カラムアクセス権26によってカラム単位にアクセ
ス権を設定する必要がある。
【0044】なお、仮想表アクセス権24と仮想表カラ
ムアクセス権26の両方を同時に用いることもできる。
同一の仮想表に対して、仮想表アクセス権24と仮想表
カラムアクセス権26の両方にアクセス権が設定されて
いる場合には、表単位のアクセス権が設定されているも
のとしてアクセス権判定処理を行なうものとする。
ムアクセス権26の両方を同時に用いることもできる。
同一の仮想表に対して、仮想表アクセス権24と仮想表
カラムアクセス権26の両方にアクセス権が設定されて
いる場合には、表単位のアクセス権が設定されているも
のとしてアクセス権判定処理を行なうものとする。
【0045】図2に実施例1のシステム構成図を示す。
本実施例のシステムは、クライアントPC1 (210)、
クライアントPC2 (220)、定義ツールPC 230、マ
ルチデータ ベース統合サーバ240、DBMSサーバ1
(250)、DBMSサーバ2 (260)、広域ネットワーク
280、ネットワーク290、よりなる。クライアント
PC1 (210)、クライアントPC2 (220)、定義ツー
ルPC 230、マルチデータ ベース統合サーバ240、
DBMSサーバ1 (250)、DBMSサーバ2 (260)、は計
算機装置であり、これらは通常の計算機装置が備えるCP
U、メモリ、記憶装置、キーボード、マウスなどを備え
ているものとする。図2に示すように各処理部を配置す
る。なお処理部の配置は図2に示すものに限らない。こ
れらの処理をすべて一台の計算機装置上で処理してもか
まわない。また、図2では2種類のDBMSしか図示してい
ないが、これについては1つ以上の任意の個数を対象と
することができる。ネットワークの構成についても図4
に示したものに限らず、自由に構成できる。
本実施例のシステムは、クライアントPC1 (210)、
クライアントPC2 (220)、定義ツールPC 230、マ
ルチデータ ベース統合サーバ240、DBMSサーバ1
(250)、DBMSサーバ2 (260)、広域ネットワーク
280、ネットワーク290、よりなる。クライアント
PC1 (210)、クライアントPC2 (220)、定義ツー
ルPC 230、マルチデータ ベース統合サーバ240、
DBMSサーバ1 (250)、DBMSサーバ2 (260)、は計
算機装置であり、これらは通常の計算機装置が備えるCP
U、メモリ、記憶装置、キーボード、マウスなどを備え
ているものとする。図2に示すように各処理部を配置す
る。なお処理部の配置は図2に示すものに限らない。こ
れらの処理をすべて一台の計算機装置上で処理してもか
まわない。また、図2では2種類のDBMSしか図示してい
ないが、これについては1つ以上の任意の個数を対象と
することができる。ネットワークの構成についても図4
に示したものに限らず、自由に構成できる。
【0046】以下では、図7から図13のフロー図を用
いて実施例1の図1における処理ブロックの動作につい
て説明する。
いて実施例1の図1における処理ブロックの動作につい
て説明する。
【0047】図7を用いて定義部10の処理フローを説
明する。
明する。
【0048】ステップ701では、入力画面を用いてDB
MS情報21の定義を行う。入力画面の構成は、図3のDB
MS情報21における各テーブルをそのまま表示したもの
を用いる。
MS情報21の定義を行う。入力画面の構成は、図3のDB
MS情報21における各テーブルをそのまま表示したもの
を用いる。
【0049】ステップ702では、入力画面を用いて、
ユーザ情報22の定義を行う。入力画面の構成は、図3
のユーザ情報22の各テーブルをそのまま表示したもの
を用いる。
ユーザ情報22の定義を行う。入力画面の構成は、図3
のユーザ情報22の各テーブルをそのまま表示したもの
を用いる。
【0050】ステップ703では、入力画面を用いて、
仮想表定義23の定義を行う。入力画面の構成は、図3
の仮想表定義23の各テーブルをそのまま表示したもの
を用いる。
仮想表定義23の定義を行う。入力画面の構成は、図3
の仮想表定義23の各テーブルをそのまま表示したもの
を用いる。
【0051】ステップ704では、入力画面を用いて、
仮想表アクセス権24の定義を行う。入力画面の構成
は、図3の仮想表アクセス権24のテーブルをそのまま
表示したものを用いる。
仮想表アクセス権24の定義を行う。入力画面の構成
は、図3の仮想表アクセス権24のテーブルをそのまま
表示したものを用いる。
【0052】ステップ705では、図1のアクセス権マ
ッピング定義11を行う。本処理により定義DB20上の
アクセス権マッピング25を定義する。本ステップにお
いては、図14に示す入力画面を用いる。詳細は図9を
用いて説明する。
ッピング定義11を行う。本処理により定義DB20上の
アクセス権マッピング25を定義する。本ステップにお
いては、図14に示す入力画面を用いる。詳細は図9を
用いて説明する。
【0053】ステップ706では、図1の定義時アクセ
ス権マッピングの整合性チェック12を行う。
ス権マッピングの整合性チェック12を行う。
【0054】本処理により、アクセス権マッピング25
と、これに関連する情報との間で、不整合が生じている
か否かのチェックを行う。具体的には、「(1)DBMSユ
ーザ情報310上のユーザが実際の統合対象側DBMS上に
存在するか」、「(2)仮想表操作権限と実表操作権限
の間に矛盾がないか」について調べる。詳細は図10を
用いて説明する。
と、これに関連する情報との間で、不整合が生じている
か否かのチェックを行う。具体的には、「(1)DBMSユ
ーザ情報310上のユーザが実際の統合対象側DBMS上に
存在するか」、「(2)仮想表操作権限と実表操作権限
の間に矛盾がないか」について調べる。詳細は図10を
用いて説明する。
【0055】なお定義部10で用いる入力画面は上記ス
テップで述べたテーブル構成をそのまま表示する画面に
限定せず、各ステップで入力対象となる項目を表示する
ものであれば、どのような画面構成であってもかまわな
い。更に、図7の定義部10の処理フローは、説明を簡
易化するために、定義DBに必要な情報をステップ毎に入
力する形で記述されているが、図7の処理フローに限ら
ず、例えばメイン画面のメニューに入力対象となる定義
DB上のテーブル名一覧を表示し、このメニューを選択す
ることにより、定義DB上の各テーブルに入力を行う個別
画面を表示し、個別テーブルへの入力処理を終了すると
メイン画面に戻る、といった、イベントドリブンな処理
フロー構成であってもかまわない。
テップで述べたテーブル構成をそのまま表示する画面に
限定せず、各ステップで入力対象となる項目を表示する
ものであれば、どのような画面構成であってもかまわな
い。更に、図7の定義部10の処理フローは、説明を簡
易化するために、定義DBに必要な情報をステップ毎に入
力する形で記述されているが、図7の処理フローに限ら
ず、例えばメイン画面のメニューに入力対象となる定義
DB上のテーブル名一覧を表示し、このメニューを選択す
ることにより、定義DB上の各テーブルに入力を行う個別
画面を表示し、個別テーブルへの入力処理を終了すると
メイン画面に戻る、といった、イベントドリブンな処理
フロー構成であってもかまわない。
【0056】図9を用いてアクセス権マッピング定義1
1の処理フローを説明する。
1の処理フローを説明する。
【0057】ステップ901では、仮想表−表定義34
0とDBMSユーザ情報310を参照することにより、仮想
表名および統合対象DBMS側ユーザ名の一覧を取得し、こ
れらを入力画面上に表示する。図14にGUIの一例を示
す。このGUIでは仮想表名の一覧を縦軸方向に表示し、D
BMS側ユーザ名の一覧を横軸方向に表示している。
0とDBMSユーザ情報310を参照することにより、仮想
表名および統合対象DBMS側ユーザ名の一覧を取得し、こ
れらを入力画面上に表示する。図14にGUIの一例を示
す。このGUIでは仮想表名の一覧を縦軸方向に表示し、D
BMS側ユーザ名の一覧を横軸方向に表示している。
【0058】ステップ902では、仮想表名と統合対象
DBMS間の対応づけを自動入力する。図14の例では、ユ
ーザがメニュー項目「自動マッピング1402」をマウ
スなどにより選択すると、仮想表名とユーザ名の間で名
称文字列の包含関係が成立するか否かを判定し、包含関
係が成立する場合には、対応個所のセル部分に丸印を表
示する。図14では、仮想表名DB1_User1_VT3の中に、
ユーザ名であるDB1_User1が文字列として含まれている
ため、セル1403に示すように自動マッピング結果で
ある丸印が表示される。一般に仮想表名とユーザ名の間
に明示的な関係はないが、仮想表定義を行なう際に、あ
る特定のルールに従って仮想表の名称を設計することが
想定できる。こうした特定のルールに従って仮想表名を
定義している場合、本ステップの自動マッピング処理に
より、手入力でマッピング定義する作業を軽減する。以
下にルールの概要を説明する。なお自動マッピングのル
ールは、ここで述べたルールに限定されない。
DBMS間の対応づけを自動入力する。図14の例では、ユ
ーザがメニュー項目「自動マッピング1402」をマウ
スなどにより選択すると、仮想表名とユーザ名の間で名
称文字列の包含関係が成立するか否かを判定し、包含関
係が成立する場合には、対応個所のセル部分に丸印を表
示する。図14では、仮想表名DB1_User1_VT3の中に、
ユーザ名であるDB1_User1が文字列として含まれている
ため、セル1403に示すように自動マッピング結果で
ある丸印が表示される。一般に仮想表名とユーザ名の間
に明示的な関係はないが、仮想表定義を行なう際に、あ
る特定のルールに従って仮想表の名称を設計することが
想定できる。こうした特定のルールに従って仮想表名を
定義している場合、本ステップの自動マッピング処理に
より、手入力でマッピング定義する作業を軽減する。以
下にルールの概要を説明する。なお自動マッピングのル
ールは、ここで述べたルールに限定されない。
【0059】ステップ903では、仮想表名と統合対象
DBMS間の対応づけを手動で入力する。図XXの例では、対
応づけたい個所のセル部分をマウスでクリックすること
により、セルに丸が表示される。ステップ902および
ステップ903において、図14の画面上のセルに対し
て丸を表示することにより、仮想表名と統合対象DBMS間
の対応づけを行う。
DBMS間の対応づけを手動で入力する。図XXの例では、対
応づけたい個所のセル部分をマウスでクリックすること
により、セルに丸が表示される。ステップ902および
ステップ903において、図14の画面上のセルに対し
て丸を表示することにより、仮想表名と統合対象DBMS間
の対応づけを行う。
【0060】ステップ904では、ユーザがメニュー項
目「登録1401」をマウスなどにより選択することに
より、アクセス権マッピング情報25の格納処理を行な
う。ステップ902、903においてセルに丸が表示さ
れた部分のマッピング関係を、アクセス権マッピング情
報25として格納する。まず画面上にて丸を指定されて
いるセルに対応した仮想表名とDBMSユーザ名を取得す
る。画面から取得したDBMSユーザ名を検索条件として、
DBMSユーザ情報310を参照することにより、DBMS_UID
の値を得ることができるので、これらを組みにしてアク
セス権マッピング情報25に格納する。
目「登録1401」をマウスなどにより選択することに
より、アクセス権マッピング情報25の格納処理を行な
う。ステップ902、903においてセルに丸が表示さ
れた部分のマッピング関係を、アクセス権マッピング情
報25として格納する。まず画面上にて丸を指定されて
いるセルに対応した仮想表名とDBMSユーザ名を取得す
る。画面から取得したDBMSユーザ名を検索条件として、
DBMSユーザ情報310を参照することにより、DBMS_UID
の値を得ることができるので、これらを組みにしてアク
セス権マッピング情報25に格納する。
【0061】図10を用いて定義時アクセス権マッピン
グの整合性チェック12の処理フローを説明する。
グの整合性チェック12の処理フローを説明する。
【0062】ステップ1001では、統合対象DBMS側の
ユーザ名確認を行う。これはDBMSユーザ情報310に格
納されているユーザ名、パスワードを用いて各DBMSへの
接続処理を実際に行うことにより確認する。接続できな
いユーザ名、パスワードが存在した場合には、これに対
応するDBMS_UIDをメモリ上に保持する。
ユーザ名確認を行う。これはDBMSユーザ情報310に格
納されているユーザ名、パスワードを用いて各DBMSへの
接続処理を実際に行うことにより確認する。接続できな
いユーザ名、パスワードが存在した場合には、これに対
応するDBMS_UIDをメモリ上に保持する。
【0063】ステップ1002では、仮想表定義22お
よび仮想表アクセス権24から、アクセス権マッピング
25の整合性確認に用いる整合性条件を導出する。以下
では整合性条件の導出方法を説明する。整合性条件を導
出するには、図3の仮想表−表定義340および仮想表
アクセス権24から、各実表単位に必要な操作権限を導
出する。例えば仮想表VT1が「SELECT RT1_1.C1, RT1_
1.C2, RT2_1.C3, RT2_1.C4 FROM RT1_1, RT2_1 WHERE
RT1_1.C1= RT2_1.C1」といったSQLによって定義され
いるものとする。ここで、RT1_1、RT2_1はおのおのDBMS
1 (40)、DBMS2(50)上の実表とする。図3の仮想表
アクセス権24に示すように、仮想表VT1に対し、S
ELECT、UPDATE権限が与えられている。仮想表VT1
に対してSELECT、UPDATE権限を与えるには、VT1を実際
に構成する実表RT1_1、RT2_1に対してSELECT、UPDATE権
限が必要なことがわかる。
よび仮想表アクセス権24から、アクセス権マッピング
25の整合性確認に用いる整合性条件を導出する。以下
では整合性条件の導出方法を説明する。整合性条件を導
出するには、図3の仮想表−表定義340および仮想表
アクセス権24から、各実表単位に必要な操作権限を導
出する。例えば仮想表VT1が「SELECT RT1_1.C1, RT1_
1.C2, RT2_1.C3, RT2_1.C4 FROM RT1_1, RT2_1 WHERE
RT1_1.C1= RT2_1.C1」といったSQLによって定義され
いるものとする。ここで、RT1_1、RT2_1はおのおのDBMS
1 (40)、DBMS2(50)上の実表とする。図3の仮想表
アクセス権24に示すように、仮想表VT1に対し、S
ELECT、UPDATE権限が与えられている。仮想表VT1
に対してSELECT、UPDATE権限を与えるには、VT1を実際
に構成する実表RT1_1、RT2_1に対してSELECT、UPDATE権
限が必要なことがわかる。
【0064】次にアクセス権マッピング情報25を参照
することにより、VT1においては、DBMS1のユーザとし
てDB1_User1が、DBMS2のユーザとしてDB1_User2が対応
づけられていることがわかる。
することにより、VT1においては、DBMS1のユーザとし
てDB1_User1が、DBMS2のユーザとしてDB1_User2が対応
づけられていることがわかる。
【0065】この対応づけに基づいて、仮想表VT1にお
いては、定義DB20と、各統合DBMS上のアクセス権定義
情報(DBMSアクセス権41、DBMS2アクセス権51)と
の間で整合性が成立するためには、以下の条件が成立す
ることが必要であることが導出できる。
いては、定義DB20と、各統合DBMS上のアクセス権定義
情報(DBMSアクセス権41、DBMS2アクセス権51)と
の間で整合性が成立するためには、以下の条件が成立す
ることが必要であることが導出できる。
【0066】(整合性条件1):DB1_User1がRT1_1に
対してSELECT権限とUPDATE権限をもつ。 (整合性条件2):DB2_User1がRT2_1に対してSELECT
権限とUPDATE権限をもつ。 ここでのべた整合性条件の導出手順を、ステップ100
2での処理として行なう。
対してSELECT権限とUPDATE権限をもつ。 (整合性条件2):DB2_User1がRT2_1に対してSELECT
権限とUPDATE権限をもつ。 ここでのべた整合性条件の導出手順を、ステップ100
2での処理として行なう。
【0067】ステップ1003では、統合対象DBMS側か
らDBMSアクセス権41、51を取得する。各DBMS毎に定
義されたユーザ名、パスワードを用いて、統合対象DBMS
側に接続を行なう。そして各ユーザ対応したアクセス権
をDBMS1アクセス権41、DBMS2アクセス権51から取
得する。なお本ステップの代案として、DBMSユーザ情報
310上において、DBMS単位にスーパーユーザ(本実施
例で必要となるDBMSの管理情報を全て参照できる特権ユ
ーザ)を設けることで、統合対象DBMSからDBMSアクセス
権41、51を取得する実現方式を用いることもでき
る。
らDBMSアクセス権41、51を取得する。各DBMS毎に定
義されたユーザ名、パスワードを用いて、統合対象DBMS
側に接続を行なう。そして各ユーザ対応したアクセス権
をDBMS1アクセス権41、DBMS2アクセス権51から取
得する。なお本ステップの代案として、DBMSユーザ情報
310上において、DBMS単位にスーパーユーザ(本実施
例で必要となるDBMSの管理情報を全て参照できる特権ユ
ーザ)を設けることで、統合対象DBMSからDBMSアクセス
権41、51を取得する実現方式を用いることもでき
る。
【0068】ステップ1004では、整合性成立条件と
統合対象DBMS上から取得したアクセス権を付き合わせる
ことにより、整合性が成立しているか否かの判定を行
う。例として、DBMS1上のDB1_User1に対しては、RT1_1
へのSELECT、UPDATE権限が与えられおり、DBMS2上のDB2
_User1に対しては、RT2_1へのSELECT権限のみが与えら
れているものとする。こうした場合、DBMS2上のDB2_Use
r1に対しては、RT2_1へのUPDATE権限が与えられていな
いため、ステップ1002の整合性条件2が成立しな
い。よって不整合が生じているものと判定する。本ステ
ップでは、ステップ1002の整合性条件が全て成立し
た時にのみ、整合性が成立しているものと判定する。な
おステップ1001においてDBMS上に存在しないと判定
されたユーザ名を整合性条件が含んでいる場合には、そ
の時点で不整合が生じているものと判定する。
統合対象DBMS上から取得したアクセス権を付き合わせる
ことにより、整合性が成立しているか否かの判定を行
う。例として、DBMS1上のDB1_User1に対しては、RT1_1
へのSELECT、UPDATE権限が与えられおり、DBMS2上のDB2
_User1に対しては、RT2_1へのSELECT権限のみが与えら
れているものとする。こうした場合、DBMS2上のDB2_Use
r1に対しては、RT2_1へのUPDATE権限が与えられていな
いため、ステップ1002の整合性条件2が成立しな
い。よって不整合が生じているものと判定する。本ステ
ップでは、ステップ1002の整合性条件が全て成立し
た時にのみ、整合性が成立しているものと判定する。な
おステップ1001においてDBMS上に存在しないと判定
されたユーザ名を整合性条件が含んでいる場合には、そ
の時点で不整合が生じているものと判定する。
【0069】ステップ1005では、不整合が生じてい
る修正対象個所を、修正対象外の個所と区別できる形態
で画面表示する。例えば、図14のセル1404の様に
「VT1とDB2_User1とのマッピングを与えている部分のセ
ルを強調表示する」などの画面制御を行う。
る修正対象個所を、修正対象外の個所と区別できる形態
で画面表示する。例えば、図14のセル1404の様に
「VT1とDB2_User1とのマッピングを与えている部分のセ
ルを強調表示する」などの画面制御を行う。
【0070】次に図8を用いてマルチデータベース統合
部30の処理フローを説明する。
部30の処理フローを説明する。
【0071】ステップ801では、定義DB20の情報を
メモリ上に読みこむ処理を行う。
メモリ上に読みこむ処理を行う。
【0072】ステップ802では、実行時アクセス権マ
ッピングの整合性チェック31を行う。本処理では、メ
モリ上のアクセス権マッピング情報を実行時の環境と比
較して不整合が発生していないかの検出を行う。不整合
が発生した場合には、メモリ上のアクセス権マッピング
情報に対して自動修正を行う。図11において詳細な説
明を行なう。
ッピングの整合性チェック31を行う。本処理では、メ
モリ上のアクセス権マッピング情報を実行時の環境と比
較して不整合が発生していないかの検出を行う。不整合
が発生した場合には、メモリ上のアクセス権マッピング
情報に対して自動修正を行う。図11において詳細な説
明を行なう。
【0073】ステップ803では、APからの接続要求を
待機する。APからの接続要求があった場合に、ステップ
804を実行する。
待機する。APからの接続要求があった場合に、ステップ
804を実行する。
【0074】ステップ804では、ユーザ認証処理を行
う。ユーザ認証は、APからの接続要求時のユーザ名とパ
スワードがユーザ情報23に存在するか否かにより、ユ
ーザ認証の判定を行なう。ユーザ名とパスワードの双方
の値が一致するレコードが存在した場合にのみ、ユーザ
認証が成立したと判定する。
う。ユーザ認証は、APからの接続要求時のユーザ名とパ
スワードがユーザ情報23に存在するか否かにより、ユ
ーザ認証の判定を行なう。ユーザ名とパスワードの双方
の値が一致するレコードが存在した場合にのみ、ユーザ
認証が成立したと判定する。
【0075】ステップ805ではユーザ認証成功の判定
を行う。成功した場合にはステップ806を行う。失敗
した場合にはAP60とマルチデータベース統合部30と
の接続を行わず、ステップ803の状態に戻る。
を行う。成功した場合にはステップ806を行う。失敗
した場合にはAP60とマルチデータベース統合部30と
の接続を行わず、ステップ803の状態に戻る。
【0076】ステップ806では、AP60とマルチデー
タベース統合部30との接続を、従来のDBMSと同様な方
法にて確立する。
タベース統合部30との接続を、従来のDBMSと同様な方
法にて確立する。
【0077】ステップ807では、接続を確立したAP6
0からのSQL要求を待機する。SQL要求があった場合に
は、ステップ808を実行する。
0からのSQL要求を待機する。SQL要求があった場合に
は、ステップ808を実行する。
【0078】ステップ808では、仮想表アクセス権判
定32の処理を行う。ここではマルチデータベース統合
部30への接続ユーザに対して、SQLで要求された仮想
表および仮想表への操作権限が認可されるか否かの判定
を行う。図12において詳細な説明を行なう。
定32の処理を行う。ここではマルチデータベース統合
部30への接続ユーザに対して、SQLで要求された仮想
表および仮想表への操作権限が認可されるか否かの判定
を行う。図12において詳細な説明を行なう。
【0079】ステップ809では、仮想表アクセス権の
判定に成功したか否かの判定を行う。成功した場合には
ステップ810を実行する。失敗した場合には、エラー
メッセージの出力などを行ない、ステップ807のSQL
要求待ちの状態に遷移する。
判定に成功したか否かの判定を行う。成功した場合には
ステップ810を実行する。失敗した場合には、エラー
メッセージの出力などを行ない、ステップ807のSQL
要求待ちの状態に遷移する。
【0080】ステップ810では、仮想表アクセス権変
換処理33を行う。ここでは、SQLで要求されている仮
想表名を検索条件とすることで、アクセス権マッピング
25からDBMS_UID404を取得する。そしてDBMSユーザ
情報310から、DBMS_UID404に対応するDBMS接続ユ
ーザ名311、パスワード314を取得する。
換処理33を行う。ここでは、SQLで要求されている仮
想表名を検索条件とすることで、アクセス権マッピング
25からDBMS_UID404を取得する。そしてDBMSユーザ
情報310から、DBMS_UID404に対応するDBMS接続ユ
ーザ名311、パスワード314を取得する。
【0081】ステップ811では,上記ステップにより
得た統合対象DBMS接続ユーザ名、パスワードを用いて、
統合対象DBMS側とマルチデータベース統合部30との接
続を確立する。そして統合対象のDBMS単位にSQLを実行
し、実行結果をマルチデータベース統合部30において
統合し、AP60に対して統合結果を戻す。本ステップの
処理には、既存技術のマルチデータベース統合システム
におけるデータ統合処理を用いる。
得た統合対象DBMS接続ユーザ名、パスワードを用いて、
統合対象DBMS側とマルチデータベース統合部30との接
続を確立する。そして統合対象のDBMS単位にSQLを実行
し、実行結果をマルチデータベース統合部30において
統合し、AP60に対して統合結果を戻す。本ステップの
処理には、既存技術のマルチデータベース統合システム
におけるデータ統合処理を用いる。
【0082】図11を用いて実行時アクセス権マッピン
グの整合性チェック31の処理フローを説明する。
グの整合性チェック31の処理フローを説明する。
【0083】ステップ1101では、図10のステップ
1001と同様な、統合対象DBMS側ユーザ名の確認を行
う。
1001と同様な、統合対象DBMS側ユーザ名の確認を行
う。
【0084】ステップ1102では、図10のステップ
1002と同様な処理を行う。仮想表定義および仮想表
アクセス権から、整合性を確認するための整合性条件を
導出を行う。
1002と同様な処理を行う。仮想表定義および仮想表
アクセス権から、整合性を確認するための整合性条件を
導出を行う。
【0085】ステップ1103では、図10のステップ
1003と同様な処理を行う。統合対象DBMSから実表に
対するアクセス権情報41、51を取得する。
1003と同様な処理を行う。統合対象DBMSから実表に
対するアクセス権情報41、51を取得する。
【0086】ステップ1104では、図10のステップ
1004と同様な処理を行う。整合性成立条件と統合対
象DBMS上から取得したアクセス権を付き合わせることに
より、整合性が成立しているか否かの判定を行う。図1
0で用いた仮想表VT1の例を再度用いると、DBMS2上のDB
2_User1に対しては、RT2_1へのUPDATE権限が与えられて
いないため、整合成立のため条件が成立せず、不整合が
生じているものと判定する。この状態では仮想表VT1に
対してUPDATEのSQL実行を行なうことが不可能である。
1004と同様な処理を行う。整合性成立条件と統合対
象DBMS上から取得したアクセス権を付き合わせることに
より、整合性が成立しているか否かの判定を行う。図1
0で用いた仮想表VT1の例を再度用いると、DBMS2上のDB
2_User1に対しては、RT2_1へのUPDATE権限が与えられて
いないため、整合成立のため条件が成立せず、不整合が
生じているものと判定する。この状態では仮想表VT1に
対してUPDATEのSQL実行を行なうことが不可能である。
【0087】ステップ1105では、不整合が生じてい
る場合に、本来定義されている接続DBユーザ名の代わり
に利用できる修復用のユーザ名が、統合対象DBMS側に存
在するか否の検出を行う。本ステップでは修復ユーザ名
を、DBMSユーザ情報310上のDB接続ユーザ名313か
ら検出する。仮想表VT1の例では、DB2_User1以外に、DB
MS2上のRT2_1に対しSELECT権限とUPDATE権限をもつ別ユ
ーザが存在すれば、VT1に対してSELECTおよびUPDATE処
理を行なうことができる。以下ではこうしたユーザのこ
とを修復ユーザ名とよぶ。修復ユーザ名を検出するに
は、図10のステップ1003と同様な処理により、各
DBMS上のDBMSアクセス権を参照する。そしてDBMS上のユ
ーザが修復ユーザとして必要となる表操作権限をもつか
を判定する。この例の場合には、DBMS2上のRT2_1に対し
SELECT権限とUPDATE権限をもつユーザがDBMSアクセス権
51上に存在するか否かを判定する。以上の処理によ
り、もし存在するのであれば、修復ユーザ名を検出でき
る。修復ユーザ名を検出した場合には、DBMSユーザ情報
310を参照することにより修復ユーザ名に対応した、
DBMS_UID311を取得する。なおDBMSユーザ情報310
とDBMSアクセス権41、51の設定内容によっては、修
復ユーザが検出できない場合もある。
る場合に、本来定義されている接続DBユーザ名の代わり
に利用できる修復用のユーザ名が、統合対象DBMS側に存
在するか否の検出を行う。本ステップでは修復ユーザ名
を、DBMSユーザ情報310上のDB接続ユーザ名313か
ら検出する。仮想表VT1の例では、DB2_User1以外に、DB
MS2上のRT2_1に対しSELECT権限とUPDATE権限をもつ別ユ
ーザが存在すれば、VT1に対してSELECTおよびUPDATE処
理を行なうことができる。以下ではこうしたユーザのこ
とを修復ユーザ名とよぶ。修復ユーザ名を検出するに
は、図10のステップ1003と同様な処理により、各
DBMS上のDBMSアクセス権を参照する。そしてDBMS上のユ
ーザが修復ユーザとして必要となる表操作権限をもつか
を判定する。この例の場合には、DBMS2上のRT2_1に対し
SELECT権限とUPDATE権限をもつユーザがDBMSアクセス権
51上に存在するか否かを判定する。以上の処理によ
り、もし存在するのであれば、修復ユーザ名を検出でき
る。修復ユーザ名を検出した場合には、DBMSユーザ情報
310を参照することにより修復ユーザ名に対応した、
DBMS_UID311を取得する。なおDBMSユーザ情報310
とDBMSアクセス権41、51の設定内容によっては、修
復ユーザが検出できない場合もある。
【0088】ステップ1106では、ステップ1105
で検出した別ユーザ名に基づいてアクセス権マッピング
情報25の修復を行う。修復ユーザ名を取得できた場合
には、不整合が発生しているユーザ名に対応するアクセ
ス権マッピング情報25のDBMS_UID404を、修復ユー
ザ名に対応しているDBMS_UIDに変更する。この際、変更
を行なったことを、ログ情報などで出力する処理も行な
う。
で検出した別ユーザ名に基づいてアクセス権マッピング
情報25の修復を行う。修復ユーザ名を取得できた場合
には、不整合が発生しているユーザ名に対応するアクセ
ス権マッピング情報25のDBMS_UID404を、修復ユー
ザ名に対応しているDBMS_UIDに変更する。この際、変更
を行なったことを、ログ情報などで出力する処理も行な
う。
【0089】ステップ1107では、修復ユーザ名が存
在しなかった場合に、影響を受ける仮想表アクセス権
を、仮想表アクセス権24から検出する。まず、修復不
可能なDBMS接続ユーザ名に対応するDBMS_UIDの値に対応
づけられている仮想表名402を、アクセス権マッピン
グ25より取得する。そして、取得した仮想表名を検索
条件とすることにより、仮想表アクセス権24から、影
響を受ける仮想表名に対応したVA_ID361をメモリ上
に保持する。
在しなかった場合に、影響を受ける仮想表アクセス権
を、仮想表アクセス権24から検出する。まず、修復不
可能なDBMS接続ユーザ名に対応するDBMS_UIDの値に対応
づけられている仮想表名402を、アクセス権マッピン
グ25より取得する。そして、取得した仮想表名を検索
条件とすることにより、仮想表アクセス権24から、影
響を受ける仮想表名に対応したVA_ID361をメモリ上
に保持する。
【0090】図12を用いて仮想表アクセス権判定32
の処理フローを説明する。
の処理フローを説明する。
【0091】ステップ1201では、AP60から問合さ
れたSQLに含まれている仮想表名、表操作権限種別と、
仮想表アクセス権24を比較することにより、仮想表ア
クセス権が成立するか否かの判定を行う。成立する場合
にはステップ1202を実行する。成立しない場合には
ステップ1203を実行する。
れたSQLに含まれている仮想表名、表操作権限種別と、
仮想表アクセス権24を比較することにより、仮想表ア
クセス権が成立するか否かの判定を行う。成立する場合
にはステップ1202を実行する。成立しない場合には
ステップ1203を実行する。
【0092】ステップ1202では、ステップ1201
においてアクセス権成立と判定するために用いた仮想表
アクセス権24上のVA_ID361が、ステップ1107
で実行時不整合の影響をうけるものとして検出したVA_I
D361と一致するか否かを判定する。一つでも一致す
る場合にはステップ1204を実行する。全て一致しな
い場合にはステップ1205を実行する。
においてアクセス権成立と判定するために用いた仮想表
アクセス権24上のVA_ID361が、ステップ1107
で実行時不整合の影響をうけるものとして検出したVA_I
D361と一致するか否かを判定する。一つでも一致す
る場合にはステップ1204を実行する。全て一致しな
い場合にはステップ1205を実行する。
【0093】ステップ1203では、エラーメッセージ
に「該当アクセス権が定義されていません」を指定し、
仮想表アクセス権判定を失敗として戻る。エラーメッセ
ージは、AP60側に画面出力などを行なうことにより通
知する。
に「該当アクセス権が定義されていません」を指定し、
仮想表アクセス権判定を失敗として戻る。エラーメッセ
ージは、AP60側に画面出力などを行なうことにより通
知する。
【0094】ステップ1204では、エラーメッセージ
に「実行時にアクセス権定義の不整合が発生しました」
を指定し、仮想表アクセス権判定を失敗として戻る。エ
ラーメッセージは、AP60側に画面出力などを行なうこ
とにより通知する。
に「実行時にアクセス権定義の不整合が発生しました」
を指定し、仮想表アクセス権判定を失敗として戻る。エ
ラーメッセージは、AP60側に画面出力などを行なうこ
とにより通知する。
【0095】ステップ1205では、仮想表アクセス権
判定を成功として戻る。
判定を成功として戻る。
【0096】図13を用いて仮想表アクセス権変換33
の処理フローを説明する。
の処理フローを説明する。
【0097】ステップ1301では、図4のアクセス権
マッピング25と図3のDBMSユーザ情報310を参照す
ることにより、統合対象DBMSに対するユーザ名、パスワ
ードを取得する。仮想表VT1に対してSQL操作が行なわれ
る場合には、アクセス権マッピング25を参照すること
によりDBMS_UIDの値として1、2を得、これに対応する
レコード情報をDBMSユーザ情報310から検索すること
により、DB接続ユーザ名としてDB1_User1とDB2_User2を
取得することができる。
マッピング25と図3のDBMSユーザ情報310を参照す
ることにより、統合対象DBMSに対するユーザ名、パスワ
ードを取得する。仮想表VT1に対してSQL操作が行なわれ
る場合には、アクセス権マッピング25を参照すること
によりDBMS_UIDの値として1、2を得、これに対応する
レコード情報をDBMSユーザ情報310から検索すること
により、DB接続ユーザ名としてDB1_User1とDB2_User2を
取得することができる。
【0098】以上で実施例1の説明を終え、次に実施例
2について述べる。実施例2の処理ブロック図を図15
に示す。以下では実施例1との違いについて説明する。
実施例1との違いを述べる形で、実施例2の処理フロー
を説明する。
2について述べる。実施例2の処理ブロック図を図15
に示す。以下では実施例1との違いについて説明する。
実施例1との違いを述べる形で、実施例2の処理フロー
を説明する。
【0099】実施例1と実施例2の定義DB20が異なる
点は、まず実施例1のアクセス権マッピング情報25の
代わりに、図5に示すアクセス権マッピング情報500
を用いることである。図5に示すように実施例2では、
ユーザ名と統合対象DBMSのユーザ名とを対応づける。
点は、まず実施例1のアクセス権マッピング情報25の
代わりに、図5に示すアクセス権マッピング情報500
を用いることである。図5に示すように実施例2では、
ユーザ名と統合対象DBMSのユーザ名とを対応づける。
【0100】次に、実施例2のアクセス権マッピング定
義1503のとアクセス権マッピング定義11(図9)
は以下の点が異なる。
義1503のとアクセス権マッピング定義11(図9)
は以下の点が異なる。
【0101】図9におけるステップ901では、仮想表
名と統合対象DBMS側のユーザ名一覧を画面表示する代わ
りに、マルチデータベース統合システムにおけるユーザ
名一覧と統合対象DBMS側のユーザ名一覧を画面表示す
る。マルチデータベース統合システムにおけるユーザ名
一覧は、ユーザ情報22より取得することができる。ス
テップ902、903では、仮想表名と統合対象DBMS側
のマッピングを定義する代わりに、マルチデータベース
統合システムにおけるユーザ名一覧と統合対象DBMS側ユ
ーザ名の間のマッピングを定義する。特にステップ90
2では、マルチデータベース統合システムにおけるユー
ザ名と統合対象DBMS側ユーザ名を比較し、ユーザ名が一
致している場合には自動的にマッピング処理を行なう。
ステップ904では、実施例2におけるアクセス権マッ
ピング情報500に対する格納処理を行う。
名と統合対象DBMS側のユーザ名一覧を画面表示する代わ
りに、マルチデータベース統合システムにおけるユーザ
名一覧と統合対象DBMS側のユーザ名一覧を画面表示す
る。マルチデータベース統合システムにおけるユーザ名
一覧は、ユーザ情報22より取得することができる。ス
テップ902、903では、仮想表名と統合対象DBMS側
のマッピングを定義する代わりに、マルチデータベース
統合システムにおけるユーザ名一覧と統合対象DBMS側ユ
ーザ名の間のマッピングを定義する。特にステップ90
2では、マルチデータベース統合システムにおけるユー
ザ名と統合対象DBMS側ユーザ名を比較し、ユーザ名が一
致している場合には自動的にマッピング処理を行なう。
ステップ904では、実施例2におけるアクセス権マッ
ピング情報500に対する格納処理を行う。
【0102】実施例2の定義時アクセス権マッピングの
整合性チェック1504では、図10のステップ100
1における統合対象DBMS側のユーザ名確認のみを行い、
他のステップを行わない。
整合性チェック1504では、図10のステップ100
1における統合対象DBMS側のユーザ名確認のみを行い、
他のステップを行わない。
【0103】実施例2の実行時アクセス権マッピングの
整合性チェック1501では、図11のステップ110
1、ステップ1107のみ行う。ステップ1101の統
合対象DBMS側の確認を行った後には、ステップ1107
として確認できなかった統合対象DBMSにより影響をうけ
るアクセス権マッピング情報500を検出する。
整合性チェック1501では、図11のステップ110
1、ステップ1107のみ行う。ステップ1101の統
合対象DBMS側の確認を行った後には、ステップ1107
として確認できなかった統合対象DBMSにより影響をうけ
るアクセス権マッピング情報500を検出する。
【0104】実施例2の仮想表アクセス権判定32につ
いては、実施例1と同様に行う。
いては、実施例1と同様に行う。
【0105】実施例2のアクセス権変換1502は、実
施例1の仮想表アクセス権変換33で参照するアクセス
権マッピング情報25の変わりに、アクセス権マッピン
グ情報500を用いる点が異なる。実施例2では、仮想
表名ではなく、ユーザ名に基づいてDBMS_UIDの取得を行
なう。
施例1の仮想表アクセス権変換33で参照するアクセス
権マッピング情報25の変わりに、アクセス権マッピン
グ情報500を用いる点が異なる。実施例2では、仮想
表名ではなく、ユーザ名に基づいてDBMS_UIDの取得を行
なう。
【0106】なお、実施例1と実施例2の特殊な場合と
して、図6に示す方式が考えられる。これは統合対象DB
MS単位に固定ユーザ名を対応づける方式であり、統合対
象DBMS単位に固定のユーザ名DB1_User1、DB2_User1を対
応づけている。本実施例は、実施例1および実施例2に
おいて、常に固定ユーザ名を対応づけた処理であるた
め、詳細説明は省略する。
して、図6に示す方式が考えられる。これは統合対象DB
MS単位に固定ユーザ名を対応づける方式であり、統合対
象DBMS単位に固定のユーザ名DB1_User1、DB2_User1を対
応づけている。本実施例は、実施例1および実施例2に
おいて、常に固定ユーザ名を対応づけた処理であるた
め、詳細説明は省略する。
【0107】図16はアクセス権を対応づけるための画
面例である。この画面例は、図14にてすでに説明した
画面と同等の定義参照を行なうものである。仮想表、お
よびDB側のユーザ名がアイコン状態で各々左右に表示さ
れる。各アイコンをダブルクリックすると、詳細な内容
が表示される(1602,1607)仮想表とユーザ名
のアイコン同士をマウスなどで対応づけることでアイコ
ン間にラインが引かれ、このことがリンク関係を示す。
エラーチェックを行うと、エラーが発生したライン上が
他のラインと異なる形態で表示される。図16では×印
が表示されている(1605)。図16に示した以外に
ラインの太さを変更したり、色を変更したりすることに
よって、エラー発生ラインを表示する様にしてもよい。
面例である。この画面例は、図14にてすでに説明した
画面と同等の定義参照を行なうものである。仮想表、お
よびDB側のユーザ名がアイコン状態で各々左右に表示さ
れる。各アイコンをダブルクリックすると、詳細な内容
が表示される(1602,1607)仮想表とユーザ名
のアイコン同士をマウスなどで対応づけることでアイコ
ン間にラインが引かれ、このことがリンク関係を示す。
エラーチェックを行うと、エラーが発生したライン上が
他のラインと異なる形態で表示される。図16では×印
が表示されている(1605)。図16に示した以外に
ラインの太さを変更したり、色を変更したりすることに
よって、エラー発生ラインを表示する様にしてもよい。
【0108】図17はDBMS自身と他DBMSとの統合を行う
統合DBMS1710による実施の形態を示す。本実施
形態では、仮想表アクセス権の制御を既に存在している
DBMS上の拡張機能として実施する。本実施形態で
は、統合DBMS1710のテーブルと外部DBMS1
40などのテーブルを統合したものを仮想表として定
義する。そして、すでに述べた実施例と同様に、統合D
BMS1710のDBMSアクセス権1741と、外部
DBMS1(40)などのDBMSアクセス権41を用
いたアクセス権マッピング定義11を行う。上記の処理
で定義した定義情報1730を用いることにより、統合
DBMS1710のテーブルと外部DBMS1(40)
などのテーブルを統合した仮想表に対して、仮想表アク
セス権判定32、仮想表アクセス権変換33などの一連
の処理を統合DBMS1710で行う。なお、定義情報
1730に格納される情報は、すでに説明した定義DB
20と同様であるので詳細な説明は省略する。なお、図
17にはアクセス権マッピング25が示されているが、
すでに説明した他の実施形態でのアクセス権マッピング
の対応づけを、統合統合DBMS1710にて行うこと
も可能である。
統合DBMS1710による実施の形態を示す。本実施
形態では、仮想表アクセス権の制御を既に存在している
DBMS上の拡張機能として実施する。本実施形態で
は、統合DBMS1710のテーブルと外部DBMS1
40などのテーブルを統合したものを仮想表として定
義する。そして、すでに述べた実施例と同様に、統合D
BMS1710のDBMSアクセス権1741と、外部
DBMS1(40)などのDBMSアクセス権41を用
いたアクセス権マッピング定義11を行う。上記の処理
で定義した定義情報1730を用いることにより、統合
DBMS1710のテーブルと外部DBMS1(40)
などのテーブルを統合した仮想表に対して、仮想表アク
セス権判定32、仮想表アクセス権変換33などの一連
の処理を統合DBMS1710で行う。なお、定義情報
1730に格納される情報は、すでに説明した定義DB
20と同様であるので詳細な説明は省略する。なお、図
17にはアクセス権マッピング25が示されているが、
すでに説明した他の実施形態でのアクセス権マッピング
の対応づけを、統合統合DBMS1710にて行うこと
も可能である。
【0109】図18は、定義ツールが複数のDB統合シス
テムを管理する場合のシステム構成図である。図18
は、定義DBの内容が各サブシステムの定義情報を統合管
理する。即ち、図18は、統合リポジトリシステムにお
ける実施の形態を示す。ここで、統合リポジトリシステ
ムとは、DBMS、文書管理、EDIなどのミドルウェ
アを連係するためのシステム間にまたがるアクセス権や
データ配置などの設定情報(メタデータと呼ばれる)を
管理するシステムである。
テムを管理する場合のシステム構成図である。図18
は、定義DBの内容が各サブシステムの定義情報を統合管
理する。即ち、図18は、統合リポジトリシステムにお
ける実施の形態を示す。ここで、統合リポジトリシステ
ムとは、DBMS、文書管理、EDIなどのミドルウェ
アを連係するためのシステム間にまたがるアクセス権や
データ配置などの設定情報(メタデータと呼ばれる)を
管理するシステムである。
【0110】本実施例では、仮想表アクセス権の定義部
10を、統合リポジトリシステム1810の一機能とし
て実現する。統合リポジトリシステム1810にて定義
した設定情報(メタデータ)を定義DB20から、連係
対象となるミドルウェアへ配布する。図18では、定義
DB20から、統合DBMS1710a,bなどにメタ
データを配布する場合を示す。そして、統合DBMS1
710a,bでは、配布されたメタデータにもとづい
て、仮想表アクセス権判定32、仮想表アクセス権変換
33などの一連の処理をそれぞれの統合DBMS171
0a,bで行う。
10を、統合リポジトリシステム1810の一機能とし
て実現する。統合リポジトリシステム1810にて定義
した設定情報(メタデータ)を定義DB20から、連係
対象となるミドルウェアへ配布する。図18では、定義
DB20から、統合DBMS1710a,bなどにメタ
データを配布する場合を示す。そして、統合DBMS1
710a,bでは、配布されたメタデータにもとづい
て、仮想表アクセス権判定32、仮想表アクセス権変換
33などの一連の処理をそれぞれの統合DBMS171
0a,bで行う。
【0111】
【発明の効果】本発明により、AP側の仮想表に対するア
クセス権定義と、統合対象DBMS側のアクセス権定義を並
行してシステム構築処理を行なうことができる。また、
本方式により、統合対象側のDBMS側において、アクセス
対象となる仮想表や、仮想表にアクセスするユーザを切
り分けるためのログ情報を、統合対象側DBMSにて取得す
るために必要なユーザ設定を行なうことが容易になる。
クセス権定義と、統合対象DBMS側のアクセス権定義を並
行してシステム構築処理を行なうことができる。また、
本方式により、統合対象側のDBMS側において、アクセス
対象となる仮想表や、仮想表にアクセスするユーザを切
り分けるためのログ情報を、統合対象側DBMSにて取得す
るために必要なユーザ設定を行なうことが容易になる。
【図1】実施例1の処理概要図である。
【図2】実施例1のシステム構成図である。
【図3】実施例1のテーブル構成図である。
【図4】仮想表を単位としたアクセス権マッピングを示
す図である。
す図である。
【図5】ユーザを単位としたアクセス権マッピングを示
す図である。
す図である。
【図6】DBMSを単位としたアクセス権マッピングを示す
図である。
図である。
【図7】実行部の処理フロー図である。
【図8】マルチデータベース統合部の処理フロー図であ
る。
る。
【図9】アクセス権マッピング定義の処理フロー図であ
る。
る。
【図10】定義時アクセス権マッピングの整合性チェッ
クのフロー図である。
クのフロー図である。
【図11】実行時アクセス権マッピングの整合性チェッ
クのフロー図である。
クのフロー図である。
【図12】仮想表アクセス権判定のフロー図である。
【図13】アクセス権変換のフロー図である。
【図14】アクセス権マッピング定義画面例である。
【図15】実施例2の処理概要図である。
【図16】アクセス権を対応付けるための画面例であ
る。
る。
【図17】DBMS自身と他のDBMSとの統合を行う
場合のシステム構成図である。
場合のシステム構成図である。
【図18】定義ツールが複数のDB統合システムを管理
する場合のシステム構成図である。
する場合のシステム構成図である。
10...定義部 20...定義DB 30...マルチデータベース統合部 40...統合対象DBMS1 50...統合対象DBMS2 60...アプリケーション
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 FI テーマコート゛(参考) G06F 17/30 120 G06F 17/30 120B (72)発明者 林 重年 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 西川 記史 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Fターム(参考) 5B017 AA03 BA06 BB06 CA16 5B075 KK03 KK07 KK13 KK33 KK37 KK43 KK54 KK63 UU40 5B082 EA11 GA11 HA00 5B085 AA01 AE02 AE03 BC00 BE07 BG03 BG07
Claims (10)
- 【請求項1】アプリケーションを実行するクライアント
およびそれぞれがデータベースを有する少なくとも1つ
のデータベースサーバが接続されたマルチデータベース
統合サーバは、 前記クライアントから、前記アプリケーションで使用さ
れる仮想表の仮想表定義情報に含まれる操作種別とユー
ザ名を定めた仮想表アクセス権情報とを入力し、 前記データベースサーバのそれぞれから、接続ユーザ名
と表操作権限とを対応付けたデータベースアクセス権情
報を入力し、 前記ユーザ名と前記接続ユーザ名、および前記操作種別
と前記表操作権限とをそれぞれ比較することによって、
前記データベースのそれぞれに対する前記仮想表のアク
セス権を判定することを特徴とするマルチデータベース
統合システムのアクセス権管理方法。 - 【請求項2】前記アクセス権管理方法は、さらに、前記
アクセス権の判定結果に基づいて、前記データベースの
それぞれに対する前記仮想表のアクセス権の有無を前記
クライアントの表示装置に表示することを特徴とする請
求項1記載のマルチデータベース統合システムのアクセ
ス権管理方法。 - 【請求項3】アプリケーションを実行するクライアント
およびそれぞれがデータベースを有する少なくとも1つ
のデータベースサーバが接続されたマルチデータベース
統合サーバは、 前記クライアントから、前記アプリケーションで使用さ
れる仮想表の仮想表定義情報に含まれる操作種別とユー
ザ名を定めた仮想表アクセス権情報とを入力し、 前記データベースサーバのそれぞれから、接続ユーザ名
と表操作権限とを対応付けたデータベースアクセス権情
報を入力し、 前記仮想表からのアクセスの際に、前記操作種別と前記
表操作権限との整合性をチェックした上で、前記ユーザ
名を前記接続ユーザ名に変換することによって、前記デ
ータベースのそれぞれに対する前記仮想表のアクセス権
を変換することを特徴とするマルチデータベース統合シ
ステムのアクセス権管理方法。 - 【請求項4】前記アクセス権を変換するステップにおい
て、所定のルールに基づいて前記アクセス権を変換する
ことを特徴とする請求項3記載のマルチデータベース統
合システムのアクセス権管理方法。 - 【請求項5】アプリケーションを実行するクライアント
およびそれぞれがデータベースを有する少なくとも1つ
のデータベースサーバが接続されたマルチデータベース
統合サーバは、 前記クライアントから、前記アプリケーションで使用さ
れる仮想表の仮想表定義情報に含まれる操作種別とユー
ザ名を定めた仮想表アクセス権情報とを入力し、 前記データベースサーバのそれぞれから、接続ユーザ名
と表操作権限とを対応付けたデータベースアクセス権情
報を入力し、 前記ユーザ名と前記接続ユーザ名、および前記操作種別
と前記表操作権限とをそれぞれ比較することによって、
前記データベースのそれぞれに対する前記仮想表のアク
セス権を判定し、 前記判定の結果、アクセス権の不整合が判明したデータ
ベースに対して、前記表操作権限が同一の他の接続ユー
ザ名によって前記接続ユーザ名を修復することを特徴と
するマルチデータベース統合システムのアクセス権管理
方法。 - 【請求項6】アプリケーションを実行するクライアント
およびそれぞれがデータベースを有する少なくとも1つ
のデータベースサーバが接続されたマルチデータベース
統合サーバは、 前記クライアントから、前記アプリケーションで使用さ
れる仮想表の仮想表定義情報に含まれるデータ項目毎の
操作種別とユーザ名を定めた仮想表アクセス権情報とを
入力し、 前記データベースサーバのそれぞれから、接続ユーザ名
とデータ項目毎の表操作権限とを対応付けたデータベー
スアクセス権情報を入力し、 前記ユーザ名と前記接続ユーザ名、およびデータ項目毎
の前記操作種別と前記表操作権限とをそれぞれ比較する
ことによって、前記データベースのそれぞれに対する前
記仮想表のアクセス権をデータ項目毎に判定することを
特徴とするマルチデータベース統合システムのアクセス
権管理方法。 - 【請求項7】前記アクセス権管理方法は、さらに、前記
アクセス権の判定結果に基づいて、前記データベースの
それぞれに対する前記仮想表のアクセス権の有無をデー
タ項目毎に前記クライアントの表示装置に表示すること
を特徴とする請求項6記載のマルチデータベース統合シ
ステムのアクセス権管理方法。 - 【請求項8】アプリケーションを実行するクライアント
およびそれぞれがデータベースを有する少なくとも1つ
のデータベースサーバが接続されたマルチデータベース
統合サーバは、 前記クライアントから、前記アプリケーションで使用さ
れる仮想表の仮想表定義情報に含まれる操作種別とユー
ザ名を定めた仮想表アクセス権情報とを入力し、 前記データベースサーバのそれぞれから、接続ユーザ名
と表操作権限とを対応付けたデータベースアクセス権情
報を入力し、 前記ユーザ名と前記接続ユーザ名、および前記操作種別
と前記表操作権限とをそれぞれ比較することによって、
前記データベースのそれぞれに対する前記仮想表のアク
セス権を判定し、 前記仮想表からのアクセスの際に、前記アクセス権の判
定結果に基づいて、前記データベースのそれぞれに対す
る前記仮想表のアクセス権を変換するすることを特徴と
するマルチデータベース統合システムのアクセス権管理
方法。 - 【請求項9】アプリケーションを実行するクライアント
およびそれぞれがデータベースを有する少なくとも1つ
のデータベースサーバが接続されたマルチデータベース
統合サーバが実行するマルチデータベース統合システム
のアクセス権管理方法のプログラムを格納した、計算機
で読み取り可能な記憶媒体であって、前記アクセス管理
方法は、 前記クライアントから、前記アプリケーションで使用さ
れる仮想表の仮想表定義情報に含まれる操作種別とユー
ザ名を定めた仮想表アクセス権情報とを入力し、 前記データベースサーバのそれぞれから、接続ユーザ名
と表操作権限とを対応付けたデータベースアクセス権情
報を入力し、 前記ユーザ名と前記接続ユーザ名、および前記操作種別
と前記表操作権限とをそれぞれ比較することによって、
前記データベースのそれぞれに対する前記仮想表のアク
セス権を判定し、 前記仮想表からのアクセスの際に、前記アクセス権の判
定結果に基づいて、前記データベースのそれぞれに対す
る前記仮想表のアクセス権を変換するすることを特徴と
する記憶媒体。 - 【請求項10】前記アクセス権管理方法において、前記
接続ユーザ名は、前記仮想表、ユーザ、および固定ユー
ザ名のいずれかと対応させることを特徴とする請求項
1,3,5,6および8に記載のマルチデータベース統
合システムのアクセス権管理方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000342373A JP2002149468A (ja) | 2000-11-06 | 2000-11-06 | マルチデータベース統合システムのアクセス権管理方法 |
US09/803,149 US20020055921A1 (en) | 2000-11-06 | 2001-03-12 | Multi-database system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000342373A JP2002149468A (ja) | 2000-11-06 | 2000-11-06 | マルチデータベース統合システムのアクセス権管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2002149468A true JP2002149468A (ja) | 2002-05-24 |
Family
ID=18816943
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000342373A Pending JP2002149468A (ja) | 2000-11-06 | 2000-11-06 | マルチデータベース統合システムのアクセス権管理方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US20020055921A1 (ja) |
JP (1) | JP2002149468A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006085578A1 (ja) * | 2005-02-10 | 2006-08-17 | Yokogawa Electric Corporation | 分散情報統合方法及び分散情報統合システム |
JP2007149067A (ja) * | 2005-10-28 | 2007-06-14 | Ricoh Co Ltd | 文書管理システム |
US8561128B2 (en) | 2006-10-20 | 2013-10-15 | Canon Kabushiki Kaisha | Document management system and document management method |
US8639670B2 (en) | 2006-01-18 | 2014-01-28 | Fujitsu Limited | Data integration apparatus, data integration method, and computer product |
US11899668B2 (en) | 2013-08-12 | 2024-02-13 | International Business Machines Corporation | Database management apparatus, database control method and program |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7712088B2 (en) * | 2004-07-08 | 2010-05-04 | Microsoft Corporation | Method and system for a batch parser |
US20060068808A1 (en) * | 2004-09-25 | 2006-03-30 | Dimitrios Karavias | Method, System and apparatus for using mobile telephone and GPS receiver to inexpensively access the server based GIS context for navigation operations |
US7516134B2 (en) * | 2005-02-01 | 2009-04-07 | Apple Inc. | Controlling access to a database using database internal and external authorization information |
US9286371B2 (en) * | 2010-12-23 | 2016-03-15 | Sap Se | Presenting a multidimensional decision table |
US20150242531A1 (en) * | 2014-02-25 | 2015-08-27 | International Business Machines Corporation | Database access control for multi-tier processing |
US10129256B2 (en) | 2015-01-08 | 2018-11-13 | BlueTalon, Inc. | Distributed storage and distributed processing query statement reconstruction in accordance with a policy |
US11281667B2 (en) * | 2015-01-08 | 2022-03-22 | Microsoft Technology Licensing, Llc | Distributed storage and distributed processing policy enforcement utilizing virtual identifiers |
US10033765B2 (en) | 2015-01-08 | 2018-07-24 | BlueTalon, Inc. | Distributed storage processing statement interception and modification |
GB201517003D0 (en) * | 2015-09-25 | 2015-11-11 | Ibm | Secure invocation of a stored procedures in a dbms |
GB201517416D0 (en) | 2015-10-02 | 2015-11-18 | Ibm | Task-execution in a DBMS using stored procedures |
US10803190B2 (en) | 2017-02-10 | 2020-10-13 | BlueTalon, Inc. | Authentication based on client access limitation |
WO2019129831A1 (en) * | 2017-12-29 | 2019-07-04 | Datawalk Spolka Akcyjna | Systems and methods for determining database permissions |
CN113254953A (zh) * | 2021-04-28 | 2021-08-13 | 深圳市鹰硕技术有限公司 | 权限分配管理方法、装置、在线教育系统及存储介质 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5809495A (en) * | 1996-06-04 | 1998-09-15 | Oracle Corporation | Method for obtaining information regarding the current activity of a database management system from a viritual table in a memory of the database management system |
-
2000
- 2000-11-06 JP JP2000342373A patent/JP2002149468A/ja active Pending
-
2001
- 2001-03-12 US US09/803,149 patent/US20020055921A1/en not_active Abandoned
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006085578A1 (ja) * | 2005-02-10 | 2006-08-17 | Yokogawa Electric Corporation | 分散情報統合方法及び分散情報統合システム |
JP2007149067A (ja) * | 2005-10-28 | 2007-06-14 | Ricoh Co Ltd | 文書管理システム |
US8639670B2 (en) | 2006-01-18 | 2014-01-28 | Fujitsu Limited | Data integration apparatus, data integration method, and computer product |
US8561128B2 (en) | 2006-10-20 | 2013-10-15 | Canon Kabushiki Kaisha | Document management system and document management method |
US11899668B2 (en) | 2013-08-12 | 2024-02-13 | International Business Machines Corporation | Database management apparatus, database control method and program |
Also Published As
Publication number | Publication date |
---|---|
US20020055921A1 (en) | 2002-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2002149468A (ja) | マルチデータベース統合システムのアクセス権管理方法 | |
CA2508928C (en) | Method, system, and apparatus for discovering and connecting to data sources | |
US10108813B2 (en) | Query conditions-based security | |
US6480863B1 (en) | Method and system for multi-entry and multi-template matching in a database | |
JP4571746B2 (ja) | アプリケーション機能に対するアクセスを選択的に規定するためのシステムおよび方法 | |
US7620658B2 (en) | Configuration of a directory system | |
US7979456B2 (en) | Method of managing and providing parameterized queries | |
US20050027724A1 (en) | Data processing apparatus and method | |
US20130110873A1 (en) | Method and system for data storage and management | |
US6651070B1 (en) | Client/server database system | |
US20010056428A1 (en) | Method and system for improved access to non-relational databases | |
US20070156687A1 (en) | Efficient implementation of multiple work areas in a file system like repository that supports file versioning | |
EP2800013B1 (en) | Integration database framework | |
US7716178B2 (en) | Systems and methods for monitoring database replication | |
US20060026180A1 (en) | System and method for automatically synchronizing security-relevant information between a relational database and a multidimensional database | |
US20030088615A1 (en) | Update resolution procedure for a directory server | |
US20040139141A1 (en) | Integration of virtual data within a host operating environment | |
Motro et al. | Multiplex, fusionplex and autoplex: three generations of information integration | |
JPH04104342A (ja) | データ分散管理方法及び管理システム | |
US20020188774A1 (en) | Virtualizing external data as native data | |
US20020188727A1 (en) | Method for processing external data for access and manipulation through a host operating environment | |
Tebbutt | Guidelines for the evaluation of X. 500 directory products | |
JPH06309203A (ja) | データベース処理システムの排他制御方法 | |
ZA200206732B (en) | Method of and system for managing electronic files. | |
Server | Catalog Views and Dynamic Management Views |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060821 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061003 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070213 |