JP2012128534A - 情報処理装置、情報処理方法、コンピュータプログラム、記録媒体 - Google Patents

Abstract

【課題】Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおいて、データベースの整合性を失わずに、リカバリを可能とする方法を提供する。
【解決手段】複数の業務を共通の設定テーブルに定義してＷｅｂ−ＥＤＩシステムを構築する情報処理装置であって、ユーザの指示に従って、前記設定テーブルに定義された業務の定義情報を主キーの数と共にバックアップするバックアップ手段と、前記設定テーブルに対して、一意の主キーを付与して業務の定義情報を追加することで定義を行う定義手段と、前記定義手段により定義された設定テーブルに対して、前記バックアップ手段によりバックアップされた定義情報を、前記バックアップされた主キーの数を用いて、主キーが重複しないように追加することでリカバリするリカバリ手段と、を備える。
【選択図】図１

Description

本発明は、情報処理装置及び方法、並びにプログラムに関し、特に、Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおけるバックアップ・リカバリに関する。

近年、企業などにおいては、受発注業務における業務効率化のために、オープンなネットワークであるインターネット技術を利用したＥＤＩであるＷｅｂ−ＥＤＩシステムが導入されている。

例えば、小売側でＷｅｂ−ＥＤＩシステムを導入した場合、小売は、卸・メーカーに対して、Ｗｅｂ−ＥＤＩシステムを使用して発注情報等を公開し、卸・メーカーは、ブラウザを介して、「発注情報照会」、「出荷情報登録」、「検収情報照会」などの複数の業務を使用することで、発注情報の参照や出荷情報を登録することが可能になる。データは迅速に相手に届き、紙のデータを手入力する手間が省けるため集計処理が一瞬で済むといったメリットが、小売、卸・メーカーの両社で発生するため、Ｗｅｂ−ＥＤＩシステムが普及してきている。

また、Ｗｅｂ−ＥＤＩシステムでは、他のＥＤＩ（全銀、ＪＣＡ）と比べて非常に自由度が高い。そのため、上記に上げた「発注情報照会」、「出荷情報登録」、「検収情報照会」以外にも「内示照会」「受注確定処理」「ピッキングリスト発行」など複数の業務に対応することが可能である。これは、業界標準のフォーマットでやり取りする他のＥＤＩ（全銀、ＪＣＡ）と違い、小売と卸・メーカー間でやりとりする情報種・フォーマットを独自に決めているためである。そのため、同じ「発注情報照会」画面でも、Ｗｅｂ−ＥＤＩシステムを導入した小売が異なれば、画面に表示している内容にも違いが発生している。

その一方、Ｗｅｂ−ＥＤＩシステムを導入する企業毎に、業務画面が異なることから、１から作る必要があり、Ｗｅｂ−ＥＤＩシステムを構築する開発者の負担になっていた。また、「発注情報照会」と「出荷情報登録」画面で開発者が異なると、ユーザインタフェースが統一されないという問題があり、Ｗｅｂ−ＥＤＩシステム構築用フレームワークが作成されるようになった。

なお、Ｗｅｂ−ＥＤＩシステム構築用フレームワークとは、「発注情報照会」、「出荷情報登録」、「検収情報照会」等の業務で、どのデータをどのように表示するかをデータベースに定義し、定義した情報を基に動的にデータを表示することができるプログラムファイル（ＪＳＰ，ＣＧＩ等）を出力するためのアプリケーションのことをいう。このＷｅｂ−ＥＤＩシステム構築用フレームワークにより、開発効率が向上し、開発者が複数いた場合でもユーザインタフェースが統一されるようになった。

しかしながら、Ｗｅｂ−ＥＤＩシステム構築用フレームワークについては、フレームワークを使用して開発する開発者にとって使いにくい部分がある。

あるＷｅｂ−ＥＤＩシステム構築用フレームワークでは、複数の業務の情報を１つのテーブルに格納するため、複数の開発者で開発した場合に、データベースの一意制約ためバックアップ・リカバリを行うことができないという制約がある。

ここで、データベースのバックアップ・リカバリについては、特許文献１にデータベースのバックアップおよび復元の方法およびシステムが開示されている。

特開平６−２１４８５３

しかしながら、特許文献１に記載のデータベースのバックアップおよび復元の方法では、データをバックアップした状態をリカバリすることはできるが、バックアップしたデータの値を変更してリカバリすることはできない。

本発明は、上記課題を解決するためになされたものであり、Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおいて、データベースの整合性を失わずに、リカバリを可能とする方法を提供することを目的とする。

本発明は、複数の業務を共通の設定テーブルに定義してＷｅｂ−ＥＤＩシステムを構築する情報処理装置であって、ユーザの指示に従って、前記設定テーブルに定義された業務の定義情報を主キーの数と共にバックアップするバックアップ手段と、前記設定テーブルに対して、一意の主キーを付与して業務の定義情報を追加することで定義を行う定義手段と、前記定義手段により定義された設定テーブルに対して、前記バックアップ手段によりバックアップされた定義情報を、前記バックアップされた主キーの数を用いて、主キーが重複しないように追加することでリカバリするリカバリ手段と、を備えることを特徴とする。

本発明によれば、Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおいて、データベースの整合性を失わずに、リカバリが可能となる。

Ｗｅｂ−ＥＤＩシステムの全体図の概要構成を示す図である。 本発明の実施形態における各種端末のハードウェア構成を示す図である。 Ｗｅｂ−ＥＤＩシステム構築のフローを示す図である。 Ｗｅｂ−ＥＤＩシステムの画面設定のフローを示す図である。 置換設定の画面イメージ図である。 業務設定の画面イメージ図である。 ユーザＤＢのテーブルのサンプル図である。 検索・一覧・詳細共通で使用される最初に表示される画面イメージ図である。 検索・一覧・詳細共通で使用される図８から遷移される画面イメージ図である。 開発ＤＢのテーブルに保存される設定データのサンプル図である。 利用者（卸・メーカー）が使用する画面イメージで図ある。 バックアップ・リカバリ例のフローを示す図である。 開発ＤＢのテーブルに保存されるデータの変化を説明した図である。 開発ＤＢのテーブルに保存されるデータの変化を説明した図である。 本アイデアを用いたリカバリ方法のフローを示す図である。 図１５のフローを実行中のメモリの値を示す図である。 図１５のフローを実行中の取得したデータの例を示す図である。 図１５のフローを実行中の取得したデータの例を示す図である。 図１５のフローを実行中の取得したデータの例を示す図である。 本アイデア実行後の開発ＤＢのテーブルのデータを示す図である。 本アイデア実行後の開発ＤＢのテーブルのデータを示す図である。 本アイデアを適用した場合の画面イメージ図である。 開発ＤＢのバックアップ管理テーブルのデータを示す図である。

以下、図面を参照して、本発明の実施形態を詳細に説明する。

図１は、本発明の実施形態におけるＷｅｂ−ＥＤＩシステムの全体図の概要構成を示す図である。

なお、図１のＷｅｂ−ＥＤＩシステム（情報処理システム）の構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。

まず、前提としてＷｅｂ−ＥＤＩシステムは、Ｗｅｂ−ＥＤＩシステム構築企業において、開発担当者が、開発サーバ１０１において、Ｗｅｂ−ＥＤＩ構築フレームワークにより開発される。そして、作成されたファイルをＷｅｂ−ＥＤＩシステムを導入する企業のＷＥＢサーバ１０５に配置することにより構築される。

次に、構築されたＷｅｂ−ＥＤＩシステムの利用形態を説明する。

卸・メーカーの操作者が操作するＰＣ（１０３、１０４）は、インターネット回線１０９を使用して、Ｗｅｂ−ＥＤＩシステムを導入した小売のＷＥＢサーバ１０５の動的ファイル（例として「発注検索画面」）にアクセスする。

ＷＥＢサーバ１０５は、ファイアウォール１０６を介して、データベースサーバ１０７上のユーザＤＢ１０８からデータを検索し、「発注検索画面」に、検索結果を「発注一覧画面」にセットして、卸・メーカーのＰＣに表示させる。ここで、「発注検索画面」や、「発注一覧画面」等の画面は、開発者がＷｅｂ−ＥＤＩ構築フレームワークを使用して作成されたものである。

なお、本発明の実施形態は、Ｗｅｂ−ＥＤＩ構築フレームワークに関しての内容であり、小売企業内のＷＥＢサーバ、データベースサーバについては関係がないため説明を省略する。

以下では、「開発者」が使用する開発サーバ１０１における「Ｗｅｂ−ＥＤＩ構築フレームワーク」の画面と、「Ｗｅｂ−ＥＤＩ構築フレームワーク」に含まれる開発ＤＢ１０２のテーブルの内容について主に説明する。メーカー・卸が使用する画面と、ユーザＤＢのテーブルの内容を説明する場合は、別途その旨を記載する。

次に、図１における開発サーバのハードウェア構成について、図２を用いて説明する。

図２は、本発明の実施形態における開発サーバのハードウェア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラム２１２が用いる定義ファイル２１３及び各種情報テーブル２１４は外部メモリ２１１に格納されており、これらについての詳細な説明は後述する。

次に、開発サーバにおけるＷｅｂ−ＥＤＩ構築システムの基本的な処理フローについて、図３を用いて説明する。

図３は、開発サーバにおけるＷｅｂ−ＥＤＩ構築フレームワークの基本的な処理フローを示す図である。

Ｓ３０１は、開発者がブラウザを使って画面から開発サーバにおけるに対して設定を行うことを表している。Ｓ３０１の詳細フローについては、図４にて示す。

Ｓ３０２は、Ｓ３０１で行われた設定内容が、Ｗｅｂ−ＥＤＩ構築フレームワークの開発ＤＢのテーブルに格納される事を表している。開発ＤＢのテーブルの説明は別途図１０で行う。

Ｓ３０３は、開発サーバにおける設定が全て終わったかの判定処理である。設定が終わっていない場合は、Ｓ３０１を繰り返す。設定が終わった場合は、Ｓ３０４に進む。

Ｓ３０４は、開発サーバにおいて構築機能を実行することにより、Ｓ３０２のデータベースの内容から動的なファイルを作成することを表している。

次に、Ｓ３０１の詳細な処理フローについて、図４を用いて説明する。

図４は、Ｓ３０１で説明した画面から設定する内容の詳細なフローである。

Ｓ４０１では、開発サーバは、置換設定か、業務設定かを判定している。置換設定を行う場合はＳ４０２に進み、業務設定を行う場合はＳ４０３に進む。この判定は、開発者の設定指示により判定を行う。

Ｓ４０２では、開発サーバは、置換設定を行う。置換設定とはコードを別の文字に置き換える設定のことである。

例として、テーブルに「確認フラグ」という項目があり、０と１の２種類の値が入っているものとする。その場合に、画面上に「０」「１」を表示しても理解しにくい。そこで置換設定で「０」の場合は「未確認」、「１」の場合は「確認済」と設定することにより、画面上に「未確認」「確認済」と表示することができる。

置換設定の画面イメージについては図５で説明する。

図５は、置換設定の画面サンプルである。

５０１と５０２は、置換設定の画面イメージである。新規追加や、登録済みの置換設定を削除することができる。登録済みの置換設定が無い場合は５０１のように表示され、登録済みの置換設定がある場合は５０２のように表示される。

追加ボタンを押した場合は、５０３の画面が表示され、修正ボタンを押した場合は５０４の画面が表示される。５０３と５０４は、置換設定の内容を登録する画面である。置換設定の名前を置換名に入力する。また、置換前の値を「キー」に、置換後の値を「値」に入力する。

次に、Ｓ４０３では、開発サーバは、業務設定を行う。業務の例として、「発注照会」「出荷登録」「検収照会」などが該当する。

Ｓ４０４では、開発サーバは、Ｓ４０３で設定した業務のデータが格納されているテーブル、またはビューを選択する。ここで指定するテーブルまたはビューは、ユーザＤＢに存在している必要がある。

ここで選択するテーブルのサンプルを図７で説明する。

図７は、ユーザＤＢのテーブルのサンプルである。

ここでは、ユーザＤＢのテーブルのサンプルとして、ＨＡＣＨＵテーブルを示している。なお、後述する図１１の画面イメージは、図７のデータを用いた場合のサンプル図である。

次に、Ｓ４０５では、開発サーバは、抽出条件の設定を行う。

Ｓ４０４で選択したテーブルには、複数の仕入先のデータが格納されている。

図１で示したが、Ｗｅｂ−ＥＤＩシステムには仕入先として、複数の卸やメーカーが自社宛の発注が無いか確認するため、Ｗｅｂ−ＥＤＩシステムにログインする。その際に他社の発注情報が表示され、単価が自社と違うといったことが判明すると非常に問題である。そのため、ログインした企業が、自社宛の情報以外は見えないようにするため、ログインした企業の情報と、Ｓ４０３で指定したテーブルのマッピングの指定もここで行う。

例として、発注ビューの「仕入先コード」とログイン情報をマッピングすると、発注ビューの仕入先コードがログイン情報と同じデータのみが表示され、別の仕入先コードのデータは表示されなくなる。

Ｓ４０３、Ｓ４０４、Ｓ４０５の画面イメージを図６で説明する。

図６は、業務設定の画面サンプルである。

６０１と６０２は、業務設定を一覧表示している画面イメージである。業務が設定されていない場合は６０１のように表示され、業務が設定されている場合は６０２のように表示される。業務設定一覧画面から新規に業務を追加したり、登録済みの業務を削除したりすることができる。

追加ボタンを押すことにより６０３の画面が、修正ボタンを押すことにより６０４の画面が表示される。６０３と６０４は、業務設定画面である。この画面でＳ４０３、Ｓ４０４、Ｓ４０５の設定を行う。「検索」「一覧」「詳細」ボタンを押すと、図８の画面が表示され、検索画面、一覧画面、詳細画面の画面レイアウトを設定することが出来る。業務名の入力と、テーブル名の選択が行われていない場合は、「検索」「一覧」「詳細」ボタンを押すとエラーが発生する。

ここで、検索画面設定、一覧画面設定、詳細画面設定の画面イメージを、図８と図９を用いて説明する。検索画面設定、一覧画面設定、詳細画面設定の画面イメージは共通のため、ここでは、一覧画面設定のみ説明する。

図８は、６０４の業務設定画面で「一覧」ボタンを押した場合に表示される画面イメージである。画面名には「業務名＋（検索 ｏｒ 一覧 ｏｒ 詳細）」が表示され、業務設定画面のテーブル名に選択したテーブルのすべての項目が表示される。

８０１は、設定を行っていない場合の画面イメージであり、８０２のように画面に表示させたい項目にチェックを付け、設定ボタンを押すと、図９の画面が表示される。

９０１は、設定を行っていない場合の画面イメージであり、前の画面でチェックを付けた項目だけが表示された状態となる。９０２は、設定完了後の画面イメージである。

一覧画面なので発注番号で集約する設定を行っており、同じ発注番号が複数存在しても１行のみ表示されることになる。

実際の画面イメージについては図１１を用いて説明する。

図１１は、Ｗｅｂ−ＥＤＩシステムの画面サンプルである。

１１０１は、ログイン画面である。Ｗｅｂ−ＥＤＩシステムを利用するためには、ユーザ名とパスワードを入力してログインする必要がある。ログイン画面についてはＷｅｂ−ＥＤＩ構築フレームワークに含まれた機能であり、開発者が設定する必要はない。

１１０２は、ログイン後に表示されるメインメニューである。メインメニューはＳ４０３で設定された業務が表示される。この例ではＳ４０３で３つの業務が設定されていることになる。

１１０３は、１１０２で「発注照会」を選択した場合に表示される画面である。１１０３の画面は、Ｓ４０６で設定された内容から作られたものである。

１１０４は、１１０３で検索を実行した後に表示される画面である。１１０４の画面は、Ｓ４０７で設定された内容から作られたものである。１１０４では発注番号単位に集約し、「発注番号」、「発注日」、「納品予定日」の他に、発注内容を以前に確認しているかを表す「発注確認」を表示している。

１１０５は、発注番号がＡ１０の詳細ボタンを選択した場合に表示される画面である。１１０５の画面は、Ｓ４０８で設定した内容から作られたものである。１１０５では１１０４で表示していた情報の他に、「納品場所」を画面上部に表示している。これは１つの発注番号には複数の明細行が含まれるが、「発注日」「納品予定日」「納品場所」は全部同じ値になるためである。明細行には「行」「商品名」「商品コード」「単価」「数量」「金額」「合計金額」を表示している。基本的には、Ｓ４０４で選択したテーブルの項目を表示するが、テーブルには無い項目であっても「金額」は単価×数量の値を、「合計金額」（金額の一番下の行）は金額を足した値というように計算して表示することが可能である。

また、設定を行った後の開発ＤＢのテーブルの内容を図１０に示す。

次に、Ｓ３０２で登録されたデータベースの内容について、図１０を用いて説明する。

図１０は、Ｓ３０２で登録されるデータベースのテーブルを簡易化したサンプルである。

１００１は、画面設定の基本部分が保存されたテーブルになる。「主キー」には連番が自動的に付与される。画面設定テーブルにはＳ４０６、Ｓ４０７、Ｓ４０８で設定された内容が保存される。

１００２は、置換設定が保存されたテーブルになる。置換テーブルにはＳ４０２で設定された内容が保存される。

１００３は、画面設定テーブルと置換テーブルを関連付けた情報が保存されたテーブルになる。

次に、これらが、どのように関連付けているかを説明する。

例えば、画面設定テーブル１００１の主キーが「１６」の行の、置換の値は「１」になっている。これは、置換設定がされていることを表し、画面−置換関連テーブル１００３の画面−置換関連テーブルの画面ＩＤが「１６」の行を検索する。

そして、画面−置換関連テーブル１００３から、画面ＩＤが「１６」の行の置換ＩＤを取得する。すると、置換ＩＤは「１」であることが判明するため、その後、置換テーブル１００２の置換ＩＤが「１」の行を取得する。ここでは、置換テーブル１００２の主キーが「１」と「２」の行が該当する。

画面設定テーブル１００１の主キーが「１６」の行の項目名の値は「確認フラグ」であるため、確認フラグの値と置換テーブルの「キー」列の値が同じ場合は、置換テーブルの「値」列の内容で置き換えることとなる。

次に、Ｓ４０６では、開発サーバは、Ｓ４０３で設定した業務の検索画面を設定する。

Ｓ４０４で設定したテーブルのデータを毎回全部表示すると、大量のデータが表示され現実的ではない。そのため、「発注日」や「発注書が未印刷」などの条件で絞り込む必要があり、絞り込む条件を設定する。なお、業務によっては検索画面が不要なことがあり、検索画面が不要な場合は検索画面設定を行わないことも可能である。検索画面設定を行わなかった場合は、検索画面を表示せず、いきなり一覧画面や詳細画面を表示することになる。

Ｓ４０７では、開発サーバは、Ｓ４０６で設定した検索画面で検索した後に表示される画面の設定を行う。

Ｓ４０４で選択したテーブルのどの項目をどう表示するか、ソート順の設定、グループ化の設定を行う。グループ化の設定とは、１つの発注番号には複数の明細行が含まれている場合があり、その場合に発注番号単位で表示したいという場合に使用する（データベースのＳＱＬ言語の「ＧＲＯＵＰ ＢＹ」に相当する。）。なお、業務によっては、一覧画面が不要な場合があり、一覧画面が不要な場合は一覧画面設定を行わないことも可能である。一覧画面設定を行わなかった場合は、検索画面で検索を実行した後は、詳細画面を表示することになる。

Ｓ４０８では、開発サーバは、Ｓ４０７で設定した一覧画面から遷移する、画面の設定を行う。

一覧画面では表示していなかった詳細な内容の表示や、一覧画面では発注番号単位で集約して表示していた場合に、明細行を表示する場合に設定する。なお、業務によっては詳細画面が不要なことがあり、詳細画面が不要な場合は詳細画面設定を行わないことも可能である。

以上、開発サーバにおけるＷｅｂ−ＥＤＩ構築システムの基本的な処理の流れを説明した。

ここで、従来の問題点として、図１０のテーブル構造において以下の２つの問題点がある。
（１）画面設定テーブル１００１の主キーの値は意味の無い連番である。
（２）画面−置換関連テーブル１００３の画面ＩＤに８０１の主キーの値を使用している。

上記（１）と（２）の問題により、業務単位でのバックアップ・リカバリが行えないことを、図１２を使って説明する。

Ｓ１２０１によって発注業務が作成されることにより画面設定テーブル１００１の状態になる。

Ｓ１２０２によって画面設定テーブル１００１の内容をバックアップする。

Ｓ１２０３によって発注業務が削除されデータベースの内容は図１３の状態になる。画面設定テーブル１００１と画面−置換関連テーブル１００３の内容がクリアされ、置換テーブル１００２だけ残った状態となる。

Ｓ１２０４によって画面設定テーブル１００１に新規に行が追加されることとなるが、この場合における主キーの値が問題となる。

本Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおいて、主キーの値は自動的に連続した番号を振るが、その際に現在の主キーの最大値に１を足した値を使用することにより、連続した番号としている。従って、Ｓ１２０３で発注業務を削除していなければ１００１の最大値である４８に１を足した４９を使用するが、Ｓ１２０３によりデータが無くなっているため、１３０１の最大値は存在しない。そのため１を使用することになり、データベースの内容は図１４の状態となる。つまり、１２０３と１２０４により、データベースの内容が更新（変更）される。

そのため、Ｓ１２０５の状態で、Ｓ１２０２で取得したバックアップでリカバリを実行すると、以下のどちらかになってしまうという問題がある。
（１）主キーが重複しているため、リカバリ不可
（２）Ｓ１２０４で作成した内容が消え、Ｓ１２０２の時点に戻ってしまう。

本来であれば、Ｓ１２０４で作成した出荷業務の設定は残った状態で、更にＳ１２０３で削除した発注業務の設定が元通りに復活するのが望ましい。

そこで、本発明の実施の形態においては、次の方法により問題を解決している。
（１）主キーの値が重複してしまうので、重複しないように振りなおす。
（２）他の関連するテーブルについても整合性を失わないよう修正する。

図１５を用いてＳ１２０５の具体的方法を説明する。

図１５は、Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおけるリカバリ方法のフローを示す図である。

ここでは、データベースが図１４の状態の場合に図１２で取得したバックアップをリカバリする例について説明する。

Ｓ１５０１では、開発サーバは、各テーブルの最大の主キーの値を格納する。格納した結果は図１６のようになる。

Ｓ１５０２では、開発サーバは、バックアップファイルから１行読み込む。読み込んだ内容は図１７のようになる。

Ｓ１５０３では、開発サーバは、読み込んだ内容と同じ内容がテーブル上に存在しないかチェックする。図１７のデータは画面設定テーブルの内容で、主キーが１なので、１４０１の主キーが１の行と比較する。業種の値がバックアップファイルは「発注」で、１４０１は「出荷」であるので、存在しないため、Ｓ１５０４に進む。

Ｓ１５０４では、開発サーバは、外部キー（ＦＫキー）が含まれているかを確認する。この例では、画面設定テーブルには外部キーが含まれていないため、Ｓ１５０６に進む。

Ｓ１５０６では、開発サーバは、バックアップファイルの主キーの値である「１」に、図１８にある該当テーブルの値である「１５」を足した値の「１６」に変更し、Ｓ１５０７に進む。

Ｓ１５０７では、開発サーバは、主キーの値を書き換えたデータをテーブルに書き込み、Ｓ１５０８に進む。

Ｓ１５０８では、開発サーバは、バックアップのファイルが最後か判定し、最後の場合は処理を終了する。ここではファイルの最後ではないので、Ｓ１５０２に戻る。

次に、Ｓ１５０２で読み込んだデータが図１８だった場合について説明する。Ｓ１５０３では、開発サーバは、図１８のデータと完全に同じデータが１４０２に存在するためＳ１５０２に進む。

また、Ｓ１５０２で読み込んだデータが図１９だった場合について説明する。Ｓ１５０３では、開発サーバは、画面ＩＤの値が違うため、Ｓ１５０４に進む。

Ｓ１５０４では、開発サーバは、外部キーが存在するか確認するが、画面ＩＤが外部キーとして画面設定テーブルの主キーの値が格納されているため、Ｓ１５０５に進む。

Ｓ１５０５では、開発サーバは、バックアップファイルの外部キーの値を修正する。参照しているテーブルである「画面設定テーブル」の最大値を足すため、図１６の値を使用する。従って「６」に「１５」を足した値の「２１」に変更し、Ｓ１５０７に進む。

以降の処理については既に説明済みのため省略する。

次に、全てリカバリが終わった後のデータベースの状態について、図２０と図２１を用いて説明する。

図２０の画面設定テーブル２００１では、主キーの値が１〜１５まではリカバリ実行前の図１４と同じ内容である。主キーの値が１６〜６３までがリカバリ処理により追加された値である。

図２１の置換テーブル２１０１は、そのままの値である。

図２１の画面−置換関連テーブル２１０２では、主キーの値が２と３がリカバリ処理により追加された値である。

これにより業務単位でのバックアップ・リカバリが可能となる。

つまり、従来のＷｅｂＥＤＩ構築フレームワークにおいては、バックアップ・リカバリ機能することができなかったが、これは、「（１）主キーが重複しているため、リカバリ不可（２）Ｓ１２０４で作成した内容が消え、Ｓ１２０２の時点に戻ってしまう。」が原因であったためである。

そこで、本発明により「（１）主キーの値が重複してしまうので、重複しないように振りなおす。（２）他の関連するテーブルについても整合性を失わないよう修正する。」ことで
バックアップ・リカバリ機能を追加することが可能となった。

次に、バックアップ・リカバリ機能を追加したイメージについて、図２２を用いて説明する。

図２２は、従来の業務設定画面に対して、本発明の実施形態を追加した後に、どうなるかを示したサンプル画面である。なお、ここで示したサンプル画面は一例であることは言うまでもない。

２２０１は、Ｓ４０２の業務設定画面のサンプルである。

２２０２は、本発明の実施形態を追加した後の業務設定画面のサンプルである。

バックアップ・リカバリ機能として、「エクスポート」と「インポート」ボタンが追加され、エクスポートする業務を選択するための「保存」チェックボックスを追加している。

バックアップする場合は、開発者は、バックアップしたい業務の「保存」チェックボックスにチェックを付け、「エクスポート」ボタンを押下する。「エクスポート」ボタンが押下された場合は、２２０３に遷移する。

また、開発者は、リカバリしたい場合は、「インポート」ボタンを押下する。「インポート」ボタンが押下された場合、２２０４に遷移する。

２２０３は、エクスポート画面のサンプルを示している。２２０２で「保存」にチェックを付けた業務が「保存業務」に表示され、「日付」が表示される。「日付」は本日の日付が自動的にセットされる。「コメント」欄は自由に入力可能である。「コメント」欄を入力し、「保存」ボタンを押すことにより、「保存業務」に表示されている業務の設定内容が外部ファイルに出力され、ＷｅｂＥＤＩ構築フレームワークが管理するバックアップ管理テーブルに管理情報が保存される。バックアップ管理テーブルについては図２３に示す。

図２３は、バックアップ管理テーブルのサンプルである。

バックアップ管理テーブルには２２０３の情報と、出力したバックアップファイルのファイルパス名が格納される。これにより２２０４のインポート画面では、自動的に適切なファイルからリカバリすることが可能となる。

２２０４は、インポート画面のサンプルである。バックアップ管理テーブルの情報を表示する。リカバリしたい業務を選択し、「復元」ボタン押すことにより図１５の処理が動作し、リカバリされる。

上述した通り、本発明によれば、Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおいて、データベースの整合性を失わずに、リカバリが可能となる。

これは、Ｗｅｂ−ＥＤＩシステム構築用フレームワークにおける一意制約の値（プライマリキーの値）を変更することで実現可能としたものである。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

また、本発明の目的は、以下のようにすることによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム或いは装置に供給する。そして、そのシステム或いは装置の中央演算処理手段（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行する。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコードを記録した記憶媒体は本発明を構成することになる。

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

更に、記憶媒体から読み出されたプログラムコードが、前記システム或いは装置に挿入された機能拡張カードや、接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれる。

本発明を前記記憶媒体に適用する場合、その記憶媒体（コンピュータ読み取り可能な記憶媒体）には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

１０１ 開発サーバ
１０２ 開発ＤＢ
１０３ メーカー
１０４ 卸
１０５ ＷＥＢサーバ
１０６ ファイアウォール
１０７ データベースサーバ
１０８ ユーザＤＢ
１０９ インターネット

Claims (5)

1. 複数の業務を共通の設定テーブルに定義してＷｅｂ−ＥＤＩシステムを構築する情報処理装置であって、
   ユーザの指示に従って、前記設定テーブルに定義された業務の定義情報を主キーの数と共にバックアップするバックアップ手段と、
   前記設定テーブルに対して、一意の主キーを付与して業務の定義情報を追加することで定義を行う定義手段と、
   前記定義手段により定義された設定テーブルに対して、前記バックアップ手段によりバックアップされた定義情報を、前記バックアップされた主キーの数を用いて、主キーが重複しないように追加することでリカバリするリカバリ手段と、
   を備えることを特徴とする情報処理装置。
2. 前記設定テーブルには、外部キーを定義する設定テーブルと外部キーを定義しない設定テーブルとが含まれ、
   前記リカバリ手段は、前記設定テーブルに外部キーの定義がされている場合、前記バックアップされた主キーの数を用いて、外部キーの値を変更してリカバリすることを特徴とする請求項１に記載の情報処理装置。
3. 複数の業務を共通の設定テーブルに定義してＷｅｂ−ＥＤＩシステムを構築する情報処理方法であって、
   ユーザの指示に従って、前記設定テーブルに定義された業務の定義情報を主キーの数と共にバックアップするバックアップステップと、
   前記設定テーブルに対して、一意の主キーを付与して業務の定義情報を追加することで定義を行う定義ステップと、
   前記定義ステップにより定義された設定テーブルに対して、前記バックアップステップによりバックアップされた定義情報を、前記バックアップされた主キーの数を用いて、主キーが重複しないように追加することでリカバリするリカバリステップと、
   を備えることを特徴とする情報処理方法。
4. 複数の業務を共通の設定テーブルに定義してＷｅｂ−ＥＤＩシステムを構築する情報処理装置において実行可能なプログラムであって、
   ユーザの指示に従って、前記設定テーブルに定義された業務の定義情報を主キーの数と共にバックアップするバックアップ手段、
   前記設定テーブルに対して、一意の主キーを付与して業務の定義情報を追加することで定義を行う定義手段、
   前記定義手段により定義された設定テーブルに対して、前記バックアップ手段によりバックアップされた定義情報を、前記バックアップされた主キーの数を用いて、主キーが重複しないように追加することでリカバリするリカバリ手段、
   を備えることを特徴とするプログラム。
5. 請求項４に記載のプログラムをコンピュータ読み取り可能に記憶した記録媒体。

Images