JP2016115223A - データベース管理システム、データベース管理方法、およびプログラム。 - Google Patents

Abstract

【課題】スキーマの修正履歴情報が記憶されていない個別に管理されているデータベースを、マスタデータベースに対応するように統一して更新する。【解決手段】マスタデータベースと、マスタデータベースを基準とする顧客毎データベースを有し、顧客毎データベースはマスタデータベースの管理外で変更されうる。顧客毎データベースは、テーブル毎のバージョン情報と更新日時情報とを有し、顧客毎データベースのスキーマとマスタデータベースのスキーマの違いを抽出し、顧客毎データベースのスキーマをマスタデータベースのスキーマに統一する差分ＳＱＬを抽出する。抽出された差分ＳＱＬを適用させる顧客毎データベース内のテーブル情報を特定し、顧客毎データベースの有するバージョン情報もしくは更新日時情報がマスタデータベースのバージョン情報もしくは更新日時情報と異なる場合、顧客毎データベースで特定されたテーブルに対して差分ＳＱＬを発行する。【選択図】図１

Description

本発明は、複数のデータベースを管理するマスタデータベースの運用技術に関する。

複数の顧客（テナント）のデータを格納するマスタデータベースと、各顧客（テナント）毎にデータが管理されているデータベース（スレーブデータベース）とがネットワークでは接続されているシステムが存在する。このシステムでは、マスタデータベースの定期的な更新に伴い、各顧客（テナント）毎に個別で管理されているデータベースも統一して更新することがある。

特許文献１では、複数のユーザがいる場合に、データベース定義の修正を比較しながら、プログラム開発者側のデータベース定義文に適切に反映させ、プログラム開発の支援をすることができるデータベース管理システムが開示されている。

特開２００６−２６０５１２

しかしながら、特許文献１のデータベース管理システムでは、複数のユーザのデータベース定義の修正を記憶していることが前提になっており、各顧客（テナント）が個別にデータベーススキーマを修正した情報を管理していない場合は、各顧客（テナント）の独自のスキーマ修正に対しては、データベース管理システムが自動的に対応することができない。

本発明は、スキーマの修正履歴情報が記憶されていない個別に管理されているデータベースを、マスタデータベースに対応するように統一して更新することを目的とする。

本発明は、マスタデータベースと、該マスタデータベースを基準とする顧客毎データベースを有し、該顧客毎データベースは該マスタデータベースの管理外で変更されうるデータベース管理システムであって、前記顧客毎データベースは、該顧客毎データベース内のテーブル毎のバージョン情報と更新日時情報とを有し、前記顧客毎データベースのスキーマと前記マスタデータベースのスキーマの違いを抽出し、該顧客毎データベースのスキーマを該マスタデータベースのスキーマに統一する差分ＳＱＬを抽出する差分ＳＱＬ抽出手段と、前記差分ＳＱＬ抽出手段により抽出された差分ＳＱＬを適用させる前記顧客毎データベース内のテーブル情報を特定するテーブル特定手段と、前記顧客毎データベースの有するバージョン情報が前記マスタデータベースのバージョン情報と異なるか、もしくは該顧客毎データベースの有する更新日時情報が該マスタデータベースの更新日時情報と異なることを判定する差分ＳＱＬ発行判定手段と、前記差分ＳＱＬ発行判定手段により、バージョン情報もしくは更新日時情報が異なると判定された顧客毎データベースの前記テーブル特定手段で特定されたテーブルに対して、前記差分ＳＱＬ抽出手段により抽出された差分ＳＱＬを発行する差分ＳＱＬ発行手段と、を有する。

本発明によれば、スキーマの修正履歴情報が記憶されていない個別に管理されているデータベースを、マスタデータベースに対応するように統一して更新できる効果を有する。

本発明の実施形態のデータベース管理システム（情報処理システム）の構成を示すシステム構成図である。 本発明の実施形態の各種端末のハードウエア構成を示す図である。 本発明の実施形態のデータベース管理システムにおける第１の制御処理手段の一例を示すフローチャートである。 本発明の実施形態のデータベース管理システムにおける第２の制御処理手段の一例を示すフローチャートである。 本発明の実施形態のデータベース管理システムにおける第３の制御処理手段の一例を示すフローチャートである。 本発明の実施形態のデータベース管理システムにおける第４の制御処理手段の一例を示すフローチャートである。 本発明の実施形態のデータベース管理システムにおける第５の制御処理手段の一例を示すフローチャートである。 本発明の実施形態のデータベース管理システムにおける第６の制御処理手段の一例を示すフローチャートである。 本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。 本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。 本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。 本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。

以下、本発明の好ましい実施の形態について図面を参照しながら詳細に説明する。

図１は、本発明に係るデータベース管理システム（情報処理システム）の構成を示すシステム構成図である。

図１において、データベース管理システムは、マスタデータベース１０１を有するデータベース管理サーバ１００と、少なくとも１つ以上の各顧客（テナント）に対するテナントデータベース（更新対象データベース）２０１を有するデータベースサーバ２００とからなる。テナントデータベース２０１はそれぞれの顧客（テナント）毎にテナント毎データベース２１０、２２０等を有しており、それらのサーバはネットワークを介して接続されている。

データベース管理サーバ１００は、保持しているマスタデータベース１０１のスキーマの変更をユーザから受け付け、スキーマが変更されたデータベーステーブルを比較対象テーブル郡１０３として記憶する。同時に、マスタデータベース１０２のバージョン情報をバージョン管理テーブル１０４に記憶する。

データベースサーバ２００のテナント毎データベース２１０や２２０等に記憶された各スキーマは、顧客（テナント）毎に管理されている。そのため、マスタデータベース１０１のバージョン管理とは別に各顧客（テナント）がテナント毎データベース２１０や２２０等のスキーマを変更することがある。本発明は、各顧客（テナント）がスキーマを変更していたとしても、マスタデータベース１０１の更新に伴い統一的にテナント毎データベース２１０や２２０等のスキーマを更新することを目的とする。

また、マスタデータベース１０１の更新に伴い統一的にテナント毎データベース２１０や２２０等のスキーマを更新する際に、検証性チェックを行う。検証性チェックの結果、マスタデータベース１０１と、テナント毎データベース２１０や２２０等のスキーマと、が一致しない場合は、更新エラーとしてユーザに、エラーとなったテナント毎データベースのスキーマを再度マスタデータベースのスキーマで更新させる。それでも更新できない場合は、エラーとなったテナント毎データベースの全てのテーブルのスキーマを元に戻す処理を行う。この処理により、何らかのエラーでスキーマが変更できなかったテナント毎データベースのテーブルは少なくとも、マスタデータベース１０１を更新する前の状態に戻すことができ、マスタデータベース１０１更新前の正常状態までに戻すことができるという効果を有する。

図２は、本発明の実施形態の各種端末のハードウエア構成を示す図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、タッチパネル、ボタン、スイッチ等が挙げられる。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶等が挙げられる。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク２１４を介して外部機器との通信制御処理を実行する。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

以下、図３〜図８を参照して、本発明における実施形態の流れを説明する。

図３は、本発明の実施形態のデータベース管理システムにおける第１の制御処理手段の一例を示すフローチャートであり、図１に示したデータベース管理サーバ１００及びデータベースサーバ２００それぞれのＣＰＵ２０１により処理が実行される。なお、図中のＳ１１〜Ｓ２０は各ステップを示す。

図３のフローチャートは、マスタデータベース１０１のスキーマが変更された後で、テナント毎データベース２１０や２２０等のスキーマをマスタデータベース１０１のスキーマに揃える際に開始されるフローチャートである。

まず、図３のステップＳ１１において、データベース管理サーバ１００のＣＰＵ２０１は、データベースサーバ２００から、各テナントのデータベース一覧情報を取得する。

次に、ステップＳ１２において、データベース管理サーバ１００のＣＰＵ２０１は、データベースサーバ２００のテナントデータベース２０１から各テナントのデータベース情報が取得できたかを判断する。テナント毎データベース２１０や２２０等の情報（スキーマ）を取得できない場合は本発明の処理を終了する。一方、テナント毎データベース２１０や２２０等の情報（スキーマ）を取得できる場合、取得したテナント毎データベース２１０や２２０等の内、一つ（例えば、テナントＡデータベースである２１０）のデータベースのスキーマについて、ステップＳ１３以下の処理を行う。

ステップＳ１３において、データベース管理サーバ１００のＣＰＵ２０１は、マスタデータベース１０１のスキーマと、テナント毎データベース２１０のスキーマの差分を抽出する処理を行う。詳細を図４を参照して説明する。

図４は、本発明の実施形態のデータベース管理システムにおける第２の制御処理手段の一例を示すフローチャートであり、図１に示したデータベース管理サーバ１００のＣＰＵ２０１により処理が実行される。なお、図中のＳ３１〜Ｓ３３は各ステップを示す。

まず、図４のステップＳ３１において、データベース管理サーバ１００のＣＰＵ２０１は、マスタデータベース１０１のスキーマとステップＳ１２で取得したテナント毎データベース２１０のスキーマとから、差分ＳＱＬを取得する。ステップＳ３１で取得する差分ＳＱＬは、テナント毎データベース２１０等のスキーマをマスタデータベース１０１のスキーマに揃えようとした際に、何らかの原因でエラーとなった際にマスタデータベース１０１のスキーマに揃えようとしたテナント毎データベース２１０等のスキーマを元のスキーマに復元するための差分ＳＱＬである。

差分ＳＱＬの取得方法としては、例えば、ＳＱＬＳｅｒｖｅｒの場合、ＳｑｌＰａｃｋａｇｅ．ｅｘｅというツールを利用し、以下の２行のスクリプトで取得することができる。
＜スクリプト例＞

ＳｑｌＰａｃｋａｇｅ．ｅｘｅ ／ａ：Ｅｘｔｒａｃｔ ／ｓｃｓ：”＜マスタデータベースのＤＢ接続文字列＞” ／ｔｆ：”＜マスタデータベースのＤＢスナップショットファイル出力パス＞”

ＳｑｌＰａｃｋａｇｅ．ｅｘｅ ／ａ：Ｓｃｒｉｐｔ ／ｓｆ：”＜マスタデータベースのＤＢスナップショットファイル出力パス＞” ／ｔｃｓ：”＜テナント毎データベースのＤＢ接続文字列＞” ／ｏｐ：”＜差分ＳＱＬファイルパス＞”

１行目でマスタデータベースのスキーマを＜マスタデータベースのＤＢスナップショットファイル＞に変換し、２行目で＜マスタデータベースのＤＢスナップショットファイル＞とテナント毎データベースとを比較し、＜差分ＳＱＬファイル＞を作成する。

以上の処理により、図９の９０３の様な差分ＳＱＬを取得する。図９を参照して、マスタデータベース１０１内の比較対象テーブル１０２内のスキーマ９０１と、テナント毎データベース２１０内の更新対象テーブル２１１内のスキーマ９０２とから、差分ＳＱＬを取得する例を説明する。

図９は、本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。

図９の９０１は、データベース管理サーバ１００が有する比較対象テーブル群１０２とバージョン管理テーブル１０４であり、９０２は、データベースサーバはテナント毎データベース２１０が有する更新対象テーブル群２１１と定義更新日付管理テーブル２１２である。定義更新日付管理テーブル２１２とは、更新対象テーブル２１１の有するバージョン情報と、過去に比較対象テーブルから更新された更新日時等が記憶されている。

図９の例では、更新対象テーブル２１１内のテーブル１は、項目Ｂの文字列が８桁であるのに対し、比較対象テーブル１０２内のテーブル１では項目Ｂの文字列のように１０桁に変更する（９０７）。また、更新対象テーブル２１１内のテーブル２は、項目Ｋの５０桁の文字列を有するが、比較対象テーブル１０２内のテーブル２では項目Ｋのコラムは無い。そのため、項目Ｋは本発明の処理で削除する（９０８）。

図９のような状況で、比較対象テーブル１０２から更新対象テーブル２１１へ復元する際に取得される差分ＳＱＬとしては、９０３に記載されているＳＱＬが該当する。９０３の２行目がテーブル１の項目Ｂの文字列数を８桁に修正する（戻す）ＳＱＬ（９０７に対応）であり、３行目が文字列数５０桁の項目Ｋを加える（戻す）ＳＱＬ（９０８に対応）である。

これらの復元用ＳＱＬを作成しておくことにより、データベーススキーマの変更に失敗した場合でも、データベーススキーマの復旧が容易になるという効果を有する。図４のフローチャートの説明に戻る。

次に、ステップＳ３２において、データベース管理サーバ１００のＣＰＵ２０１は、復元処理用にテナント毎データベース更新対象が有する定義更新日付管理テーブルから、最新のテーブル名と更新対象のテーブル毎のバージョン情報、比較対象テーブルからの更新日時情報、及びテナント毎データベース２１０の更新対象テーブル２１１が各テナントの管理者などにより更新された実更新日時を取得する。取得した情報の一例が９０４の例である。９０４は、データベースサーバ２００の有する各テナントの定義更新日付管理テーブル２１２の内容と、各テーブルの実更新日時情報とを有している。

次に、ステップＳ３３において、データベース管理サーバ１００のＣＰＵ２０１は、マスタデータベース１０１のスキーマとステップＳ１２で取得したテナント毎データベース２１０のスキーマとから、テナント毎データベース２１０等のスキーマをマスタデータベース１０１のスキーマに揃えるために実行される差分ＳＱＬである。

差分ＳＱＬの取得方法としては、前述と同じように、例えば、ＳＱＬＳｅｒｖｅｒの場合、ＳｑｌＰａｃｋａｇｅ．ｅｘｅというツールを利用し、以下の２行のスクリプトで取得することができる。
＜スクリプト例＞

ＳｑｌＰａｃｋａｇｅ．ｅｘｅ ／ａ：Ｅｘｔｒａｃｔ ／ｓｃｓ：”＜テナント毎データベースのＤＢ接続文字列＞” ／ｔｆ：”＜テナント毎データベースのＤＢスナップショットファイル出力パス＞”

ＳｑｌＰａｃｋａｇｅ．ｅｘｅ ／ａ：Ｓｃｒｉｐｔ ／ｓｆ：”＜テナント毎データベースのＤＢスナップショットファイル出力パス＞” ／ｔｃｓ：”＜マスタデータベースのＤＢ接続文字列＞” ／ｏｐ：”＜差分ＳＱＬファイルパス＞”

２行目の＜差分ＳＱＬファイルパス＞で作成される＜差分ＳＱＬファイル＞の例として、図９の９０５を参照して説明する。

９０５の２行目がテーブル１の項目Ｂの文字列数を１０桁に修正するＳＱＬ（９０７に対応）であり、３行目が項目Ｋを削除するＳＱＬ（９０８に対応）である。

以上の処理により、テナント毎データベース２１０のスキーマをマスタデータベース１０１のスキーマに揃えるためのテナント毎データベース２１０毎に更新用ＳＱＬを抽出する。図３のフローチャートの説明に戻る。

図３のステップＳ１３において、マスタデータベース１０１のスキーマと、テナント毎データベース２１０のスキーマの差分を抽出する処理を行うと、次のステップＳ１４へと処理を移行する。ステップＳ１４において、データベース管理サーバ１００のＣＰＵ２０１は、マスタデータベース１０１から検証用スキーマ定義情報を抽出する。検証用スキーマ定義情報とはマスタデータベース１０１の比較対象テーブル群１０２のスキーマ情報である。

次に、ステップＳ１５において、データベース管理サーバ１００のＣＰＵ２０１は、マスタデータベース１０１内のバージョン管理テーブル１０４から、テーブル名とテーブル毎の更新後バージョンを取得し、データベースサーバ２００へと処理を移行する。

次に、ステップＳ１６において、データベースサーバ２００のＣＰＵ２０１は、テナント毎データベース２１０から復元検証用スキーマ定義情報を抽出する。この復元時検証用スキーマ定義情報とはテナント毎データベース２１０の更新対象テーブル群２１１のスキーマ情報である。

次に、ステップＳ１７において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ１３で抽出されたマスタデータベース１０１に揃えるための差分ＳＱＬと、ステップＳ１５で取得したテーブルバージョン情報ファイル１０４とをデータベース管理サーバ１００から取得し、差分ＳＱＬを発行する処理を実行する。ステップＳ１７の詳細を図５を参照して説明する。

図５は、本発明の実施形態のデータベース管理システムにおける第３の制御処理手段の一例を示すフローチャートであり、図１に示したデータベースサーバ２００のＣＰＵ２０１により処理が実行される。なお、図中のＳ４１〜Ｓ４９は各ステップを示す。

まず、図５のステップＳ４１において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ１３により抽出された差分ＳＱＬから、該当するテナント毎データベース２１０内から差分ＳＱＬ発行対象のテーブル名を検索し、最初に見つかったテーブル名を保持する。

次に、ステップＳ４２において、データベースサーバ２００のＣＰＵ２０１は、差分ＳＱＬ発行対象のテーブル名を検索し、取得できるかを判断する。差分ＳＱＬ発行対象のテーブル名を取得できない場合は、図５のフローチャートを終える。一方、差分ＳＱＬ発行対象のテーブル名を取得できる場合は、該当するテーブルを保持して、次のステップＳ４３へと処理を移行する。

次に、ステップＳ４３において、データベースサーバ２００のＣＰＵ２０１は、データベースサーバ２００が有する定義更新日付管理テーブル２１２内の、該当するテーブルのバージョンと更新日時を取得する。

次に、ステップＳ４４において、データベースサーバ２００のＣＰＵ２０１は、データベースサーバ２００が有する定義更新日付管理テーブル２１２内の該当するテーブルのバージョンと、ステップＳ１５で取得したテーブルバージョン情報ファイル１０４内の該当テーブルのバージョンが異なるかを判断する。定義更新日付管理テーブル２１２内の該当するテーブルのバージョンと、テーブルバージョン情報ファイル１０４内の該当テーブルのバージョンとが異なれば、ステップＳ４６へと処理を移行する。一方、定義更新日付管理テーブル２１２内の該当するテーブルのバージョンと、テーブルバージョン情報ファイル１０４内の該当テーブルのバージョンとが同じであれば、ステップＳ４５へと処理を移行する。

ステップＳ４５へと遷移すると、データベースサーバ２００のＣＰＵ２０１は、データベースサーバ２００の更新対象テーブル２１１が有する実更新日時情報を取得し、その実更新日時と、定義更新日付管理テーブル２１２内の該当テーブルの更新日時が異なるかを判断する。実更新日時と定義更新日付管理テーブル２１２内の該当テーブルの更新日時が異なる場合はステップＳ４６へと処理を移行する。一方、実更新日時と定義更新日付管理テーブル２１２内の該当テーブルの更新日時が同じであれば、ステップＳ４２へと処理へと戻り、次の該当する差分ＳＱＬ発行対象のテーブル名を取得できるかの判断へと移行する。

以上、ステップＳ４４とステップＳ４５により、該当する更新対象テーブルのバージョンが比較対象テーブルのバージョンと異なっているか、もしくは更新対象テーブルの実更新日時が定義更新日付管理テーブル２１２の更新日時と異なっていれば、差分ＳＱＬを発行する処理ステップＳ４６へと処理を移行する。ステップＳ４４によりステップＳ４６へと処理を移行させるパターンが図９の９０６の例に該当し、ステップＳ４５によりステップＳ４６へと処理を移行させるパターンが図９の９０９と９１０の例に該当する。

ステップＳ４５において、更新対象テーブルの実更新日時が定義更新日付管理テーブル２１２の更新日時と異なる場合とは、たとえば、テナント毎データベースのスキーマを本ツールを使用せずに変更した場合などに生じることがある。その際は次に説明するステップＳ４６において、該当する統一したスキーマに変更する。

次に、ステップＳ４６において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ１３で抽出した差分ＳＱＬ処理を該当する更新対象テーブルに対して実行する。実行された更新対象テーブルは、正常に機能すれば、図１０の１００２の更新対象テーブル群２１１のように、比較対象テーブル群と同じスキーマに変更される。

次に、ステップＳ４７において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ４６が正常に処理されたかを判断する。ステップＳ４６が正常に処理されていれば、ステップＳ４８へと処理を移行し、ステップＳ４６が正常に処理されなかった場合は、ステップＳ４２へと遷移し、次の差分ＳＱＬ発行対象テーブルを検索する。

ステップＳ４８へと処理を移行すると、データベースサーバ２００のＣＰＵ２０１は、定義更新日付管理テーブルの更新日時を更新し、ステップＳ４９において、次の差分ＳＱＬ発行対象テーブルを検索、取得して、ステップＳ４２へと処理を戻す。図１０を参照して、正常に完了した場合のデータベースのスキーマ情報を説明する。

図１０は、本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。

図１０の１００１と１００２はそれぞれ図９の９０１と９０２に対応している。テナント毎データベース２１０のスキーマ情報は、１００３から１００６のように更新されている。

以上の処理によりテナント毎データベース内の差分ＳＱＬ発行対象テーブルのスキーマをマスタデータベース１０１の比較対象テーブルのスキーマに揃えることができ、個別に変更されうるテナント毎データベースのスキーマをマスタデータベースに対応するように統一して更新することができる。以上、図５を参照して、差分ＳＱＬを発行する処理について説明した。図３のフローチャートの説明に戻る。

図３のステップＳ１７において、差分ＳＱＬを発行する処理を実行すると、次にステップＳ１８において、ステップＳ１７で発行した差分ＳＱＬが正常に実行されたかを確認する。ステップＳ１８の処理を図６を参照して説明する。

図６は、本発明の実施形態のデータベース管理システムにおける第４の制御処理手段の一例を示すフローチャートであり、図１に示したデータベースサーバ２００のＣＰＵ２０１により処理が実行される。なお、図中のＳ５１〜Ｓ５４は各ステップを示す。

まず、図６のステップＳ５１において、データベースサーバ２００のＣＰＵ２０１は、テナント毎データベースのスキーマからスキーマ定義情報をＳＱＬにより取得し、ファイル出力する。

次に、ステップＳ５２において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ１４で抽出したマスタデータベース１０１の検証用スキーマ定義情報をデータベース管理サーバ１００から受信し、受信した検証用スキーマ定義情報とステップＳ５１で取得したスキーマ定義情報とを比較する。

ステップＳ５３で、比較結果が一致している場合は、図６のフローチャートの処理を終了するが、比較結果が異なる場合は、ステップＳ５４へと処理を移行する。

ステップＳ５４へと処理を移行すると、データベースサーバ２００のＣＰＵ２０１は、不一致だったスキーマ名／テーブル名／差分ＳＱＬ／更新後バージョンをリトライ用ログとして出力する。リトライ用ログファイルの出力例として、図１１を参照して説明する。

図１１は、本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。

図１１において、１１０２の更新対象テーブルのスキーマを１１０１の比較対象テーブルのスキーマへ更新する時、１１０３の項目Ｂの文字列が８桁から１０桁に更新できない場合、リトライログとしては、例えば、１１０８のようなリトライ用ログファイルが作成される。具体的には、１１０８のリトライログファイルは、１１０５部分のスキーマ名のテーブル名に対して、１１０６部分の差分ＳＱＬを再実行（リトライ）させるファイルである。図６のフローチャートの説明に戻る。

ステップＳ５４において、リトライ用ログとして出力すると図６のフローチャートの処理を終え、図３のフローチャートのしょりに戻る。

図３のステップＳ１８において、ステップＳ１７で発行した差分ＳＱＬが正常に実行されたかを確認すると、次の処理をデータベース管理サーバ１００へと移行し、ステップＳ１９において、データベース管理サーバ１００のＣＰＵ２０１は、データベースサーバ２００からリトライ用ログファイルを取得し、記憶しておく。

次に、ステップＳ２０において、データベース管理サーバ１００のＣＰＵ２０１は、次のテナント毎データベース（たとえば、２２０）を検索、取得し、ステップＳ１２へと処理を戻す。

以上の処理を繰り返すことにより、スキーマの修正履歴情報が記憶されていない個別に管理されているテナント毎データベースを、マスタデータベースに対応するように統一して更新でき、また、テナント毎データベースの更新ができなかった場合のリトライ用ログファイルを作成することができる。

次に、図７を参照して、テナント毎データベースが更新されなかった場合の処理の流れを説明する。

図７は、本発明の実施形態のデータベース管理システムにおける第５の制御処理手段の一例を示すフローチャートであり、図１に示したデータベース管理サーバ１００及びデータベースサーバ２００それぞれのＣＰＵ２０１により処理が実行される。なお、図中のＳ６１〜Ｓ６６は各ステップを示す。

図７のフローチャートは、テナント毎データベース２１０や２２０等の更新がされなかった場合に、開始されるフローチャートである。

まず、図７のステップＳ６１において、データベース管理サーバ１００のＣＰＵ２０１は、図３のステップＳ１９でデータベースサーバ２００より取得したリトライ用ログファイルから、リトライ（再実行）する処理対象のスキーマ名／テーブル名／差分ＳＱＬ／更新後バージョンの一行分を取得する。

次に、ステップＳ６２において、データベース管理サーバ１００のＣＰＵ２０１は、ステップＳ６１でリトライ用ログファイルの一行分を取得できたかを判断する。リトライ用ログファイルを取得できない場合は、図７のフローチャートの処理を終え、リトライ用ログファイルを取得できる場合は、ステップＳ６３へと処理を移行する。

ステップＳ６３において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ６１で指定されたスキーマ／テーブルに対して、ステップＳ６１で取得した差分ＳＱＬを発行し、差分ＳＱＬを実行する。実行される差分ＳＱＬの例としては、例えば、図１１の１１０６等である。

次に、ステップＳ６４において、データベースサーバ２００のＣＰＵ２０１は、定義更新日付管理テーブル２１２の情報を更新する。更新内容は、図１０の定義更新日付管理テーブル２１２の内容と同じように、更新日時と図１１の１１０７のバージョン情報で更新する。

次に、ステップＳ６５において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ６３で発行した差分ＳＱＬが正常に実行されたかを確認する。ステップＳ６５の処理はステップＳ１８と同様であり、図６の記載内容と同様なので説明を省略する。

次に、処理をデータベース管理サーバ１００へと戻し、ステップＳ６６において、データベース管理サーバ１００のＣＰＵ２０１は、ステップＳ６５で更に出力されたリトライ用ログファイルをデータベースサーバ２００から取得する。その後、リトライ用ログファイルの残りの行を取得し、ステップＳ６２へと処理を戻し、ステップＳ６２以降の処理を繰り返す。

このように、図７のフローチャートではリトライ用ログファイルに出力された再実行すべき差分ＳＱＬを再実行させる処理を実現している。

次に図８を参照して、テナント毎データベースが更新されなかった場合にテナント毎データベース内のテーブルを全て元に戻す処理の流れを説明する。

図８は、本発明の実施形態のデータベース管理システムにおける第６の制御処理手段の一例を示すフローチャートであり、図１に示したデータベース管理サーバ１００及びデータベースサーバ２００それぞれのＣＰＵ２０１により処理が実行される。なお、図中のＳ７１〜Ｓ７８は各ステップを示す。

図８のフローチャートは、テナント毎データベース２１０や２２０等の更新がされず、ユーザによりテナント毎データベースを元に戻す命令が発行された際に開始されるフローチャートである。

まず、図８のステップＳ７１において、データベース管理サーバ１００のＣＰＵ２０１は、図３のステップＳ１９でデータベースサーバ２００より取得したリトライ用ログファイルから、復元する処理対象のスキーマ名を一件取得する。

次に、ステップＳ７２において、データベース管理サーバ１００のＣＰＵ２０１は、ステップＳ７１でリトライ用ログファイルの一件分のスキーマ名を取得できたかを判断する。スキーマ名を取得できない場合は、図７のフローチャートの処理を終え、スキーマ名を取得できる場合は、ステップＳ７３へと処理を移行する。

ステップＳ７３において、データベースサーバ２００のＣＰＵ２０１は、データベース管理サーバ１００のステップＳ１３（図４のステップＳ３１）で抽出した復元するための差分ＳＱＬを取得し、復元用差分ＳＱＬを発行する。発行する復元用差分ＳＱＬとして、図９の９０３を例に挙げる。図８の処理で用いられるデータの例を図１２を参照して説明する。

図１２は、本発明の実施形態のデータベース管理システムにおけるデータベースのスキーマのバージョン情報並びにスキーマ情報の一例を示す模式図である。

図１２の１２０１は、データベースサーバ２００のテナント毎データベース２１０が有する更新対象テーブル群２１１と定義更新日付管理テーブル２１２である。１２０１は、図８のフローチャートの処理を終えた段階での値が反映されており、ステップＳ７２の段階では、テナント毎データベース２１０の内容は、たとえば、図９の定義更新日付管理テーブル２１２の値と、図１１の更新対象テーブル群２１１を有する。図８のフローチャートの説明に戻る。

図８のステップＳ７３において、たとえば、図１２の復元用差分ＳＱＬ９０３を発行すると、マスタデータベース１０１のスキーマに更新されていたテナント毎データベース２１０は、元の更新前の更新対象テーブル状態に戻される。元の更新前の更新対象テーブルに戻った状態が図１２の１２０２や１２０３である。

次に、ステップＳ７４において、復元テーブルバージョン情報ファイル内の定義更新日付管理テーブルの更新日時部分と、実更新日時部分とが一致するかにより、定義更新日付管理テーブルの更新日時の設定値を変える処理分岐を行う。ステップＳ７４において、復元テーブルバージョン情報ファイル内の定義更新日付管理テーブルの更新日時部分と、実更新日時部分とが一致していれば、ステップＳ７５へと遷移し、復元テーブルバージョン情報ファイル内の定義更新日付管理テーブルの更新日時部分と、実更新日時部分とが異なれば、ステップＳ７６へと遷移する。

ステップＳ７５へと処理を遷移すると、定義更新日付管理テーブルの更新日時は、更新対象テーブル２１１の実更新日時と同じ日時を登録する。図１２を参照して、図８のフローチャートによる定義更新日付管理テーブルの更新日時の設定値を説明する。

図１２の復元用テーブルバージョン情報ファイル（図９の９０４と同じ）内の定義更新日付管理テーブルの更新日時部分と、実更新日時部分とが一致している１２０４と１２０５のようなテーブル１の例であれば、１２０８のようにテーブル１の実更新日時を定義更新日付管理テーブル２１２の更新日時の欄に登録する（１２０９）。図８のフローチャートの説明に戻る。

一方、ステップＳ７６へと処理を遷移すると、定義更新日付管理テーブルの更新日時は、復元用テーブルバージョン情報ファイルの実更新日時の部分の値を登録する。図１２を参照して、図８のフローチャートによる定義更新日付管理テーブルの更新日時の設定値を説明する。

図１２の復元用テーブルバージョン情報ファイル（図９の９０４と同じ）内の定義更新日付管理テーブルの更新日時部分と、実更新日時部分とが異なっている１２０６と１２０７のようなテーブル２の例であれば、復元用テーブルバージョン情報ファイルの実更新日時の部分の値である１２０７の値を定義更新日付管理テーブル２１２の更新日時の欄に登録する（１２１０）。

以上の処理により、復元用テーブルバージョン情報ファイル内の更新日時同士が一致しているかいないかをマスタデータベース１０１の更新の度に確認することで、更新対象テーブル２１１の実更新日時が自動的に更新されても、定義更新日付管理テーブルの更新日時と実更新日時とを比較できるので、データベーススキーマを復元するかしないかを判断できる効果を有する。図８のフローチャートの説明に戻る。

次に、図８のステップＳ７７の処理へと遷移し、ステップＳ７７において、データベースサーバ２００のＣＰＵ２０１は、ステップＳ７３で発行した差分ＳＱＬが正常に実行されたかを確認する。ステップＳ７７の処理はステップＳ１８と同様であり、図６の記載内容と同様なので説明を省略する。

次に、処理をデータベース管理サーバ１００へと戻し、ステップＳ７８において、データベース管理サーバ１００のＣＰＵ２０１は、ステップＳ７７で更に出力されたリトライ用ログファイルをデータベースサーバ２００から取得する。その後、リトライ用ログファイルの残りの復元処理対象のスキーマ名を取得し、ステップＳ７２へと処理を移行し、ステップＳ７２以降の処理を行う。

ステップＳ７２において、復元処理対象のスキーマ名が取得できなくなれば、図８の処理を終了する。

以上の処理により、更新対象テーブル２１１の実更新日時が自動的に更新されるデータベースでも、定義更新日付管理テーブルを有することにより、テナント側の管理者がスキーマを更新したことを把握可能にし、マスタデータベース１０１のバージョンアップに伴うスキーマのバージョンアップの際に、バージョン更新ができない場合でも、テナント毎データベースの全てのデータのバックアップを参照することなしに、スキーマのバージョンアップを取り止め、元のスキーマに容易に戻すことができるという効果を有する。

このように、本発明のデータベース管理システムにおいて、スキーマの修正履歴情報が記憶されていない個別に管理されているデータベースを、マスタデータベースに対応するように統一して更新できる効果を有する。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

なお、本実施形態中に示した各変形例を組み合わせた構成も全て本発明に含まれるものである。

以上説明したように、本実施形態によれば、ワークフローシステムにおいて、閲覧権限が無いユーザに対して、起票者や承認者が閲覧権限を与えることにより、閲覧権限の無いユーザが電子伝票を確認可能になり、また、ユーザや電子伝票の閲覧権限を期限もしくは、アクティビティ毎に閲覧権限を削除することを可能とする。

従って、システム管理者ではなく一般のユーザが電子伝票（案件）ごとに閲覧権限を追加でき、電子伝票を処理中のユーザが閲覧権限の無いユーザに電子伝票の内容を確認してもらう場合などでも、容易に閲覧権限の無いユーザに確認してもらうことが可能になる等の効果を奏する。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図３〜図８に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

１００ データベース管理サーバ
１０１ マスタデータベース
１０２ 比較対象テーブル群
１０４ バージョン管理テーブル
２００ データベースサーバ
２０１ テナントデータベース２０１
２１０ テナントＡデータベース
２１１ 更新対象テーブル群
２１２ 定義更新日付管理テーブル
２２０ テナントＢデータベース
２２１ 更新対象テーブル群
２２２ 定義更新日付管理テーブル
６００ ネットワーク

Claims (5)

1. マスタデータベースと、該マスタデータベースを基準とする顧客毎データベースを有し、該顧客毎データベースは該マスタデータベースの管理外で変更されうるデータベース管理システムであって、
   前記顧客毎データベースは、該顧客毎データベース内のテーブル毎のバージョン情報と更新日時情報とを有し、
   前記顧客毎データベースのスキーマと前記マスタデータベースのスキーマの違いを抽出し、該顧客毎データベースのスキーマを該マスタデータベースのスキーマに統一する差分ＳＱＬを抽出する差分ＳＱＬ抽出手段と、
   前記差分ＳＱＬ抽出手段により抽出された差分ＳＱＬを適用させる前記顧客毎データベース内のテーブル情報を特定するテーブル特定手段と、
   前記顧客毎データベースの有するバージョン情報が前記マスタデータベースのバージョン情報と異なるか、もしくは該顧客毎データベースの有する更新日時情報が該マスタデータベースの更新日時情報と異なることを判定する差分ＳＱＬ発行判定手段と、
   前記差分ＳＱＬ発行判定手段により、バージョン情報もしくは更新日時情報が異なると判定された顧客毎データベースの前記テーブル特定手段で特定されたテーブルに対して、前記差分ＳＱＬ抽出手段により抽出された差分ＳＱＬを発行する差分ＳＱＬ発行手段と、
   を有することを特徴とするデータベース管理システム。
2. 前記顧客毎データベースのスキーマが、前記マスタデータベースのスキーマに変更されたことを検証するために、該マスタデータベースのスキーマ定義情報を抽出する検証用スキーマ定義情報抽出手段と、
   前記差分ＳＱＬ発行手段により発行された前記顧客毎データベースのスキーマ定義情報と、前記検証用スキーマ定義情報抽出手段により抽出された前記マスタデータベースのスキーマ定義情報とを比較し、一致しない場合に該マスタデータベースのスキーマ定義情報と一致させるＳＱＬを抽出する再実行ＳＱＬ抽出手段と、
   を有することを特徴とする請求項１に記載のデータベース管理システム。
3. 前記顧客毎データベースのスキーマと前記マスタデータベースのスキーマの違いを抽出し、該マスタデータベースのスキーマから該顧客毎データベースのスキーマに戻すための差分ＳＱＬを抽出する復元差分ＳＱＬ抽出手段と、
   前記顧客毎データベースのスキーマが、前記マスタデータベースのスキーマに変更されたことを検証するために、該マスタデータベースのスキーマ定義情報を抽出する検証用スキーマ定義情報抽出手段と、
   前記差分ＳＱＬ発行手段により発行された前記顧客毎データベースのスキーマ定義情報と、前記検証用スキーマ定義情報抽出手段により抽出された前記マスタデータベースのスキーマ定義情報とを比較し、一致しない場合に、前記復元差分ＳＱＬ抽出手段で抽出された差分ＳＱＬにより、元の該顧客毎データベースのスキーマに戻す復元差分ＳＱＬ発行手段と、
   を有することを特徴とする請求項１又は２に記載のデータベース管理システム。
4. マスタデータベースと、該マスタデータベースを基準とする顧客毎データベースを有し、該顧客毎データベースは該マスタデータベースの管理外で変更されうるデータベース管理システムにおけるデータベース管理方法であって、
   前記顧客毎データベースは、該顧客毎データベース内のテーブル毎のバージョン情報と更新日時情報とを有し、
   前記顧客毎データベースのスキーマと前記マスタデータベースのスキーマの違いを抽出し、該顧客毎データベースのスキーマを該マスタデータベースのスキーマに統一する差分ＳＱＬを抽出する差分ＳＱＬ抽出ステップと、
   前記差分ＳＱＬ抽出ステップにより抽出された差分ＳＱＬを適用させる前記顧客毎データベース内のテーブル情報を特定するテーブル特定ステップと、
   前記顧客毎データベースの有するバージョン情報が前記マスタデータベースのバージョン情報と異なるか、もしくは該顧客毎データベースの有する更新日時情報が該マスタデータベースの更新日時情報と異なることを判定する差分ＳＱＬ発行判定ステップと、
   前記差分ＳＱＬ発行判定ステップにより、バージョン情報もしくは更新日時情報が異なると判定された顧客毎データベースの前記テーブル特定ステップで特定されたテーブルに対して、前記差分ＳＱＬ抽出ステップにより抽出された差分ＳＱＬを発行する差分ＳＱＬ発行ステップと、
   を有することを特徴とするデータベース管理方法。
5. 請求項１乃至３に記載のデータベース管理システムとして、コンピュータを機能させるためのプログラム。

Images