(57)【要約】【課題】なるべくリクエストにエラーが生じないようにシノニムの対象の切り替えを行えるようにする。【解決手段】第一種と第二種のシノニムが同一のシノニム名である場合に該シノニム名を指定したリクエストを受け付けたならば第二種のシノニムでアクセスする仕様になっているデータベースシステムに対し、第一のスキーマオブジェクトを対象とした第一種のシノニムが存在し、該第一種のシノニムのシノニム名についての参照先及び更新先を第二のスキーマオブジェクトに切り替える場合に、該第一種のシノニムのシノニム名について参照は許可するが更新は抑止した更新抑止状態にした上で、第二のスキーマオブジェクトを対象とした、第一種のシノニムと同一のシノニム名の第二種のシノニムを作成し、その後に、更新抑止状態を解除する。【選択図】図４
2008084255.tif 000002
【特許請求の範囲】
【請求項１】
第一種と第二種のシノニムが同一のシノニム名である場合に該シノニム名を指定したリクエストを受け付けたならば該第二種のシノニムでアクセスする仕様になっているデータベースシステムのアクセス制御方式であり、
第一のスキーマオブジェクトを対象とした第一種のシノニムが存在し、該第一種のシノニムのシノニム名についてのアクセス先を第二のスキーマオブジェクトに切り替える場合に、該第一種のシノニムのシノニム名について参照は許可するが更新は抑止する更新抑止状態にする更新抑止手段と、
前記更新抑止状態になった後に、前記第二のスキーマオブジェクトを対象とした、前記第一種のシノニムと同一のシノニム名の第二種のシノニムを作成する第二種作成手段と、
該第二種のシノニムを作成した後に、前記更新抑止状態を解除する更新抑止解除手段と
を備えることを特徴とするアクセス制御方式。
【請求項２】
前記同一のシノニム名について参照も更新も許可した状態で、前記第一のスキーマオブジェクトを対象とした前記第一種のシノニムを削除する第一種削除手段と、
前記第二のスキーマオブジェクトを対象とした、前記第二種のシノニムと同一のシノニム名の前記第一種のシノニムを新たに作成する第一種作成手段と、
該第二種のシノニムを削除する第二種削除手段と
を更に備える請求項１記載のアクセス制御装置。
【請求項３】
前記第二のスキーマオブジェクトを対象とした第一種のシノニムが存在し、前記同一のシノニム名についてのアクセス先を第三のスキーマオブジェクトに切り替える場合に、
前記更新抑止手段が、前記同一のシノニム名について前記更新抑止状態にし、
前記第二種作成手段が、前記第三のスキーマオブジェクトを対象とした、前記同一のシノニム名の前記第二種のシノニムを作成し、
前記更新抑止解除手段が、前記更新抑止状態を解除する、
ことを特徴とする請求項２記載のアクセス制御方式。
【請求項４】
前記スキーマオブジェクトは、テーブルであり、
前記更新抑止状態になった後で、切り替え元のテーブルから、全件分のデータをアンロードする手段と、
該全件分のデータの一部又は全部を更新した全件分のデータをバッチで作成する手段と、
前記更新した全件分のデータを、前記切り替え先のテーブルにロードする手段と
を更に備え、前記第二種作成手段が、該ロードの後に、前記切り替え先のテーブルを対象とした前記第二種のシノニムを作成する、
請求項１又は３記載のアクセス制御方式。
【請求項５】
現在どのスキーマオブジェクトが前記第一種のシノニムの対象になっている場合にどのスキーマオブジェクトを対象とした前記第二種のシノニムを作成するかを定義した情報が予め設定されており、
前記第二種のシノニムを作成する場合に、前記第一種のシノニムの対象であるスキーマオブジェクトを表す情報を取得する手段、
を更に備え、前記第二種作成手段が、該取得した情報と前記定義した情報とから、前記第二種のシノニムの対象とするスキーマオブジェクトを特定し、該特定したスキーマオブジェクトを対象とした前記第二種のシノニムを作成する、
請求項１記載のアクセス制御方式。
【請求項６】
前記第三のスキーマオブジェクトは前記第一のスキーマオブジェクトであり、
前記定義した情報は、現在第一のスキーマオブジェクトが前記第一種のシノニムの対象になっている場合に第二のスキーマオブジェクトを対象とした前記第二種のシノニムを作成し、現在第二のスキーマオブジェクトが前記第一種のシノニムの対象になっている場合に前記第一のスキーマオブジェクトを対象とした前記第二種のシノニムを作成することを定義した情報である、
請求項５記載のアクセス制御方式。
【請求項７】
第一種と第二種のシノニムが同一のシノニム名である場合に該シノニム名を指定したリクエストを受け付けたならば該第二種のシノニムでアクセスする仕様になっているデータベースシステムのアクセス制御方法であり、
第一のスキーマオブジェクトを対象とした第一種のシノニムが存在し、該第一種のシノニムのシノニム名についてのアクセス先を第二のスキーマオブジェクトに切り替える場合に、該第一種のシノニムのシノニム名について参照は許可するが更新は抑止する更新抑止状態にした上で、前記第二のスキーマオブジェクトを対象とした、前記第一種のシノニムと同一のシノニム名の第二種のシノニムを作成し、その後に、前記更新抑止状態を解除する、
ことを特徴とするアクセス制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シノニムを使用するデータベースシステムのアクセス制御に関する。
【背景技術】
【０００２】
「シノニム」と言う用語が一般に知られている。シノニムとは、テーブル等のスキーマオブジェクトに付ける別名のことであり、データベースオブジェクトの一つである。シノニムには、実際のオブジェクト名の代わりに簡略化した名前でリクエスト（例えばＳＱＬ（Structured Query Language））を作成できるというメリットがある。
【０００３】
【非特許文献１】http://amd.town-web.net/~ky1999/ORA/PDF/BZSQL16.PDF
【発明の開示】
【発明が解決しようとする課題】
【０００４】
例えば、２４時間オンラインでリクエストを受け付け処理することができるコンピュータシステム（以下、２４時間オンラインシステム）のニーズがある。このようなニーズは、例えば、電子マネーのチャージや出金等を管理する電子マネーシステムにある。
【０００５】
２４時間オンラインシステムの種類によっては（例えば電子マネーシステムでは）、短期間で多くのリクエストが発生することがあり、また、リクエストに従う参照先（データの読出し元）及び更新先（データの書込み先）となるテーブルについて、膨大な件数（例えば１日に数百万件〜数千万件）のデータ更新を行い、該更新後のテーブルを、参照先及び更新先にする必要が生じることがある。
【０００６】
通常、同一のシノニム名を有するシノニムと全く同じシノニムを並存させることはできない。
【０００７】
そこで、リクエストをシノニム名で受け付けるようになっている場合に、上記のテーブル更新に対応する方法として、例えば、リクエストを受け付けつつ、前述した膨大の件数のデータを逐次に更新していく方法が考えられる。しかし、この方法は、テーブルの更新に非常に長い時間を要してしまう。
【０００８】
別法として、更新後のテーブルを準備しておき、シノニムの対象を、更新前のテーブルから更新後のテーブルに切り換える方法が考えられる。しかし、同一のシノニムは並存することができないため、この別法では、更新前のテーブルを対象とするシノニムを一旦削除し、更新後のテーブルを対象としたシノニムを新たに作成する必要がある。そうすると、シノニムが存在しない期間ができてしまい、その結果、その期間中に受けたリクエストはエラーになってしまうと考えられる。
【０００９】
従って、本発明の目的は、なるべくリクエストにエラーが生じないようにシノニムの対象の切り替えを行えるようにすることにある。
【課題を解決するための手段】
【００１０】
第一種と第二種のシノニムが同一のシノニム名である場合に該シノニム名を指定したリクエストを受け付けたならば該第二種のシノニムでアクセスする仕様に着目し、該仕様のデータベースシステム（例えばデータベース管理システム（ＤＢＭＳ））のアクセス制御方式を構築する。
【００１１】
そのアクセス制御方式は、更新抑止手段、第二種作成手段、及び更新抑止解除手段を備える。更新抑止手段は、第一のスキーマオブジェクトを対象とした第一種のシノニムが存在し、該第一種のシノニムのシノニム名についてのアクセス先（参照先及び更新先）を第二のスキーマオブジェクトに切り替える場合に、該第一種のシノニムのシノニム名について参照は許可するが更新は抑止する更新抑止状態にする。第二種作成手段は、該更新抑止状態になった後に、第二のスキーマオブジェクトを対象とした、第一種のシノニムと同一のシノニム名の第二種のシノニムを作成する。更新抑止解除手段は、該第二種のシノニムが作成された後に、更新抑止状態を解除する。
【００１２】
このアクセス制御方式によれば、参照が常に許可されており、且つ、シノニムが常時存在するので、シノニム名を指定した参照リクエストを常時受け付けることを可能にしたまま、該シノニム名を指定した参照リクエストに従う参照先を、第一のスキーマオブジェクトから第二のスキーマオブジェクトに切り換えることができる。
【００１３】
前述した各手段は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、一部をコンピュータプログラムで実行し残りをハードウェアで実行する）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照し、本発明の一実施形態に係るアクセス制御方式が適用されたコンピュータシステムの一例を説明する。
【００１５】
図１（Ａ）は、本発明の一実施形態に係るコンピュータシステムの構成例を示す。以下の説明では、データベースを「ＤＢ」と略記することがある。
【００１６】
このコンピュータシステムは、例えば、前述した２４時間オンラインシステムの一種であり、具体的には、例えば、ＩＣカードや携帯電話機等の電子マネー媒体にチャージされたり出金されたりした電子マネーの金額などを管理する電子マネーシステムである。このコンピュータシステムの構成要素は、ＰＬ（プレゼンテーションロジック）１０１と、ＢＬ（ビジネスロジック）１０３と、ＤＢ（データベース）１０５とに大別することができる。
【００１７】
ＰＬ１０１は、複数種類のチャネルにそれぞれ対応した複数のサーバ（以下、ＰＬサーバ）で構成することができる。各ＰＬサーバは、自分に対応したチャネルを介して、電子マネーに関するデータを情報処理端末（例えば、ＰＯＳレジスタ、銀行ＡＴＭ、携帯電話機など）から受信し、該受信したデータに応じて、ＢＬにデータを送信する。
【００１８】
ＢＬ１０３は、一又は複数のサーバで構成することができる。ＢＬ１０３は、ＰＬ１０１に対する見せ方の制御や、各ユーザの電子マネーの管理などを行うことができる。ＢＬ１０３は、ＤＢ１０５に、アクセスリクエスト（参照リクエストや更新リクエスト）を送信し、それにより、ＤＢ１０５からデータを読み出したり、データをＤＢ１０５に書込んだりすることができる。
【００１９】
ＤＢ１０５は、ＢＬ１０３からアクセスリクエストを受け付けるオンライン用ＤＢサーバ１１１と、所定のバッチ処理を実行するバッチ用ＤＢサーバ１１３と、それらが共用するストレージ装置（以下、共用ストレージ）１１５とを有する。共用ストレージ１１５は、両ＤＢサーバ１１１、１１３にとっての外部のストレージ装置であり、例えば、複数の記憶装置がＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）構成とされた大規模なストレージシステムとすることができる。
【００２０】
図１（Ｂ）は、オンライン用ＤＢサーバ１１１の構成例を示す。
【００２１】
ＣＰＵ１２１と記憶資源（例えばメモリやハードディスク）１２３とがある。記憶資源１２３には、ＣＰＵ１２１に読み込まれて実行されるコンピュータプログラムが記憶される。そのコンピュータプログラムとしては、ＤＢ（このＤＢは、ＤＢ１０５とは異なる）を操作するシノニム切替ＤＢＭＳ４０３と、ＢＬ１０３からアクセスリクエストを受け付け該アクセスリクエストに応じてシノニム切替ＤＢＭＳ４０３にリクエストを発行するアクセス制御プログラム４０１とがある。アクセス制御プログラム４０１は、シノニム切替ＤＢＭＳ４０３の外に存在しても良いし、シノニム切替ＤＢＭＳ４０３にプラグインされても良い。シノニム切替ＤＢＭＳ４０３の操作対象であるＤＢは、記憶資源１２３と共用ストレージ１１５の両方に格納することができる。
【００２２】
シノニム切替ＤＢＭＳ４０３には、シノニムでスキーマオブジェクトにアクセスする機能がサポートされているＤＢＭＳである。そのため、オンライン用ＤＢサーバ１１１は、シノニム名を指定したアクセスリクエストをＢＬ１０３から受け付けることができる。
【００２３】
以下、本実施形態で行われる処理の流れの概要を説明する。その際、シノニムの対象となるスキーマオブジェクトは、テーブルとする。また、以下の説明において、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するＣＰＵによって処理が行われるものとする。
【００２４】
図２は、本実施形態で行われる処理の流れの概要を示す。
【００２５】
シノニム３０１のシノニム名を指定したアクセスリクエスト（参照リクエスト、更新リクエスト）を、アクセス制御プログラム４０１が受け、それを、シノニム切替ＤＢＭＳ４０３に渡すようになっている。現時点では、シノニム３０１の対象が第一のテーブル３０３Ａであるとする。この場合、シノニム切替ＤＢＭＳ４０３は、該アクセスリクエストに応答して、第一のテーブル３０３Ａにアクセスする。これにより、第一のテーブル３０３Ａの参照や更新が実行される。
【００２６】
本実施形態では、第一のテーブル３０３Ａと、第二のテーブル３０３Ｂとが用意されており、シノニム３０１の対象が、適時に、交互に切り替えられるようになっている。図２は、シノニム３０１の対象を第一のテーブル３０３Ａから第二のテーブル３０３Ｂに切り替える例を示している。
【００２７】
シノニム対象の切り替えが行われる前に、アクセス制御プログラム４０１が、更新抑止状態になる（ステップＳ１）。この状態になるのは、後述するＳ２で第一のテーブル３０３Ａからのアンロード中にその第一のテーブル３０３Ａが更新されてしまうことによりデータの整合性が保証できなくなってしまうことを防ぐためである。なお、更新抑止状態とは、参照リクエストを受け付けた場合には該参照リクエストをシノニム切替ＤＢＭＳ４０３に渡すが、更新リクエストを受け付けた場合には該更新リクエストをシノニム切替ＤＢＭＳ４０３には渡さない状態である。更新抑止状態になるとは、例えば、アクセス制御プログラム４０１が内部的に更新抑止を設定することである。アクセス制御プログラム４０１は、例えば、更新抑止状態になっている間に更新リクエストを受け付けた場合には、リクエスト発行元（ＢＬ１０３）に更新完了を応答しないことにより（例えばビジー或いはリトライ要求を応答することにより）、更新リクエストがエラーになってしまうことを防げる。なお、更新抑止状態になるタイミングとしては、例えば、所定の時刻になったことが検出されたタイミング、或いは、シノニム対象の切り替えを行うことの通知を受信したタイミングがある。この通知は、例えば、シノニム切替ＤＢＭＳ４０３或いはバッチ用ＤＢサーバ１１３から受けることができる。
【００２８】
更新抑止の状態になった場合に、シノニム対象の切り替えのための準備処理（Ｓ２〜Ｓ４）が実行される。Ｓ２〜Ｓ４は、バッチ用ＤＢサーバ１１３内でＤＢＭＳ（例えばシノニム切替ＤＢＭＳ）が実行されることにより行われる。
【００２９】
Ｓ２では、バッチ用ＤＢサーバ１１３が、第一のテーブル３０３Ａの全件分のデータをまとめてアンロードする（読み出す）。２４時間オンラインシステムでは、膨大な数のリクエストが発行されることがあるため、ここでアンロードされた全件分のデータは、例えば、数百万件〜数千万件のデータである場合がある。この全件分のデータの集合を、以下、「アンロードデータ」と言う。
【００３０】
Ｓ３では、バッチ用ＤＢサーバ１１３が、マッチングデータを用いてアンロードデータの必要な部分を更新するバッチ処理を実行する。これにより、アンロードデータの全部或いは一部が更新される（ちなみに、マッチングデータとは、例えば、電子マネーシステムでは、アンロードデータと突き合わせるための、所定のデータセンタから配信されて来た締め用のデータ（例えば日次締めのためのデータ）とすることができる）。更新後のアンロードデータを、以下、「ロードデータ」と言う。
【００３１】
Ｓ４では、バッチ用ＤＢサーバ１１３が、作成されたロードデータを、第二のテーブル３０３Ｂにロード（格納）する。ロードデータも、アンロードデータと同様に、全件分のデータとなっているので、このロードでは、それら全件分のデータがまとめて格納されることになる。そのため、このＳ４では、従来型パスでのロードに比して高速にロードすることが可能なダイレクトパスでのロードが可能である。従来型パス及びダイレクトパスでのロードは、シノニム切替ＤＢＭＳでサポートされている機能である。
【００３２】
以上のＳ２〜Ｓ４により、第二のテーブル３０３Ｂに更新後の全件分のデータが登録される。言い換えれば、第二のテーブル３０３Ｂが、更新後の第一のテーブルとなる。
【００３３】
この後で、アクセス制御プログラム４０１が、シノニム対象（以下、「シノニム参照先」と言うこともある）の切り替え操作を行う。具体的には、例えば、アクセス制御プログラム４０１は、第二のテーブル３０３Ｂに更新後の全件分のデータが登録されたことを検知したタイミングで（或いは、Ｓ２〜Ｓ４の処理に要すると推測される時間を十分に待ったタイミングで）、その切り替え操作を行う。その検知は、例えば、第二のテーブル３０３Ｂに更新後の全件分のデータの登録が完了したことの通知をバッチ用ＤＢサーバ１１３から受けることにより、可能である。
【００３４】
シノニム対象の切り替えが完了する前までに、アクセス制御プログラム４０１が参照リクエストを受け付けた場合には、第一のテーブル３０３Ａの参照が実行される。しかし、その切り替えが完了した後に、参照リクエストを受け付けた場合には、第二のテーブル３０３Ｂの参照が実行される。
【００３５】
シノニム対象の切り替え後、アクセス制御プログラム４０１は、更新抑止状態を解除する（Ｓ６）。更新抑止状態の解除とは、例えば、アクセス制御プログラム４０１が内部的に更新抑止の設定を解除することである。アクセス制御プログラム４０１は、例えば、更新抑止状態を解除した後に、更新リクエストを受け付けた場合には、該更新リクエストをシノニム切替ＤＢＭＳ４０３に渡す。それにより、第二のテーブル３０３Ｂに対する更新が実行される。
【００３６】
第二のテーブル３０３Ｂにロードデータが格納された後、アクセス制御プログラム４０１は、第一のテーブル３０３Ａの削除をシノニム切替ＤＢＭＳ４０３に実行させることができる（Ｓ７）。
【００３７】
以上が、本実施形態で行われる処理の流れの一例の概要説明である。以上の流れによれば、参照と更新のうち、更新が、Ｓ２〜Ｓ５の期間、抑止された状態となる。しかし、Ｓ２でのアンロードやＳ４でのロードは、全件分のデータについてまとめて実行されるので、２４時間オンラインにおいて更新ができない期間は、２４時間のうち短い時間で済む。そして、参照は２４時間いつでも可能とされる。以上のことから、２４時間オンラインの要請をなるべく満たしつつ、シノニム参照先の切り替えを行うことができる。
【００３８】
さて、この処理の流れによれば、シノニム参照先が切り替えられるが、一般に、同一シノニム名を有する同一のシノニムを並存させることはできないので、何の工夫もしないと、シノニム参照先の切り替えのためにシノニムが存在しない期間ができてしまう。２４時間オンラインの状況では、常にリクエストが発生し得る状況なので、シノニムが存在しない期間ができてしまうと、エラーが発生してしまうことになる。
【００３９】
そこで、本実施形態では、複数種類のシノニムを同一のシノニム名で並存させることができる、シノニム切替ＤＢＭＳ４０３でサポートされている仕様を、アクセス制御プログラム４０１が巧みに利用することで、そのような問題点を解決することができる。以下、アクセス制御プログラム４０１の機能を理解し易くするために、まず、シノニム切替ＤＢＭＳ４０３でサポートされている仕様を説明し、その後で、アクセス制御プログラム４０１の機能を詳細に説明する。
【００４０】
＜シノニム切替ＤＢＭＳ４０３でサポートされている仕様の説明＞。
【００４１】
同一のシノニム名を有する第一種のシノニムと第二種のシノニムとを並存させることができ、並存している場合には、第二種のシノニムが優先的に使用される。この仕様を有するシノニム切替ＤＢＭＳとしては、例えば、オラクル社が提供するＤＢＭＳ（以下、オラクルＤＢＭＳ）がある。そのオラクルＤＢＭＳでは、第一種のシノニムが、パブリックシノニムに相当し、第二種のシノニムが、プライベートシノニムに相当する。
【００４２】
具体的には、図３（Ａ）に示すように、第一のテーブル３０３Ａを参照先とする第一種のシノニム３０１Ａが存在し、該第一種のシノニム３０１Ａと同一のシノニム名を有する第二種のシノニム３０１Ｂが存在しない場合に、該シノニム名を指定したアクセスリクエストがあったならば、該第一種のシノニム３０１Ａの参照先である第一のテーブル３０３Ａにアクセスが行われる。しかし、該第一種のシノニム３０１Ａと同一のシノニム名を有し第二のテーブル３０３Ｂを参照先とする第二種のシノニム３０１Ｂが作成された後に、該シノニム名を指定したアクセスリクエストがあったならば、優先的に第二種のシノニム３０１Ｂでのアクセスが行われる。つまり、第一のテーブル３０３Ａではなく第二のテーブル３０３Ｂへのアクセスが行われる。
【００４３】
その後に、図３（Ｂ）に示すように、第二種のシノニム３０１Ｂが削除された後に、上記のシノニム名でアクセスリクエストを受け付けた場合には、第一種のシノニム３０１Ａでのアクセスとなる。
【００４４】
＜アクセス制御プログラム４０１の機能の説明＞。
【００４５】
アクセス制御プログラム４０１は、図４（Ａ）〜図５（Ｂ）の一連の処理を繰り返すことを自動で実行する機能を有している。以下、その一連の処理を説明することで、アクセス制御プログラム４０１の機能を説明する。なお、図４（Ａ）〜図５（Ｂ）において、テーブルについて「新」、「古」という文字があるが、これは、テーブルの相対的な新古の関係を表している。
【００４６】
図４（Ａ）に示すように、第一のテーブル３０３Ａを参照先とした第一種のシノニム３０１Ａが存在する。この場合（例えば、後述するＳ１０での第二種のシノニムの削除を契機として）、アクセス制御プログラム４０１は、現在の第一種のシノニム３０１Ａの参照先の第一のテーブル３０３Ａを表す情報（以下、便宜上、「テーブル特定情報」と言う）を取得する（Ｓ０）。そのテーブル特定情報は、例えば、第一種のシノニム３０１Ａに関する情報（テーブル特定情報を含む）が設定されているシノニム切替ＤＢＭＳ４０３に所定の問い合わせを発行することにより、シノニム切替ＤＢＭＳ４０３から取得することできる。
【００４７】
アクセス制御プログラム４０１は、取得したテーブル特定情報から、どのテーブルを参照先とした第二種のシノニムを作成すべきかを判別する。具体的には、例えば、アクセス制御プログラム４０１には、予め、以下の定義情報、
・第一種のシノニムの参照先が第一のテーブルの場合には、第二のテーブルを参照先とする第二種のシノニムを作成、
・第一種のシノニムの参照先が第二のテーブルの場合には、第一のテーブルを参照先とする第二種のシノニムを作成、
が予め設定されている。アクセス制御プログラム４０１は、取得したテーブル特定情報を用いてその定義情報から、参照先とするテーブルを判別する。
【００４８】
図４（Ｂ）に示すように、アクセス制御プログラム４０１は、判別された第二のテーブル３０３Ｂを参照先とした、上記第一種のシノニム３０１Ａと同一のシノニム名を有する第二種のシノニム３０１Ｂを作成する（Ｓ５Ａ）。その作成は、第二のテーブル３０３Ｂを参照先とすることを表す情報と上記同一のシノニム名とを記述した所定の作成命令（例えばオラクルＤＢＭＳではCREATE SYNONYM文）をシノニム切替ＤＢＭＳ４０３に発行することで、行うことができる。
【００４９】
このような第二種のシノニム３０１Ｂが作成された後、シノニム切替ＤＢＭＳ４０３の前述した仕様により、アクセス先は、第一のテーブル３０３Ａから第二のテーブル３０３Ｂに変わる。なお、このように、第一種のシノニム３０１Ａと同一のシノニム名を有する第二種のシノニム３０１Ｂが作成されるとアクセス先が切り替わるので、上記Ｓ５Ａの前に、前述したＳ１〜Ｓ４が行われ、Ｓ５Ａの後に、前述したＳ６が行われ、Ｓ４が完了した後に、前述したＳ７が行われる。
【００５０】
アクセス制御プログラム４０１は、Ｓ５Ａの後（例えばＳ５Ａの実行を契機として）、第一のテーブル３０３Ａを参照先とする第一種のシノニム３０１Ａを削除する（Ｓ５Ｂ）。その削除は、上記同一のシノニム名を記述した所定の削除命令（例えばオラクルＤＢＭＳではDROP PUBLIC SYNONYM文）をシノニム切替ＤＢＭＳ４０３に発行することで、行うことができる。このＳ５Ｂの実行は、Ｓ５Ａの後であれば、Ｓ６の前でも後でも良い（Ｓ６と並行して行っても良い）。
【００５１】
図５（Ａ）に示すように、所定のタイミングで、テーブルの相対的な新古の関係が変わる（Ｓ８）。そのタイミングとしては、例えば、所定時刻になったタイミング、或るイベントが発生したタイミングなどがある。
【００５２】
Ｓ８により、第二のテーブル３０３Ｂが第一のテーブル３０１Ａに比して古くなった場合、後に、第二のテーブル３０３Ｂから全件分のデータをアンロードし更新後の全件分のデータを第一のテーブル３０１Ａにロードすることになる。該ロードの後に第一のテーブル３０１Ａをアクセス先とするためには、その第一のテーブル３０１Ａを参照先とした第二種のシノニムを作成する必要がある。なぜなら、第一のテーブル３０１Ａを参照先とした第一種のシノニムを作成しても、上記仕様により、第二種のシノニムが優先的に使用されるので、第一のテーブル３０１Ａへのアクセスが行われないためである。
【００５３】
同一のシノニム名を有する第二種のシノニムを並存させることはできない。
【００５４】
そこで、第一のテーブル３０１Ａを参照先とする第二種のシノニムを作成することができる状況にするために、以下の処理が実行される。
【００５５】
すなわち、まず、アクセス制御プログラム４０１が、第二種のシノニム３０１Ｂと同一のシノニム名を有し、第二種のシノニム３０１Ｂの現在の参照先である第二のテーブル３０３Ｂを参照先とする第一種のシノニム３０１Ａを作成する（Ｓ９）。これは、例えば、Ｓ５Ｂの第一種のシノニムの削除を契機として実行することができる。
【００５６】
しかし、このままでは、そのＳ９で作成された第一種のシノニム３０１Ａは利用されない。なぜなら、シノニム切替ＤＢＭＳ４０３の前述した仕様によれば、同一のシノニム名を有する場合には、第二種のシノニム３０１Ｂが優先的に利用されるからである。
【００５７】
そのため、アクセス制御プログラム４０１は、第二のテーブル３０３Ｂを参照先とする第二種のシノニム３０１Ｂを削除する（Ｓ３０１Ｂ）。これは、例えば、Ｓ９の第一種のシノニムの作成を契機に実行することができる。
【００５８】
これにより、Ｓ９で作成された第一種のシノニム３０１Ａを利用して第二のテーブル３０３Ｂにアクセスされることになる。また、これにより、第一のテーブル３０３Ａに、それを参照先とする第二種のシノニムを作成することが可能な状況となる。
【００５９】
この後、任意のタイミングで（例えば、Ｓ１０の第二種のシノニムの削除が実行されたことを契機に）、図４のＳ０が実行される。
【００６０】
以上の一連の処理によれば、シノニム参照先を切り替える場合であっても、リクエストで指定されるシノニム名のシノニムが存在しない期間を無くすことができる。これにより、リクエストでエラーが発生してしまうことを防ぐことができる。また、このような切り替えを、２４時間参照可能とした状態で行うことができる。
【００６１】
以上、本発明の一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、本発明に従うアクセス制御方式は、電子マネーシステムでのデータベースシステムに限らず、他のデータベースシステムに対しても適用することができる。また、シノニムの対象に対する更新を抑止したり更新抑止を解除したりする方法としては、上述した方法に限らず他の方法も採用できる。例えば、アクセス制御プログラム４０３による設定により、ＢＬ１０３が更新リクエストを発行するか否かを制御しても良い。具体的には、例えば、所定の記憶域に、更新抑止状態か否かを表すフラグを用意し、アクセス制御プログラム４０３は、更新抑止状態にする場合には、該フラグを立て（例えば値１を設定し）、更新抑止状態を解除する場合には、該フラグを倒す（例えば値０を設定する）。ＢＬ１０３で実行される所定のコンピュータプログラム（例えば、シノニム名を指定したアクセスリクエストを送信するプログラム）が、更新リクエストを発行する前に、該フラグを参照し、該フラグが立っていれば、更新リクエストを発行せず、該フラグが倒れていれば、更新リクエストを発行する。このような方法でも、更新を抑止したり更新抑止を解除したりすることができる。
【図面の簡単な説明】
【００６２】
【図１】（Ａ）は、本発明の一実施形態に係るコンピュータシステムの構成例を示す。（Ｂ）は、オンライン用ＤＢサーバ１１１の構成例を示す。
【図２】本発明の一実施形態で行われる処理の流れの一例の概要を示す。
【図３】（Ａ）は、第二種のシノニムが第一種のシノニムよりも優先的に使用されることの説明図。（Ｂ）は、第二種のシノニムが削除された場合には第一種のシノニムでのアクセスになることの説明図。
【図４】（Ａ）は、第一種のシノニムの参照先のテーブルを表す情報を取得することの説明図。（Ｂ）は、同一のシノニム名を有する第二種のシノニムが作成される場合に実行される処理の説明図。
【図５】（Ａ）は、第一と第二のテーブルの相対的な新古の関係が入れ替わることの説明図。（Ｂ）は、新しいテーブルを参照先とするための処理の説明図。
【符号の説明】
【００６３】
３０１Ａ…第一種のシノニム  ３０１Ｂ…第二種のシノニム  ３０３Ａ…テーブルＡ  ３０３Ｂ…テーブルＢ  ４０１…アクセス制御プログラム  ４０３…シノニム切替ＤＢＭＳ
【図１】
2008084255.tif 000003
【図２】
2008084255.tif 000004
【図３】
2008084255.tif 000005
【図４】
2008084255.tif 000006
【図５】
2008084255.tif 000007