JP3545589B2

JP3545589B2 - Database migration method

Info

Publication number: JP3545589B2
Application number: JP05223898A
Authority: JP
Inventors: 政彦小原; 健山口; 元一勝谷; 藤男中野; 淳徳永
Original assignee: NTT Comware Corp
Current assignee: NTT Comware Corp
Priority date: 1998-03-04
Filing date: 1998-03-04
Publication date: 2004-07-21
Anticipated expiration: 2018-03-04
Also published as: JPH11250093A

Description

【０００１】
【発明の属する技術分野】
本発明は、個別に運用されていた複数のデータベースによって構成されるシステムから共用データベースシステムへの移行させるデータベース移行方法に関する。
【０００２】
【従来の技術】
近年の情報化社会にあっては、企業の活動を支援するために各種の情報処理装置が用いられる。例えば、大企業においては、人事システム、給与システムあるいは社宅システムといった個別のデータベースによって人材管理が行われることが多い。
【０００３】
このようなシステムにおいては、相互に関連するデータに基づいて処理を行っているので、一つのアプリケーションでデータの更新が行われると他のアプリケーションに更新されたデータをファイル化して転送する必要が生じることがある。例えば、従業者が昇進に伴いある事業所から別の事業所に異動になり、この異動に関する情報が、まず、人事システムに入力されたとする。この場合、昇進に伴って給与は昇給するのでこの情報を給与システムに渡す必要があり、また、勤務先が変更になるので社宅に関する情報を社宅システムに渡す必要が生じる。このため、人事システムでは、従業者の異動に係わるデータを相手方のシステムで読み取れるようにデータ形式を変換してファイルを作成する。そして、ファイルを格納した磁気ディスクを相手先のシステムで読み込んだり、あるいは、通信網を介してファイルを転送していた。
【０００４】
ここで、Ｎ個のシステムが相互に関連して動作しているとすれば、システム全体の変換アプリケーション数はＮ（Ｎ−１）個となるので、全体を構成するシステム数が増加すると、必要とされる変換アプリケーション数が飛躍的に増加してしまう。このため、変換アプリケーションを開発する工数、変換処理に要する工数、あるいは、変換アプリケーションを記憶するコンピュータ資源を消費してしまうといった問題がある。
また、あるシステムでデータが更新された場合に、更新されたデータが他のシステムに反映されるまでには時間がかかるので、最新のデータに基づく情報を提供することができないといった問題があった。
【０００５】
そこで、各システムで共通するデータを共有する共用データベースシステムが開発されている。共用データベースシステムは、例えば、人事システム、給与システム、社宅システムといった個別システム、各個別システムからのデータを一元的に記憶した原本データベース、および各個別システムと原本データベースとを接続するＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）から構成されている。
【０００６】
この原本データベースには、個別システムに共通する共通データが各種のテーブルの形態で格納されており、また、各個別システムには当該システムでのみ用いられる個別データがテーブルの形態で格納されている。
【０００７】
【発明が解決しようとする課題】
ところで、このような共用データベースシステムは、個別システムを異なるロケーションに配置する分散システムとして構築されるのが通常である。このため、分散した各個別システムの整合性を保証する必要がある。整合性を保証する方式としては、２フェーズコミット制御と呼ばれる制御方式が提案されており、そこでは、１回目に各個別システムが更新可能であるか否かを問い合わせ、２回目に実際の更新が行われる。
しかしながら、２フェーズコミット制御では、トランザクション量が大きくなるので、例えば、月曜日の１０時といった特定の時間に処理が集中すると、処理に長時間を要するといった問題がある。
また、共用データベースシステムを採用する場合には従来の個別システムを破棄して、新規に各個別システムを作り直す必要があり、開発工数、開発時間などの負担が大きいといった問題があった。
【０００８】
本発明は上述した事情に鑑みてなされたものであり、現行のシステムから共用データベースに円滑に以降させるためのデータベース移行方法を提供するものである。
【０００９】
【課題を解決するための手段】
上記課題を解決するため請求項１に記載の発明にあっては、相互に関連する共通データを取り扱う複数のデータベース装置を備え前記共通データを前記複数のデータベース装置間で相互に転送する第１のデータベースシステムから、他の装置から独立した個別データを少なくとも記憶する各個別データベース装置と、前記各個別データベース装置と接続され、他の装置と関連のある共通データを少なくとも記憶する共用データベース装置とを備え前記共通データをリアルタイム更新する共用データベースシステムへ移行させるデータベース移行方法であって、前記共用データベース装置とデータの更新があると更新データを前記共用データベース装置に転送する複数の目的別データベース装置とを備え、前記共用データベース装置は転送された前記更新データをその記憶内容に反映させるとともに前記目的別データベース装置毎に定めれた規則に従って抽出した抽出データを前記複数の目的別データベース装置に各々転送する第２のデータベースシステムを、前記第１のデータベースシステムから前記共用データベースシステムへ移行させる中間段階に設けたことを特徴とする。
【００１０】
また、請求項２に記載の発明にあっては、前記第２のデータベースシステムから前記共用データベースシステムに移行させる場合には、全ての前記目的別データベース装置において２フェーズコミット制御が支障なく行えるようになった後に移行措置を実行することを特徴とする。
【００１１】
また、請求項３に記載の発明にあっては、相互に関連する共通データを取り扱う複数のデータベース装置を備え前記共通データを前記複数のデータベース装置間で相互に転送する第１のデータベースシステムから、他の装置から独立した個別データを少なくとも記憶する各個別データベース装置と、前記各個別データベース装置と接続され、他の装置と関連のある共通データを少なくとも記憶する共用データベース装置とを備え前記共通データをリアルタイム更新する共用データベースシステムへ移行させるデータベース移行方法であって、前記第１のデータベースシステムから、前記共用データベース装置を備えるとともに、前記複数のデータベース装置のうち相互に共通データの範囲が重なる一部のデータベース装置をリアルタイム更新に対応する前記個別データベース装置に変更し、他のデータベース装置は前記共用データベース装置との間でファイル転送を行うことによって遅延更新を行う目的別データベース装置に変更した第２のデータベースシステムに移行させる第１のステップと、前記第２のデータベースシステムから前記共用データベースシステムへ移行させる第２のステップとを備えたことを特徴とする。
【００１２】
また、請求項４に記載の発明にあっては、相互に関連する共通データを取り扱う複数のデータベース装置を備え前記共通データを前記複数のデータベース装置間で相互に転送する第１のデータベースシステムから、他の装置から独立した個別データを少なくとも記憶する各個別データベース装置と、前記各個別データベース装置と接続され、他の装置と関連のある共通データを少なくとも記憶する共用データベース装置とを備え前記共通データをリアルタイム更新する共用データベースシステムへ移行させるデータベース移行方法であって、前記第１のデータベースシステムから、前記共用データベース装置を備えるとともに前記データベース装置をデータの更新があると更新データを前記共用データベース装置に転送する目的別データベース装置に変更し、前記共用データベース装置は転送された前記更新データをその記憶内容に反映させた後、前記目的別データベース装置毎に定めれた規則に従って抽出した抽出データを前記複数の目的別データベース装置に各々転送する第２のデータベースシステムに移行させる第１のステップと、前記第２のデータベースシステムから、前記複数の目的別データベース装置のうち相互に共通データの範囲が重なる一部の目的別データベース装置をリアルタイム更新に対応する前記個別データベース装置に変更した第３のデータベースシステムに移行させる第２のステップと、前記第３のデータベースシステムから前記共用データベースシステムへ移行させる第３のステップとを備えたことを特徴とする。
【００１３】
また、請求項５に記載の発明にあっては、前記第２のステップは、変更の対象となる前記目的別データベース装置において、２フェーズコミット制御が支障なく行えるようになった後に移行措置を実行することを特徴とする。
【００１４】
【発明の実施の形態】
以下、図面を参照しつつ、本発明の一実施形態に係わるデータベース移行方法を説明する。
【００１５】
Ａ．前提
上述したように、分散型の共用データベースシステムを実現する場合には、２フェーズコミット制御に係る処理時間を考慮する必要がある。この場合、更新を行う個別システムの種類によって、更新データの量や、更新データに関連するデータが異なるので、２フェーズコミット制御に要する処理時間は、個別システム毎に相違する。
一方、通信速度や原本データベースの処理速度が高速になり、２フェーズコミット制御の処理時間が短くなって、更新処理が集中した場合でも短時間で処理を行うことが可能になれば、共用データベースシステムに移行することが可能となる。
【００１６】
ここで、移行の方法には、全ての個別システムを共用データベースシステムに移行する第１の態様と、一部の個別システム（新個別システム）を共用データベースシステムに移行し、他の個別システム（旧個別システム）は、当該個別システムにデータを蓄積して変化分のみをファイル化して原本データベースとの間でやり取りするといった第２の態様が考えられる。
【００１７】
ところで、各個別システムのデータは相互に関連しているから、第２の態様では、以下の問題があって、メリットが少ない。すなわち、旧個別システムでは更新データをファイル化して原本データベースに転送するから、新個別システムは、旧個別システムからのデータをリアルタイムで見ることができない。また、旧個別システムは、ファイル転送によって新個別システムで更新されたデータを受け取るから、新個別システムのデータをリアルタイムで見ることができない。
このため、ほとんど個別システムが原本データベースをリアルタイムに更新できる環境が整った状況で共用データベースシステムに移行することが望ましい。
【００１８】
しかしながら、そのような環境が実現するまで、共通データの共有を先延ばしにすると、それまでの間は、上述したように、各個別システム間で各々ファイル転送を行う必要があり、個別システムのいずれかに仕様の変更が生じると、関連する全ての個別システムについて変更する必要があり、処理の柔軟性に欠けるといった問題が生ずる。
【００１９】
そこで、本発明者らはシステムの将来性や柔軟性を考慮して、各個別システム間で相互にファイル転送を行う旧データベースシステムから、一旦、各個別システムが共用データベースに対してデータを遅延更新する中間データベースシステムに移行させ、この中間データベースシステムから分散型の共用データベースシステムに移行させるようにした。
【００２０】
Ｂ．第１実施形態
以下、図面を参照しつつ、第１実施形態に係わる移行方法を説明する。
１．旧データベースシステムから中間データベースシステムへの移行
１−１：旧データベースシステム
まず、旧データベースシステムの構成を説明する。図１は旧データベースシステムの全体構成を示す概念図である。旧データベースシステム１は、図に示すように、データベースＳ１〜Ｓ７から構成されており、人事システムＳ１は従業者の人事異動、勤怠、評価、家族構成等を管理し、給与システムＳ２は従業者の給与を管理し、年金システムは退職者への年金の支給等を管理し、社宅システムは社宅の入居状況を管理し、退職手当システムＳ５は各社員の退職金を管理し、物流システムＳ６は物流を管理し、経理システムＳ７は企業全体の経理を管理している。
このような各データベースＳ１〜Ｓ７は、目的別のデータベースとして構成されており、あるデータベースには当該データベースにのみ用いられる個別データと、他のデータベースで用いられる共通データとが混在して格納されていた。
【００２１】
この場合、個別データは当該データベースにのみ用いられるのでその変更が生じても他のデータベースに影響を与えないが、共通データに変更が生じると他のデータベースに影響を与えるので、変更が生じた共通データをファイル化して関係する他のデータベースに渡す必要があった。
【００２２】
１−２：中間データベースシステム
次に、中間データベースシステムについて説明する。図２は、中間データベースシステムの全体構成を示す概念図である。
【００２３】
図において、中間データベースシステム２は、相異なるロケーションに配置される目的別データベースＳ１’〜Ｓ７’、標準化されたデータを蓄積する共用データベースＤＢ、および各目的別データベースＳ１’〜Ｓ７’と共用データベースＤＢを各々接続するローカルエリアネットワークＬＡＮから構成されている。
【００２４】
各目的別データベースＳ１’〜Ｓ７’は、上述したデータベースＳ１〜Ｓ７に対応しており、標準データを各目的別データベースＳ１’〜Ｓ７’に用いられるレコード形式に変換する変換アプリケーションを備える点を除いて、旧データベースシステム１のデータベースＳ１〜Ｓ７と同様である。変換アプリケーションは、共用データベースＤＢから転送ファイルを受け取ると、そこに格納されているデータを各目的別データベースＳ１’〜Ｓ７’のレコード形式に合致させるようにデータの並替処理を行う。この場合、変換アプリケーションは共用データベースＤＢとの間でのみ動作するので、ごく小規模なプログラム（数Ｋバイト程度）で足りる。
【００２５】
ところで、旧データベースシステム１を構成するデータベースＳ１〜Ｓ７は、通常、業務の必要に応じて構築されるものであるから、あるシステムはＵＮＩＸ、他のシステムはウインドウズといったように異なるオペレーションシステムの下に動作しており、また、それらで扱われるレコード形式は統一されていないのが一般的である。したがって、共用データベースＤＢに統一した形式でデータを格納しようとすると、データベースＳ１〜Ｓ７を統一した規則の下に構築し直す必要があるが、各データベースを始めから作成し直すには、膨大な工数や費用がかかってしまう。しかし、上述した変換アプリケーションを用いることによって、データベースＳ１〜Ｓ７をほとんど変更することなく、旧データベースシステム１から中間データベースシステム２に移行できる。
【００２６】
各目的別データベースＳ１’〜Ｓ７’は、相互に密接な関連を持っている。例えば、人事システムＳ１’に蓄積される従業者の勤怠データは、当該従業者の給与に反映させるため給与システムＳ２’においても必要とされる。また、従業者が社宅を希望する場合には、家族構成を考慮して社宅を斡旋する必要があるため、家族データが社宅システムＳ４’で必要となる。このため、各目的別データベースＳ１’〜Ｓ７’に蓄積されるデータに更新があると、他の目的別データベースＳ１’〜Ｓ７’に共通する更新データをファイル形式で転送することによって共用データベースＤＢが更新データを一旦集約し、共用データベースＤＢから各目的別データベースＳ１’〜Ｓ７’に更新に用いるファイルが転送されるようになっている。この場合、目的別データベースＳ１’〜Ｓ７’から共用データベースＤＢへのファイル転送は、一日毎といったように一定周期で行われる。このため、データの更新はリアルタイムでなく遅延更新となる。
【００２７】
次に、共用データベースＤＢの主要部は、共通データを記憶する原本データベース１０と、原本データベース１０に対して反映抽出処理を行うデータベース管理システムＤＢＭＳとから構成される。ところで、各目的別データベースＳ１’〜Ｓ７’のデータ型式（例えば、１データの文字数）は、それらのアプリケーションに依存する。このため、原本データベース１０は、各個別データベースＳ１〜Ｓ７からの転送ファイルを標準化して得た標準データを蓄積する。各目的別データベースＳ１’〜Ｓ７’にデータを転送する際には、原本データベース１０から必要とされる標準データの抽出処理が行われるようになっている。このため、原本データベース１０のデータ構造は抽出処理を効率良く実行できるようにグルーピングされている。具体的には、社員、学歴あるいは所属といった各種のテーブルから構成されており、テーブル名を指定して検索が行えるようになっている。
【００２８】
また、各目的別データベースＳ１’〜Ｓ７’毎に必要とされるデータは異なる。このため、データベース管理システムＤＢＭＳは、各目的別データベースＳ１’〜Ｓ７’毎に定められた抽出条件（規則）に従って抽出処理を実行するようになっている。この抽出処理は、キー情報を抽出し、キー情報を用いてテーブルを抽出し、抽出されたテーブルを結合することにより行われる。キー情報の抽出は、抽出時期、抽出タイミングの可否、関連するデータの特定といった各機能毎に処理モジュールが用意されており、これに抽出パラメータを与えることにより行われる。この例では、キー情報として社員コードを用いており、社員コードから該当するテーブルが抽出され、これが結合されるようになっている。この場合、データベース管理システムＤＢＭＳは、どのような処理モジュールと抽出パラメータを用いるかを、各目的別データベースＳ１’〜Ｓ７’毎に記憶しており、これを参照することによって、抽出処理が行われ、抽出された標準データがファイル化され各目的別データベースＳ１’〜Ｓ７’に転送されるようになっている。これにより、ある目的別データベースで共通データの変更があると、変更結果を他の目的別データベースに反映させることができる。
【００２９】
このように中間データベースシステム２は、遅延更新を行うものの原本データベース１０において、個別データと共通データとを一元的に管理するので、旧データベースシステム１のように、各個別データベースＳ１〜Ｓ７の間でファイル転送を相互に行うといった手間がなくなる。また、少なくとも、共用データベースＤＢから転送されるファイルを目的別データベースＳ１’〜Ｓ７’が受け入れた時点で、全ての目的別データベースＳ１’〜Ｓ７’に蓄積されているデータが統一されることになるので、各目的別データベースＳ１’〜Ｓ７’の処理結果に統一性を保証することが可能となる。さらに、ある目的別データベースＳ１’〜Ｓ７’に仕様の変更が生じた場合には、当該個別データベースと共用データベースＤＢとの関係を見直すだけで足りるので、旧データベースシステム１に比較して変更に伴うプログラムの作成工数・時間を大幅にすることが可能となる。
【００３０】
２．中間データベースシステムから共用データベースシステムへの移行
上述した中間データベースシステム２から共用データベースシステムへは、上述したように２フェーズコミット制御に要する時間が短縮され、反映処理の集中を考慮しても支障がないような時期に行う。
【００３１】
図３は、共用データベースシステムの全体構成を示す概念図である。図において、共用データベースシステム３の各個別データベースＳ１’’〜Ｓ７’’は、そのデータベースでのみ用いられる個別データを格納する点で、個別データのみならず共通データを蓄積する中間データベースシステム２の目的別データベースＳ１’〜Ｓ７’と相違する。例えば、給与システムＳ４’’で管理する社員の現在給与額が他のシステムで必要とされないとすると、現在給与額に関するデータは個別データに該当する。
【００３２】
ここで、個別データと共通データは各種のテーブルから構成されており、その項目によって関連づけられている。例えば、上述した社員の現在給与額を示すデータが図４（ａ）に示す給与テーブルで与えられ、これが個別データとして給与システムＳ４’’に格納されており、一方、社員の所属を示す所属テーブル（図４（ｂ）参照）が共通データとして原本データベース１０に格納されているものとする。この場合、社員コードが両テーブルに共通する項目であり、これによって、両テーブルを関連づけることができる。
【００３３】
次に、各個別データベースＳ１’’〜Ｓ７’’は、更新されたデータが個別データであるか共通データであるかを判別する判別機構を備えており、判別機構を用いて反映処理が行われる。まず、各個別データベースＳ１’’〜Ｓ７’’に更新データが入力されると、判別機構によって更新データが個別データであるか共通データであるかが判別される。
【００３４】
更新データが個別データである場合には、各個別データベースＳ１’’〜Ｓ７’’自体でデータの更新を行い、一方、更新データが共通データである場合には、更新データをＬＡＮを介して共用データベースＤＢに送信する。共用データベースＤＢでは、データベース管理システムＤＢＭＳを用いて更新データを原本データベース１０の記憶内容に反映させる。
【００３５】
このように、共用データベースシステム３では、個別データと共通データとを分散させて格納するようにしたので、各個別データベースＳ１’’〜Ｓ７’’は共通データのみを共用データベースＤＢに送信すれば反映処理を直ちに行うことができる。したがって、このシステムによれば、中間データベースシステム２のように原本データベース１０から各目的別データベースＳ１’〜Ｓ７’にファイルを転送する必要がなく、データ更新に係わる通信量を削減することができ、しかもリアルタイムでデータを更新することが可能となる。
【００３６】
また、各個別データベースＳ１’’〜Ｓ７’’の抽出処理においては、入力されたコマンドに対応するキー情報に基づいて、検索が行われる。例えば、給与システムＳ４’’において、社員コードを検索キーとして入力し当該社員の現在給与額と所属を出力するコマンドを与えると、給与システムＳ４’’の判別機構は、当該コマンドを検知して、個別データと共通データから抽出処理を行う必要があることを認識する。そして、社員コードをキー情報として図４（ａ）に示す給与テーブルを参照して現在給与額を取得するとともに、共用データベースＤＢに対して当該社員コードに対応する所属を出力するように指示を送る。共用データベースＤＢが指示を受け取ると、データベース管理システムＤＢＭＳは、社員コードに基づいて図４（ｂ）に示す所属テーブルを検索して、当該社員コードに該当する所属を抽出し、これを給与システムＳ４’’に返送する。この後、給与システムＳ４’’は、現在給与額と所属を抽出結果として出力する。これにより、利用者は、検索の対象となるデータが、ネットワーク上のいずれのロケーションに格納されているかを気にすることなく、必要な抽出結果を得ることができる。
【００３７】
このように、第１実施形態に係わるデータベース移行方法によれば、第１段階として旧データベースシステム１から中間データベースシステム２に移行し、第２段階として、中間データベースシステム２から共用データベースシステム３に移行するようにしたので、通信網やコンピュータの開発速度に併せて、円滑に移行させることができる。
すなわち、第１段階においては、旧データベースシステム１の各目的別データベースＳ１’〜Ｓ７’に大幅な変更を加えることなく移行できるので、プログラムの開発工数・時間を削減することができ、しかも原本データベース１０では、共通データを一元的に管理することができる。また、第２段階は、通信網やコンピュータの速度が２フェーズコミット制御を行っても処理に支障が起こらないタイミングで移行するので、リアルタイム更新の利点を充分発揮させることができる。
【００３８】
Ｃ．第２実施形態
上述した実施形態においては、全ての目的別データベースにおいて、２フェーズコミット制御の条件が満たされた時点で第２段階の移行を実行するものであった。これは、各目的別データベースのデータは相互に関連しているから、一部の目的別データベースのみをリアルタイム更新を行う個別データベースに移行させても、他の目的別データベースで遅延更新すると、他の目的別データベースでは更新データをリアルタイムで見ることができず、また一部の個別データベースでは他の目的別データベースからの共通データをリアルタイムでみることができないという理由に基づくものであった。
【００３９】
ところで、共通データの範囲は各目的別データベースＳ１’〜Ｓ７’の仕様に応じて定まるものであるから、例えば、各目的別データベースＳ１’〜Ｓ７’のデータが図５に示すような関係になることもある。この場合、物流システムＳ６’は社宅システムＳ４’との間に共通データＤａを有するが、他の目的別データベースＳ１’〜Ｓ５’、Ｓ７’の間には共通するデータがない。したがって、社宅システムＳ４’と物流システムＳ６’において、２フェーズコミット制御の条件が整った時点でこれらをリアルタイム更新に移行すると、社宅システムＳ４’では物流システムＳ６’によってリアルタイム更新された共通データＤａをリアルタイムで見ることが可能となる。
【００４０】
そこで、第２実施形態は、第１実施形態の第１段階の後、一部の目的別データベースをリアルタイム更新に移行させ、その後、全ての目的別データベースをリアルタイム更新に移行させる移行方法を提供するものである。すなわち、第１段階にあっては、旧データベースシステム１から第１の中間データベースシステム（第１実施形態の中間データシステム２）に移行させ、第２段階にあっては、第１の中間データベースシステム２から一部リアルタイム更新を含む第２の中間データベースシステム２’に移行させ、第３段階にあっては第２の中間データベースシステム２’から共用データベースシステム３に移行させるものである。第１段階は第１実施形態と同様であり、第３段階は第１実施形態の第２段階と同様に全ての個別データベースが２フェーズコミット制御の条件を満たした時点で移行を実行するものであるから、ここでは説明を省略し、第２段階（第１の中間データベースシステム２から第２の中間データベースシステム２’への移行）について説明する。
【００４１】
１．移行の条件
第２段階を実行する条件は、第１の中間データベースシステム２（図２参照）を構成する各目的別データベースＳ１’〜Ｓ７’のうち、相互に共通データの範囲が重なる目的別データベースＳ１’〜Ｓ７’を組として、組単位で２フェーズコミット制御の条件が満たされた時点で移行を行う。
例えば、図５に示す例にあっては、物流システムＳ６’と社宅システムＳ４’とが第１組であり、また、人事システムＳ１’、給与システムＳ２’、年金システムＳ３’、退職手当システムＳ５’、物流システムＳ６’、および給与システムＳ７’が第２組となっている。
【００４２】
ここで、第２組の人事システムＳ１’が第１の中間データベースシステム２の基幹となるデータベースであって、共通データの量が多く、他の目的別データベースからその共通データをアクセスする頻度が高く、２フェーズコミット制御に伴う処理に長時間を必要とし、一方、第１組の物流システムＳ６’では、共通データのデータ量が少なく、２フェーズコミット制御に伴う処理時間が短いものとする。この場合、通信網やコンピュータの速度が次第に高速化すると、第１組の移行条件は満たすが、第２組の移行条件は満たさない時期がくる。そのタイミングでは、第１組のみをリアルタイム更新に移行させ、第２の中間データベースシステム２’を構築することとなる。
【００４３】
２．第２の中間データベースシステム
次に、図６を参照しつつ、第２の中間データベースシステム２’の構成について説明する。なお、この例では、物流システムＳ６’と社宅システムＳ４’をリアルタイム更新に移行させたものとする。
【００４４】
図６に示す第２の中間データベースシステム２’において、物流システムＳ６’’と社宅システムＳ４’’は個別データをそれ自体で記憶し、原本データベース１０は、物流システムＳ６’’と社宅システムＳ４’’との共通データおよび他の目的別データベースＳ１’〜Ｓ３’、Ｓ５’、Ｓ７’の共通データを記憶している。
【００４５】
この場合、目的別データベースＳ１’〜Ｓ３’、Ｓ５’、Ｓ７’の反映処理および抽出処理は、第１実施形態で説明したファイル転送の形式で行われる。一方、物流システムＳ６’’と社宅システムＳ４’’の反映処理において、更新データが個別データであるならば当該個別データベース自体で格納する。一方、更新データが共通データである場合には、共用データベースＤＢに送り、原本データベース１０の記憶内容をリアルタイムで更新する。
【００４６】
このように第２実施形態にあっては、第１の中間データベースシステム２から第２の中間データベースシステム２’に移行させた後、共用データベースシステム３に移行させるようにしたので、リアルタイム更新を早期に実現させることができる。
【００４７】
なお、上述した第２実施形態においては、第１の中間データベースシステム２から第２の中間データベースシステム２’に移行させたが、旧データベースシステムから第２の中間データベースシステム２’に直接移行させ、この後共用データベースシステム３に移行させるようにしてもよい。
【００４８】
また、上述した個別データベースＳ１’’〜Ｓ７’’は、個別データのみを記憶するものであったが、個別データとともに当該個別データベースで必要とされる共通データを記憶するものであってもよい。この場合には、例えば、検索の使用頻度の高いものについて、個別データと共通データを格納するようにすれば、原本データベース１０へのアクセス頻度を減らすことができるので、共用データベースシステム３を円滑に運用することが可能となる。
【００４９】
【発明の効果】
上述したように本発明に係る発明特定事項によれば、ファイル転送により遅延更新するデータベースシステムを介して共用データベースシステムに移行するようにしたので、簡易かつ円滑に移行を行うことができ、しかも、共通するデータの整合性を保証することが可能となる。
【図面の簡単な説明】
【図１】旧データベースシステムの全体構成を示す概念図である。
【図２】同実施形態に係わる共用データベースの機能構成を示す機能ブロック図である。
【図３】同実施形態に係わる人事システムで生成されるテーブルの例を示す図である。
【図４】（ａ）は同実施形態に係わる給与テーブルの例を示したものであり、（ｂ）は同実施形態に係わる所属テーブルの例を示したものである。
【図５】同実施形態に係わる各目的別データベースに格納されるデータの関係を示す概念図である。
【図６】同実施形態に係わる第２の中間データベースシステムの構成を示すブロック図である。
【符号の説明】
１…旧データベースシステム（第１のデータベースシステム）
２…第１の中間データベースシステム
２’…第２の中間データベースシステム
３…共用データベースシステム
Ｓ１〜Ｓ７…データベース（データベース装置）
Ｓ１’〜Ｓ７’…目的別データベース（目的別データベース装置）
Ｓ１’’〜Ｓ７’’…個別データベース（個別データベース装置）
ＤＢ…共用データベース（共用データベース装置）
ＬＡＮ…ローカルエリアネットワーク（通信網）[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a database migration method for migrating a system constituted by a plurality of individually operated databases to a shared database system.
[0002]
[Prior art]
In the information society in recent years, various information processing devices are used to support corporate activities. For example, in a large company, human resource management is often performed by an individual database such as a personnel system, a salary system, or a company housing system.
[0003]
In such a system, processing is performed based on mutually related data. Therefore, when data is updated by one application, it is necessary to file the updated data to another application and transfer it to another application. Sometimes. For example, suppose that an employee is transferred from one establishment to another due to promotion, and information on this transfer is first input to the personnel system. In this case, since the salary increases with the promotion, it is necessary to pass this information to the salary system, and since the place of employment is changed, it becomes necessary to pass information about the company house to the company house system. Therefore, in the personnel system, a file is created by converting the data format so that the data relating to the employee's transfer can be read by the partner system. Then, the magnetic disk storing the file is read by the partner system or the file is transferred via the communication network.
[0004]
Here, assuming that N systems are operating in relation to each other, the number of conversion applications of the entire system is N (N-1). The number of conversion applications is dramatically increased. For this reason, there is a problem that the man-hour for developing the conversion application, the man-hour required for the conversion process, or the computer resources for storing the conversion application are consumed.
In addition, when data is updated in a certain system, it takes time until the updated data is reflected in another system, so that information based on the latest data cannot be provided. .
[0005]
Therefore, a shared database system has been developed in which each system shares common data. The shared database system is, for example, an individual system such as a personnel system, a salary system, or a company house system, an original database storing data from each individual system in an integrated manner, and a LAN (Local Area Network) connecting each individual system and the original database. ).
[0006]
The original database stores common data common to individual systems in the form of various tables, and individual systems store individual data used only in the system in the form of tables.
[0007]
[Problems to be solved by the invention]
Incidentally, such a shared database system is usually constructed as a distributed system in which individual systems are arranged at different locations. For this reason, it is necessary to ensure the consistency of each distributed individual system. As a method for guaranteeing consistency, a control method called two-phase commit control has been proposed, in which it is first asked whether each individual system can be updated or not. Done.
However, in the two-phase commit control, since the transaction amount is large, there is a problem that if the processing is concentrated at a specific time, for example, 10:00 on Monday, the processing takes a long time.
In addition, when a shared database system is used, it is necessary to discard the conventional individual system and to recreate each individual system, resulting in a large burden on development man-hours and development time.
[0008]
The present invention has been made in view of the above circumstances, and provides a database migration method for smoothly switching from a current system to a shared database.
[0009]
[Means for Solving the Problems]
In order to solve the above-mentioned problem, according to the first aspect of the present invention, there is provided a data processing apparatus comprising: a plurality of database devices for handling mutually related common data; and a first device for mutually transferring the common data between the plurality of database devices. From the database system, each of the individual database devices that stores at least individual data independent of other devices, and a shared database device that is connected to each of the individual database devices and stores at least common data related to the other devices. A database migration method for migrating the common data to a shared database system for real-time updating, comprising: the shared database device and a plurality of purpose-specific database devices that transfer update data to the shared database device when data is updated. , Said shared database device is transferred A second database system that reflects the update data to its storage content and transfers extracted data extracted according to rules determined for each purpose-specific database device to each of the plurality of purpose-specific database devices, The present invention is characterized in that it is provided at an intermediate stage of transition from a database system to the shared database system.
[0010]
Further, in the invention according to claim 2, when migrating from the second database system to the shared database system, two-phase commit control can be performed without hindrance in all the purpose-specific database devices. After that, the transitional measures are executed.
[0011]
Further, in the invention according to claim 3, from a first database system including a plurality of database devices for handling mutually related common data and transferring the common data between the plurality of database devices, Each of the individual database devices that stores at least individual data independent of other devices, and a shared database device that is connected to each of the individual database devices and stores at least common data related to other devices, includes the common data. A database migration method for migrating to a shared database system for real-time updating, wherein the first database system includes the shared database device, and a part of the plurality of database devices in which a range of common data mutually overlaps. Update database device in real time A first database that is changed to the corresponding individual database device, and the other database device is transferred to the second database system changed to a purpose-specific database device that performs a delayed update by performing file transfer with the shared database device. And a second step of migrating from the second database system to the shared database system.
[0012]
Further, according to the invention described in claim 4, a first database system including a plurality of database devices for handling mutually related common data and transferring the common data between the plurality of database devices, Each of the individual database devices that stores at least individual data independent of other devices, and a shared database device that is connected to each of the individual database devices and stores at least common data related to other devices, includes the common data. A database migration method for migrating to a shared database system for real-time updating, comprising: providing said shared database device from said first database system and transferring update data to said shared database device when said database device is updated. Purpose database Device, and the shared database device reflects the transferred update data in its stored content, and then extracts the extracted data extracted according to the rules defined for each of the purpose-specific database devices, to the plurality of purpose-specific database devices. A first step of migrating to a second database system for transferring data to each of the plurality of purpose-specific database devices from the second database system; A second step of transferring the third database system to the third database system which has been changed to the individual database device corresponding to real-time updating, and a third step of transferring the third database system to the shared database system. It is characterized by.
[0013]
Further, in the invention according to claim 5, the second step executes a transition measure after the two-phase commit control can be performed without hindrance in the target database device to be changed. It is characterized by doing.
[0014]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, a database migration method according to an embodiment of the present invention will be described with reference to the drawings.
[0015]
A. Premise
As described above, when implementing a distributed shared database system, it is necessary to consider the processing time involved in two-phase commit control. In this case, the amount of update data and the data related to the update data differ depending on the type of the individual system that performs the update, so that the processing time required for the two-phase commit control differs for each individual system.
On the other hand, if the communication speed and the processing speed of the original database are high, the processing time of the two-phase commit control is short, and even if the update processing is concentrated, the processing can be performed in a short time, the shared database system It is possible to shift to.
[0016]
Here, the migration method includes the first mode in which all individual systems are migrated to the shared database system, and the migration of some individual systems (new individual systems) to the shared database system and other individual systems (old systems). In the second mode, the individual system may store data in the individual system, file only the changed portion, and exchange the file with the original database.
[0017]
By the way, since the data of each individual system is related to each other, the second aspect has the following problems and has few advantages. That is, since the old individual system converts the updated data into a file and transfers it to the original database, the new individual system cannot see the data from the old individual system in real time. Also, the old individual system receives data updated in the new individual system by file transfer, and therefore cannot see the data of the new individual system in real time.
For this reason, it is desirable to migrate to a shared database system in an environment where almost all individual systems can update the original database in real time.
[0018]
However, if the sharing of the common data is postponed until such an environment is realized, in the meantime, as described above, it is necessary to perform the file transfer between the individual systems as described above. When the specification of the crab is changed, it is necessary to change all the related individual systems, and there is a problem that the processing is inflexible.
[0019]
In view of the future potential and flexibility of the system, the present inventors have temporarily delayed the data update from the old database system, which mutually transfers files between the individual systems, to the shared database. The system was migrated to an intermediate database system, and the system was migrated from the intermediate database system to a distributed shared database system.
[0020]
B. First embodiment
Hereinafter, a migration method according to the first embodiment will be described with reference to the drawings.
1. Migration from old database system to intermediate database system
1-1: Old database system
First, the configuration of the old database system will be described. FIG. 1 is a conceptual diagram showing the entire configuration of the old database system. The old database system 1 is composed of databases S1 to S7 as shown in the figure. The personnel system S1 manages personnel transfers, attendance, evaluation, family structure, etc., and the salary system S2 manages employees. The salary management, the pension system manages the payment of pensions to retirees, the company housing system manages the occupancy of company housing, the retirement allowance system S5 manages the retirement allowance of each employee, and the distribution system S6 manages the distribution. The accounting system S7 manages the accounting of the entire company.
These databases S1 to S7 are configured as purpose-specific databases, and one database stores individual data used only for the database and common data used for another database in a mixed manner. Was.
[0021]
In this case, the individual data is used only for the relevant database, so if the change occurs, it does not affect other databases. However, if the common data changes, it affects other databases. The data had to be filed and passed to other databases involved.
[0022]
1-2: Intermediate database system
Next, the intermediate database system will be described. FIG. 2 is a conceptual diagram showing the entire configuration of the intermediate database system.
[0023]
In the figure, an intermediate database system 2 includes purpose-specific databases S1 'to S7' arranged at different locations, a shared database DB for storing standardized data, and purpose-specific databases S1 'to S7' and a shared database DB. Are connected to a local area network LAN.
[0024]
The purpose-specific databases S1 'to S7' correspond to the databases S1 to S7 described above, except that a conversion application for converting standard data into a record format used for the purpose-specific databases S1 'to S7' is provided. Therefore, it is the same as the databases S1 to S7 of the old database system 1. Upon receiving the transfer file from the shared database DB, the conversion application performs a data rearrangement process so that the data stored therein matches the record format of each purpose-specific database S1 'to S7'. In this case, since the conversion application operates only with the shared database DB, a very small program (about several kilobytes) is sufficient.
[0025]
By the way, the databases S1 to S7 constituting the old database system 1 are usually constructed according to business needs, so that one system is under UNIX and another is under a different operation system such as Windows. In general, they operate and the record formats handled by them are not uniform. Therefore, if data is to be stored in the unified format in the shared database DB, it is necessary to reconstruct the databases S1 to S7 under the unified rules. And costs. However, by using the above-described conversion application, it is possible to migrate from the old database system 1 to the intermediate database system 2 with almost no change in the databases S1 to S7.
[0026]
The purpose-specific databases S1 'to S7' are closely related to each other. For example, the employee's attendance data accumulated in the personnel system S1 'is also required in the salary system S2' to reflect the employee's salary. In addition, when an employee desires a company house, it is necessary to arrange the company house in consideration of the family structure, so that family data is required in the company house system S4 '. Therefore, if the data stored in each of the purpose-specific databases S1 'to S7' is updated, the shared database DB is transferred by transferring the update data common to the other purpose-specific databases S1 'to S7' in a file format. The update data is once aggregated, and the files used for the update are transferred from the shared database DB to the purpose-specific databases S1 'to S7'. In this case, the file transfer from the purpose-specific databases S1 'to S7' to the shared database DB is performed at regular intervals, such as every day. For this reason, the data is updated not in real time but in a delayed manner.
[0027]
Next, the main part of the shared database DB includes an original database 10 for storing common data and a database management system DBMS for performing a reflection extraction process on the original database 10. Incidentally, the data type (for example, the number of characters of one data) of each purpose-specific database S1 'to S7' depends on the application. Therefore, the original database 10 accumulates standard data obtained by standardizing the transfer files from the individual databases S1 to S7. When transferring data to the purpose-specific databases S1 'to S7', a process of extracting required standard data from the original database 10 is performed. For this reason, the data structure of the original database 10 is grouped so that the extraction process can be executed efficiently. Specifically, it is composed of various tables such as employees, educational backgrounds, and affiliations, and can be searched by designating table names.
[0028]
The data required for each purpose-specific database S1 'to S7' is different. For this reason, the database management system DBMS executes the extraction process according to the extraction conditions (rules) defined for each purpose-specific database S1 'to S7'. This extraction process is performed by extracting key information, extracting a table using the key information, and combining the extracted tables. Extraction of key information is performed by providing a processing module for each function such as extraction timing, availability of extraction timing, and specification of related data, and by giving an extraction parameter to the processing module. In this example, an employee code is used as key information, and a corresponding table is extracted from the employee code, and this table is joined. In this case, the database management system DBMS stores what processing modules and extraction parameters are used for each purpose-specific database S1 'to S7', and performs extraction processing by referring to these. The extracted standard data is filed and transferred to the purpose-specific databases S1 'to S7'. Thus, when there is a change in the common data in a certain purpose database, the change result can be reflected in another purpose database.
[0029]
Although the intermediate database system 2 performs the delayed update in this way, the individual database and the common data are centrally managed in the original database 10, and therefore, like the old database system 1, the individual databases S1 to S7 have There is no need to transfer files to each other. Further, at least when the purpose-specific databases S1 'to S7' receive files transferred from the shared database DB, the data stored in all the purpose-specific databases S1 'to S7' are unified. Therefore, it is possible to guarantee uniformity in the processing results of the purpose-specific databases S1 'to S7'. Further, when the specifications are changed in certain purpose-specific databases S1 'to S7', it is sufficient to simply review the relationship between the individual database and the shared database DB. It is possible to greatly increase the man-hour and time required for creating a program.
[0030]
2. Migration from intermediate database system to shared database system
The time required for the two-phase commit control is reduced from the above-mentioned intermediate database system 2 to the shared database system as described above, and is performed at a time when there is no problem even if the concentration of the reflection processing is considered.
[0031]
FIG. 3 is a conceptual diagram showing the entire configuration of the shared database system. In the figure, each of the individual databases S1 "to S7" of the shared database system 3 stores individual data used only in that database. The purpose of the intermediate database system 2 is to store not only individual data but also common data. This is different from the different databases S1 'to S7'. For example, if the current salary of the employee managed by the salary system S4 ″ is not required by another system, the data on the current salary corresponds to the individual data.
[0032]
Here, the individual data and the common data are composed of various tables, and are related by their items. For example, the above-mentioned data indicating the current salary of the employee is given in a salary table shown in FIG. 4A, and this is stored as individual data in the salary system S4 ″. (See FIG. 4B) is stored in the original database 10 as common data. In this case, the employee code is an item common to both tables, and thereby, both tables can be associated with each other.
[0033]
Next, each of the individual databases S1 "to S7" includes a discriminating mechanism for discriminating whether the updated data is the individual data or the common data, and the reflection processing is performed using the discriminating mechanism. . First, when update data is input to each of the individual databases S1 ″ to S7 ″, the determination mechanism determines whether the update data is individual data or common data.
[0034]
If the update data is individual data, the data is updated in each of the individual databases S1 "to S7" itself. On the other hand, if the update data is common data, the update data is shared via the LAN. Send to database DB. In the shared database DB, the updated data is reflected in the storage contents of the original database 10 using the database management system DBMS.
[0035]
As described above, in the shared database system 3, the individual data and the common data are distributed and stored, so that each individual database S1 "to S7" is reflected by transmitting only the common data to the shared database DB. Processing can be performed immediately. Therefore, according to this system, it is not necessary to transfer files from the original database 10 to the purpose-specific databases S1 'to S7' as in the intermediate database system 2, and it is possible to reduce the amount of communication related to data update, In addition, data can be updated in real time.
[0036]
In the process of extracting each of the individual databases S1 ″ to S7 ″, a search is performed based on key information corresponding to the input command. For example, in the salary system S4 '', when an employee code is input as a search key and a command for outputting the current salary amount and affiliation of the employee is given, the determination mechanism of the salary system S4 '' detects the command, Recognize that it is necessary to perform extraction processing from individual data and common data. Then, the current salary amount is acquired by referring to the salary table shown in FIG. 4A using the employee code as key information, and an instruction is sent to the shared database DB to output the affiliation corresponding to the employee code. . When the shared database DB receives the instruction, the database management system DBMS searches the affiliation table shown in FIG. 4B based on the employee code, extracts the affiliation corresponding to the employee code, and sends it to the payroll system S4. Return to ''. Thereafter, the salary system S4 ″ outputs the current salary amount and affiliation as an extraction result. As a result, the user can obtain a necessary extraction result without worrying about which location on the network stores the data to be searched.
[0037]
As described above, according to the database migration method according to the first embodiment, the first database is migrated from the old database system 1 to the intermediate database system 2, and the second database is migrated from the intermediate database system 2 to the shared database system 3. Therefore, the transition can be made smoothly in accordance with the development speed of the communication network and the computer.
That is, in the first stage, the migration can be performed without making significant changes to the purpose-specific databases S1 'to S7' of the old database system 1, so that the number of steps and time required for program development can be reduced, and the original database In 10, the common data can be centrally managed. Further, in the second stage, the speed of the communication network or the computer shifts at a timing when the processing does not hinder even if the two-phase commit control is performed, so that the advantages of the real-time update can be sufficiently exhibited.
[0038]
C. Second embodiment
In the above-described embodiment, the second stage transition is executed when the conditions of the two-phase commit control are satisfied in all the purpose-specific databases. This is because, since the data of each purpose-based database is related to each other, even if only some purpose-specific databases are migrated to individual databases that perform real-time updates, if other This is based on the reason that the update data cannot be viewed in real time in the purpose-specific database, and that common data from other purpose-specific databases cannot be viewed in real time in some individual databases.
[0039]
By the way, since the range of the common data is determined according to the specifications of the purpose-specific databases S1 'to S7', for example, the data of the purpose-specific databases S1 'to S7' has a relationship as shown in FIG. Sometimes. In this case, the physical distribution system S6 'has common data Da with the company home system S4', but there is no common data among the other purpose-specific databases S1 'to S5' and S7 '. Therefore, when the conditions of the two-phase commit control are shifted to real-time updating in the company housing system S4 ′ and the physical distribution system S6 ′, the common data Da updated real-time by the physical distribution system S6 ′ is transferred to the corporate housing system S4 ′. It will be possible to watch in real time.
[0040]
Therefore, the second embodiment provides a migration method in which, after the first stage of the first embodiment, some of the purpose-specific databases are shifted to real-time updating, and then all of the purpose-specific databases are shifted to real-time updating. Things. That is, in the first stage, the old database system 1 is migrated to the first intermediate database system (the intermediate data system 2 of the first embodiment), and in the second stage, the first intermediate database system is migrated. 2 to a second intermediate database system 2 'including a part of real-time updating, and in the third stage, a transition from the second intermediate database system 2' to the shared database system 3. The first stage is the same as that of the first embodiment, and the third stage executes the migration when all the individual databases satisfy the conditions of the two-phase commit control, as in the second stage of the first embodiment. Therefore, the description is omitted here, and the second stage (migration from the first intermediate database system 2 to the second intermediate database system 2 ') will be described.
[0041]
1. Transition conditions
The conditions for executing the second stage are as follows: among the purpose-specific databases S1 ′ to S7 ′ constituting the first intermediate database system 2 (see FIG. 2), the purpose-specific databases S1 ′ to S1 ′ to which the ranges of the common data mutually overlap. With S7 'as a set, migration is performed when the condition of the two-phase commit control is satisfied in units of a set.
For example, in the example shown in FIG. 5, the physical distribution system S6 'and the company housing system S4' are the first set, and the personnel system S1 ', the salary system S2', the pension system S3 ', and the retirement allowance system S5 ', A distribution system S6', and a payroll system S7 'are a second set.
[0042]
Here, the second set of personnel systems S1 'is a database serving as a backbone of the first intermediate database system 2, and has a large amount of common data and a high frequency of accessing the common data from other purpose-specific databases. In the first distribution system S6 ', it is assumed that the amount of common data is small and the processing time associated with the two-phase commit control is short. In this case, when the speed of the communication network or the computer gradually increases, the time comes to satisfy the first set of transition conditions but not satisfy the second set of transition conditions. At that timing, only the first set is shifted to the real-time update, and the second intermediate database system 2 'is constructed.
[0043]
2. Second intermediate database system
Next, the configuration of the second intermediate database system 2 'will be described with reference to FIG. In this example, it is assumed that the distribution system S6 'and the company house system S4' have been shifted to real-time updating.
[0044]
In the second intermediate database system 2 ′ shown in FIG. 6, the physical distribution system S6 ″ and the company home system S4 ″ store individual data by themselves, and the original database 10 stores the physical distribution system S6 ″ and the company home system S4 ′. And common data of other purpose-specific databases S1 'to S3', S5 ', and S7'.
[0045]
In this case, the reflection processing and the extraction processing of the purpose-specific databases S1 'to S3', S5 ', and S7' are performed in the file transfer format described in the first embodiment. On the other hand, in the reflection processing of the distribution system S6 ″ and the company home system S4 ″, if the update data is individual data, the update data is stored in the individual database itself. On the other hand, if the update data is common data, the update data is sent to the shared database DB, and the storage contents of the original database 10 are updated in real time.
[0046]
As described above, in the second embodiment, after the migration from the first intermediate database system 2 to the second intermediate database system 2 ′, the migration to the shared database system 3 is performed. Can be realized.
[0047]
In the above-described second embodiment, the first intermediate database system 2 is migrated to the second intermediate database system 2 ′. However, the old database system is directly migrated to the second intermediate database system 2 ′. Thereafter, the process may be shifted to the shared database system 3.
[0048]
In addition, the individual databases S1 ″ to S7 ″ described above store only individual data, but may store common data required by the individual database together with the individual data. In this case, for example, by storing individual data and common data for those frequently used for search, the frequency of access to the original database 10 can be reduced, so that the shared database system 3 can be smoothly operated. It becomes possible to operate.
[0049]
【The invention's effect】
As described above, according to the invention specifying items of the present invention, since the transition to the shared database system is performed via the database system that is delayedly updated by the file transfer, the transition can be performed easily and smoothly, and It is possible to guarantee the consistency of common data.
[Brief description of the drawings]
FIG. 1 is a conceptual diagram showing an entire configuration of an old database system.
FIG. 2 is a functional block diagram illustrating a functional configuration of a shared database according to the embodiment;
FIG. 3 is a diagram showing an example of a table generated by the personnel system according to the embodiment;
FIG. 4A shows an example of a salary table according to the embodiment, and FIG. 4B shows an example of an affiliation table according to the embodiment.
FIG. 5 is a conceptual diagram showing a relation between data stored in each purpose-specific database according to the embodiment.
FIG. 6 is a block diagram showing a configuration of a second intermediate database system according to the embodiment.
[Explanation of symbols]
1: Old database system (first database system)
2. First intermediate database system
2 '... Second intermediate database system
3. Shared database system
S1 to S7: Database (database device)
S1 'to S7': Database for each purpose (database device for each purpose)
S1 '' to S7 '' ... individual database (individual database device)
DB: Shared database (shared database device)
LAN: Local area network (communication network)

Claims

A first database system that includes a plurality of database devices that handle mutually related common data and that transfers the common data among the plurality of database devices from each other; each individual unit that stores at least individual data independent of other devices; A database migration method for migrating to a shared database system that includes a database device and a shared database device that is connected to each of the individual database devices and stores at least common data related to other devices, and that updates the shared data in real time. hand,
The shared database device and a plurality of purpose-specific database devices that transfer update data to the shared database device when data is updated, wherein the shared database device reflects the transferred update data in its storage content. A second database system for transferring extracted data extracted according to rules defined for each of the purpose-specific database devices to the plurality of purpose-specific database devices, from the first database system to the shared database system; A database migration method provided at a stage.

When migrating from the second database system to the shared database system, the migrating measures are executed after the two-phase commit control can be performed without hindrance in all the purpose-specific database devices. Item 4. The database migration method according to Item 1.

A first database system that includes a plurality of database devices that handle mutually related common data and that transfers the common data among the plurality of database devices from each other; each individual unit that stores at least individual data independent of other devices; A database migration method for migrating to a shared database system that includes a database device and a shared database device that is connected to each of the individual database devices and stores at least common data related to other devices, and that updates the shared data in real time. hand,
From the first database system, the shared database device is provided, and a part of the plurality of database devices, each of which overlaps a range of common data, is changed to the individual database device corresponding to real-time update; A first step of transferring the other database device to a second database system changed to a purpose-specific database device that performs a delayed update by performing file transfer with the shared database device;
And a second step of migrating from the second database system to the shared database system.

A first database system that includes a plurality of database devices that handle mutually related common data and that transfers the common data among the plurality of database devices from each other; each individual unit that stores at least individual data independent of other devices; A database migration method for migrating to a shared database system that includes a database device and a shared database device that is connected to each of the individual database devices and stores at least common data related to other devices, and that updates the shared data in real time. hand,
From the first database system, the shared database device is provided, and the database device is changed to a purpose-specific database device that transfers updated data to the shared database device when data is updated, and the shared database device is transferred. After reflecting the updated data in the storage contents, the extracted data is transferred to the second database system which transfers the extracted data extracted in accordance with the rules defined for each purpose-specific database device to each of the plurality of purpose-specific database devices. A first step;
A third database system in which, from the second database system, a part of the plurality of purpose-specific database devices, each of which has a common data range overlapping each other, is changed to the individual database device corresponding to real-time update; A second step to transition to
And a third step of migrating from the third database system to the shared database system.

5. The database migration according to claim 4, wherein the second step executes a migration measure after the two-phase commit control can be performed without any trouble in the purpose-specific database device to be changed. 6. Method.