JP2015170198A - データ処理装置、データ処理プログラム、データ処理方法、データベースシステム、及び通信システム - Google Patents

Abstract

【課題】 効率的に更新可能なデータ処理プログラムを提供する。
【解決手段】 本発明は、データベースへのアクセスを伴うプログラムを実行するデータ処理装置に関する。そして、本発明のデータ処理装置は、データベースにアクセスする構文を保持する構文データ保持手段と、構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づくデータベースへのアクセス実行を行うデータベースアクセス手段と、データベースアクセス手段を介したデータベースへのアクセスを伴うプログラムの実行を行うプログラム実行手段とを有し、構文データ保持手段に保持される構文が、データベースの構成と、プログラム実行手段の構成との差分を吸収する内容となっていることを特徴とする。
【選択図】 図１

Description

本発明は、データ処理装置、データ処理プログラム、データ処理方法、データベースシステム、及び通信システムに関し、例えば、データベース（以下、「ＤＢ」とも表す）にアクセスするデータベースクライアントアプリケーション（以下、「ＤＢクライアントＡＰＬ」とも呼ぶ）に適用し得る。

従来、プログラム開発を行うメーカでは、プログラムにより提供するサービスが類似する複数のシステム開発を行う際、各顧客要件に対応して細かいカスタマイズを行い、各顧客向けのファイルパッケージを作成する場合がある。

具体的には、例えば、特許文献１の記載技術のように、データベースとＤＢクライアントＡＰＬを利用するシステムについても、プログラム開発企業は、ＤＢクライアントＡＰＬ側のプログラム（ＤＢアクセス機能実装部）、及びデータベース自体について、顧客要件毎に開発を行う場合がある。特許文献１には、プログラムソースにデータベースを操作するためのＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）構文を埋め込んでシステム構成することについて記載されている。プログラムソースにデータベースを操作するためのＳＱＬ構文を埋め込んだ場合、例えば、図９のようなコードとなる。図９では、「加入者契約情報取得ＩＦ（）」という名前のサブプログラムにおいて、データベースにアクセスする関数（図９では「ＳＱＬ実行（）」という関数）に、引数としてＳＱＬ構文が代入された文字列（図９では「ｓｑｌ＿ｓｔｒｉｎｇ」という文字列）を与えて実行（図９では「ＳＱＬ実行（ｓｑｌ＿ｓｔｒｉｎｇ）；」というステップにより実行）するコードとなっている。

プログラムを開発するメーカとしては、第１の顧客向けのソースファイルと、第２の顧客向けのソースファイルを分けて管理し、それぞれメンテナンスすることは、開発工数が増大するため、ソースファイルは共通化（＝一本化）されていることが理想的である。

例えば、第１の顧客、第２の顧客共に、同じ機能の追加が発生した場合や、両方のファイルバージョンに共通する不具合を対処する場合など、ソースファイルが複数存在すると、フィードバック作業、ファイル化作業等が発生する。仮に、プログラム開発メーカがソースファイルを一本化し、例えば、通信事業者Ａにのみ機能追加が発生した場合、ファイルバージョン１．１に機能を追加し、ファイルバージョン１．２として、第１の顧客向けに提供すると、通常第２の顧客向けに提供した機能も実装されることになる。

特許公開平１０−１６１９１４号公報

しかしながら、提供するサービスが類似する複数のシステム（複数の顧客）について、共通的なＤＢクライアントＡＰＬを利用してデータベースシステムを開発する場合、その導入の際に、顧客によっては、利用しない余計な機能が実装されたり、利用しない機能を実装するためにサービス停止（例えば、ＤＢサーバの停止）を伴う作業が発生する等の問題が生じる場合がある。

そのため、効率的に更新可能なデータ処理プログラムを利用したデータ処理装置、データベースシステム、及び通信システムが望まれている。

第１の本発明のデータ処理装置は、（１）データベースにアクセスする構文を保持する構文データ保持手段と、（２）上記構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づく上記データベースへのアクセス実行を行うデータベースアクセス手段と、（３）上記データベースアクセス手段を介した上記データベースへのアクセスを伴うプログラムの実行を行うプログラム実行手段と、（４）上記構文データ保持手段に保持される構文が、上記データベースの構成と、上記プログラム実行手段の構成との差分を吸収する内容となっていることを特徴とする。

第２の本発明のデータ処理プログラムは、コンピュータを、（１）データベースにアクセスする構文を保持する構文データ保持手段と、（２）上記構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づく上記データベースへのアクセス実行を行うデータベースアクセス手段と、（３）上記データベースアクセス手段を介した上記データベースへのアクセスを伴うプログラムの実行を行うプログラム実行手段として機能させ、（４）上記構文データ保持手段に保持される構文が、上記データベースの構成と、上記プログラム実行手段の構成との差分を吸収する内容となっていることを特徴とする。

第３の本発明は、データ処理装置が行うデータ処理方法において、（１）構文データ保持手段、データベースアクセス手段、及びプログラム実行手段を備え、（２）上記構文データ保持手段は、データベースにアクセスする構文を保持し、（３）上記データベースアクセス手段は、上記構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づく上記データベースへのアクセス実行を行い、（４）上記プログラム実行手段は、上記データベースアクセス手段を介した上記データベースへのアクセスを伴うプログラムの実行を行い、（５）上記構文データ保持手段に保持される構文が、上記データベースの構成と、上記プログラム実行手段の構成との差分を吸収する内容となっていることを特徴とする。

第４の本発明は、データベースと、上記データベースにアクセスしてプログラムの実行を行うデータ処理装置とを備えるデータベースシステムにおいて、上記データ処理装置として第１の本発明のデータ処理装置を適用したことを特徴とするデータベースシステム。

第５の本発明は、複数の通信装置と、データベースと、上記データベースにアクセスして上記通信装置に通信サービスを提供するデータ処理装置とを備える通信システムにおいて、上記データ処理装置として、第１の本発明のデータ処理装置を適用したことを特徴とする通信システム。

本発明によれば、効率的に更新可能なデータ処理プログラムを提供することができる。

実施形態に係るデータベースシステムの動作について示した説明図（通信事業者Ａ向けのファイルバージョン１．１）について示した説明図である。 実施形態に係るデータベースシステムを適用した通信システムの全体公正について示したブロック図である。 実施形態に係るデータベースの構成例について示した説明図である。 実施形態に係るＡＰＬプログラムの機能的構成の例について示したブロック図である。 実施形態に係るＤＢアクセスライブラリプログラムが保持するアクセスライブラリの構成について示した説明図である。 実施形態に係るＤＢアクセスライブラリプログラムの基本的な動作について示したフローチャートである。 実施形態に係るデータベースシステムの動作について示した説明図（通信事業者Ａ向けのファイルバージョン１．０）について示した説明図である。 実施形態に係るデータベースシステムの動作について示した説明図（通信事業者Ｂ向けのファイルバージョン１．１）について示した説明図である。 従来のＤＢクライアントで、ソースコードにＳＱＬ構文を埋め込んだ場合の例である。

（Ａ）主たる実施形態
以下、本発明によるデータ処理装置、データ処理プログラム、データ処理方法、データベースシステム、及び通信システムの一実施形態を、図面を参照しながら詳述する。なお、以下では、本発明のデータ処理装置をデータベースクライアントに適用する例について説明する。

（Ａ−１）実施形態の構成
図２は、この実施形態の通信システム１の全体構成を示すブロック図である。

通信システム１には、データベースシステム１０を有している。そして、データベースシステム１０は、ＤＢサーバ２、及びＤＢクライアント３を有している。

データベースシステム１０は、ネットワークＮに接続する端末４(通信装置)に対して、ＤＢサーバ２のデータを利用したアプリケーションの提供を行うシステムである。

ＤＢサーバ２は、データベース２１を有し、データベース２１のデータをＤＢクライアント３に提供するものである。

ＤＢクライアント３は、ＡＰＬプログラム３１（アプリケーションプログラム）に従ってデータベース２１にアクセスし、データベース２１のデータを利用して端末４に対してアプリケーションサービスを提供するものである。ＤＢクライアント３としては、例えば、ネットワーク接続可能なコンピュータ（プログラムの実施構成）に実施形態のデータ処理プログラムを含むプログラムをインストールすることにより構成されるものであるものとする。

通信システム１の用途は限定されないものであるが、ここでは、ネットワークＮは通信事業者のネットワーク（例えば、種々のＩＰネットワーク）であり、ＤＢサーバ２、ＤＢクライアント３がネットワークＮに接続する加入者の端末４に対して、通信サービス（例えば、ＳＩＰを利用した各種音声通信サービス）を提供するものとして説明する。

具体的には、ここでは、ＤＢサーバ２は、各加入者（各端末４）のサービス契約状況を示す情報（以下、「加入者契約情報」と呼ぶ）を管理するためのシステムであるものとして説明する。そして、ＤＢクライアント３は、データベース２１の加入者契約情報等を読込み、そのデータに基づいて端末４に対して各種通信サービス（例えば、ＳＩＰを利用した各種音声通信サービス）を提供する装置（例えば、呼制御装置等の通信制御装置）であるものとして説明する。

また、ＤＢサーバ２及びＤＢクライアント３は、複数の通信事業者向けにカスタマイズやバージョンアップが可能な構成となっているものとする。この実施形態では、ＤＢサーバ２及びＤＢクライアント３について、第１の通信事業者Ａと、第２の通信事業者Ｂ向けにカスタマイズする例について説明する。また、ＤＢサーバ２及びＤＢクライアント３上のデータ構成やプログラム（ソースコード）は、バージョンアップ（更新）される場合もあり得るものとする。

なお、以下では、この当初のデータベースシステム１０を構成するＡＰＬプログラム３１のソースプログラム（ソースプログラムファイル）のバージョン（以下、「ファイルバージョン」と呼ぶ）を「ファイルバージョン」と呼ぶものとする。この実施形態では、まず、最初のＡＰＬプログラム３１（以下、この当初のＡＰＬプログラム３１を「ファイルバージョン１．０」と表すものとする）が、通信事業者Ａ向けのデータベースシステム１０に導入されたものとする。そして、その後、バージョン１．０のＡＰＬプログラム３１を更新（バージョンアップ）すると同時に、その更新されたＡＰＬプログラム３１を通信事業者Ｂ向けにカスタマイズする開発も行われたものとする。以下では、この更新後の通信事業者Ａ及びＢ向けのＡＰＬプログラム３１を「ファイルバージョン１．１」と表すものとする。

まず、ＤＢサーバ２を構成するデータベース２１の内部構成について説明する。

図３は、ＤＢサーバ２を構成するデータベース２１の構成例について示した説明図である。

図３（ａ）は通信事業者Ａ向けのデータベース２１の構成例（各加入者の加入者契約情報を構成する項目の例）であり、図３（ｂ）は通信事業者Ｂ向けのデータベース２１の構成例（各加入者の加入者契約情報を構成する項目の例）である。なお、この実施形態では、説明を簡易にするため各加入者の加入者契約情報について、各加入者の契約者名、電話番号、及び各サービスの契約状況に係る項目についてのみ抜き出した構成を例として説明する。

なお、通信事業者Ａ向けのＤＢサーバ２（データベース２１）の構成自体については、バージョン１．０とバージョン１．１で変更はないものとして説明する。

図３（ａ）に示すように通信事業者Ａの加入者契約情報は、「留守番電話契約」、「不在転送契約」、「キャッチフォン契約」の３種類のサービスに関する契約の有無（「あり」、又は「なし」）を示す項目で構成されている。

図３（ｂ）に示すように通信事業者Ｂの加入者契約情報は、「留守番電話契約」、「不在転送契約」、「キャッチフォン契約」、「三者通話契約」、「迷惑着信お断り契約」の５種類のサービスに関する契約の有無（「あり」、又は「なし」）を示す項目で構成されている。

すなわち、通信事業者Ｂ向けでは、「三者通話契約」、及び「迷惑着信お断り契約」２つの項目（カラム）について、加入者契約情報を構成するカラムが通信事業者Ａと比較して追加設定されているものとする。すなわち、この実施形態では、ファイルバージョン１．１がリリースされた時点で、「三者通話」、及び「迷惑着信お断り」の通信サービスについては通信事業者Ａでは提供していないが、通信事業者Ｂでは提供しているものとする。

図４は、ＤＢクライアント３を構成するＡＰＬプログラム３１の機能的構成例について示した説明図である。図４（ａ）は通信事業者Ａ向けのファイルバージョン１．０のＡＰＬプログラム３１の構成例であり、図４（ｂ）は通信事業者Ａ及びＢ向けのファイルバージョン１．１のＡＰＬプログラム３１の構成例である。

図４に示すように、ＡＰＬプログラム３１は、サービスレイヤプログラム３２及び共通部レイヤプログラム３３を有する。

サービスレイヤプログラム３２は、主として、端末４に対して通信サービス（例えば、ＩＰ電話サービス等）を提供するプログラム実行手段として機能するものである。ただし、サービスレイヤプログラム３２は、図４に示すように、各通信サービスの機能に対応する処理部に加えて、自装置や端末４を保守するためのコマンド制御処理部３２１、自装置がＩＰ交換局として必要とする局データ管理処理部３２２、及び収容加入者（各端末４）の契約情報を管理するための加入者管理処理部３２３なども実装しているものとする。

図４（ａ）に示すようにファイルバージョン１．０のサービスレイヤプログラム３２は、通信サービスに係る処理部（プログラム）として、留守番電話処理部３２４、不在転送処理部３２５、及びキャッチフォン処理部３２６を有している。

これに対して、図４（ｂ）に示すように、ファイルバージョン１・１のサービスレイヤプログラム３２は、通信サービスに係る処理部（プログラム）として、留守番電話処理部３２４、不在転送処理部３２５、キャッチフォン処理部３２６、迷惑着信お断り処理部３２７、及び三者通話処理部３２８を有している。

すなわち、ファイルバージョン１．０のサービスレイヤプログラム３２は、迷惑着信お断り処理部３２７及び三者通話処理部３２８を有していないが、ファイルバージョン１．１のサービスレイヤプログラム３２は、迷惑着信お断り処理部３２７及び三者通話処理部３２８を有している。

共通部レイヤプログラム３３は、上位ＡＰＬ、すなわち、サービスレイヤプログラム３２が利用する各機能に係るライブラリが実装されている。サービスレイヤプログラム３２には、少なくとも、ＤＢサーバ２（データベース２１）にアクセスするためのＤＢアクセスライブラリプログラム３３１が含まれているものとする。ただし、この実施形態では、サービスレイヤプログラム３２には、端末４と通信する際の通信制御機能を定義した端末信号制御ライブラリ３３２等も含まれるものとして説明する。

次に、ＤＢアクセスライブラリプログラム３３１の内部構成の例について説明する。

図５は、ＤＢアクセスライブラリプログラム３３１の構成を概念的に示した説明図である。

ＤＢアクセスライブラリプログラム３３１は、起動時に、ＳＱＬ構文が識別子（以下、「タグＩＤ」と呼ぶ）と対応付けて定義されたコンフィグファイルＦを読込んで、ライブラリとしてメモリ上に展開してアクセスライブラリ３３１ａを構成する。このように、ＤＢアクセスライブラリプログラム３３１は、コンフィグファイルＦ（構文データ）を保持する構文データ保持手段と、メモリ（アクセスライブラリ３３１ａ）上に展開したＳＱＬ構文を実行してデータベース２１にアクセスするデータベースアクセス手段として機能する。

この実施形態において、ファイルバージョン１．１のＡＰＬプログラム３１（プログラムのソースコードの内容自体）は、通信事業者ＡとＢで同じ構成のものが適用されるものとするが、通信事業者Ａ向けのＡＰＬプログラム３１と、通信事業者Ｂ向けのＡＰＬプログラム３１とでは、読み込まれるコンフィグファイルＦの内容が異なっているものとする。ＤＢクライアント３において、コンフィグファイルＦの格納領域は限定されないものであり、外部から通信によりダウンロードして取得する構成としてもよい。

なお、通信事業者ＡとＢで、ファイルバージョン１．１のＡＰＬプログラム３１（プログラムのソースコードの内容自体）として全く同じ内容のものをリリースするようにしてもよいが、一部に改変を加えるようにしてもよいことは当然である。ただし、ファイルバージョン１．１のＡＰＬプログラム３１（プログラムのソースコードの内容自体）において、少なくとも、ＤＢアクセスライブラリプログラム３３１については、通信事業者ＡとＢでまったく同じソースプログラムが適用されることが望ましい。

コンフィグファイルＦは、例えば、図５に示すように、タグＩＤ（１、２、３、…）と、当該タグＩＤに対応するＳＱＬ構文のテキストデータを交互に配置したファイルとしてもよい。なお、１つのタグＩＤに対応するＳＱＬ構文は複数のＳＱＬコマンドを用いて構成されていてもよい。

以下では、アクセスライブラリ３３１ａを構成する各ＳＱＬ構文をＳＱＬ構文Ｃと呼ぶものとする。また、タグＩＤが１、２、３、…のＳＱＬ構文Ｃを、それぞれＣ１、Ｃ２、Ｃ３、…と表すものとする。ＡＰＬプログラム３１では、このタグＩＤが各プログラム上のタグとして機能するものとして説明する。

アクセスライブラリ３３１ａにおけるＳＱＬ構文Ｃの保持形式（メモリ上での記憶の形式やメモリ上での配列パターン）については限定されないものであり、各ＤＢアクセスライブラリプログラム３３１から、タグＩＤに基づいて対応するＳＱＬ構文Ｃが呼び出す（読込む）ことができる構成であればよい。

ＤＢアクセスライブラリプログラム３３１が、コンフィグファイルＦを読込んでアクセスライブラリ３３１ａの構成（又は、再構成）を行うタイミングは限定されないものであり、例えば、プロセスの起動時としてもよいし、プログラム又はユーザ操作（例えば、コンフィグファイルの再読み込みを行うコマンドの実行）により再読み込みを実行することによりシステム運用中に読み込みも可能としてもよい。

ＤＢアクセスライブラリプログラム３３１（アクセスライブラリ３３１ａ）は、サービスレイヤプログラム３２の各サービス（処理部）用のインタフェースを実装し、サービスレイヤプログラム３２の各サービス（処理部）に公開される。

（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態の通信システム１の動作（実施形態のデータ処理方法）を説明する。

以下では、ＤＢクライアント３のＡＰＬプログラム３１（ＤＢアクセスライブラリプログラム３３１）が、ＤＢサーバ２にアクセスする際の動作を中心に説明する。

（Ａ−２−１）ＤＢアクセスライブラリプログラムの基本動作
まず、ＤＢアクセスライブラリプログラム３３１が、サービスレイヤプログラム３２の要求に応じてＳＱＬ構文の実行（ＤＢサーバ２からのデータ取得）を行う基本動作について、図６のフローチャートを用いて説明する。

ＤＢアクセスライブラリプログラム３３１（サービスレイヤプログラム３２の各サービス（各処理部）向けに実装された機能インタフェース）は、サービス機能（処理部）からの要求に対応したＳＱＬ構文を、アクセスライブラリ３３１ａ（メモリ上）から検索し（Ｓ１０１）、ＳＱＬ構文を取得し、サービス機能から渡されたパラメータ（つまり、検索／更新時の条件パラメータ）を設定して（Ｓ１０２）、ＤＢサーバ２にトランザクション要求（クエリ）を送信する（Ｓ１０３）。

そして、ＤＢアクセスライブラリプログラム３３１は、そのトランザクション要求（クエリ）の結果（検索結果）をＤＢサーバ２から取得（ＤＢサーバ２からの応答を取得）して（Ｓ１０４）、要求元（サービスレイヤプログラム３２）に返答する（Ｓ１０５）。

ＤＢアクセスライブラリプログラム３３１は、以上のような動作でサービスレイヤプログラム３２からの要求に基づき、ＤＢサーバ２にアクセスする。

（Ａ−２−２）通信事業者Ａ向けのシステム（ファイルバージョン１．０）の動作
次に、通信事業者Ａ向けのファイルバージョン１．０のＡＰＬプログラム３１の動作につい図７のシーケンス図を用いて説明する。

まず、ＤＢクライアント３において、ＤＢアクセスライブラリプログラム３３１が起動（プロセスが起動）し、コンフィグファイルＦが読み込まれたものとする（Ｓ２０１）。

次に、ＤＢアクセスライブラリプログラム３３１が、メモリ上に、コンフィグファイルＦに含まれる各ＳＱＬ構文Ｃを展開して、アクセスライブラリ３３１ａを構成する（Ｓ２０２）。

ここでは、図７に示すようにタグＩＤが１〜６の６個のＳＱＬ構文Ｃ１〜Ｃ６がアクセスライブラリ３３１ａに展開されたものとする。

ここでは、図７に示すようにタグＩＤが２のＳＱＬ構文Ｃ２の内容が、「ＳＥＬＥＣＴ 契約者名、電話番号、留守番電話契約、不在転送契約、キャッチフォン契約 ＦＲＯＭ 加入者契約情報」というＳＱＬ構文となっている。これは、なお、データベース２１上の「加入者契約情報」という名称のデータベースから、全ての加入者について「契約者名、電話番号、留守番電話契約、不在転送契約、キャッチフォン契約」の項目のデータを取得するためのＳＱＬ構文である。

その後、サービスレイヤプログラム３２のいずれかの処理部で、加入者契約情報の取得要求が発生し、ＤＢアクセスライブラリプログラム３３１に、その要求があったものとする（Ｓ２０３）。

具体的には、例えば、サービスレイヤプログラム３２の加入者管理処理部３２３で、ＤＢアクセスライブラリプログラム３３１に加入者契約情報取得を要求するインタフェースの関数が実行（例えば、「加入者契約情報取得IF()；」というソースコードに従った関数の実行）されたものとする。

そして、ＤＢアクセスライブラリプログラム３３１は、その要求に基づいて、タグＩＤが２のＳＱＬ構文Ｃ２を取得する（Ｓ２０４）。なお、ここでは、ＤＢアクセスライブラリプログラム３３１において、加入者契約情報の取得要求（加入者契約情報取得を要求するインタフェースの関数）に対応するタグＩＤとして、「２」が定義されているものとする。なお、サービスレイヤプログラム３２とＤＢアクセスライブラリプログラム３３１との間のインタフェース（プログラムインタフェース）の詳細については限定されないものであり、種々の構成を適用することができる。

そして、ＤＢアクセスライブラリプログラム３３１により、ＤＢサーバ２へ取得したＳＱＬ構文に基づくトランザクション要求（クエリ）が送信され（Ｓ２０５）、ＤＢサーバ２によりその結果（加入者契約情報）が返答されたものとする（Ｓ２０６）。

そして、ＤＢアクセスライブラリプログラム３３１は、返答された加入者契約情報を、要求元（サービスレイヤプログラム３２）に返答する（Ｓ２０７）。

その際、ＤＢアクセスライブラリプログラム３３１が処理する加入者契約情報は、データ構造体の形式で表すと、図７に示すように「契約者名、電話番号、留守番電話契約、不在転送契約、キャッチフォン契約」の項目で構成されるデータ構造体となる。

以上のように、通信事業者Ａ向けのバージョン１．０のＡＰＬプログラム３１では、加入者契約情報表のカラム構成上の項目は、留守番電話、不在転送、キャッチフォンの３種類となっており、ＳＱＬ構文及び、プログラム上のデータ構造体についても、この３種類の情報を取得、設定可能な実装がなされている。

（Ａ−２−３）通信事業者Ｂ向けのシステム（バージョン１．１）の動作
次に、通信事業者Ｂ向けのバージョン１．１のＡＰＬプログラム３１の動作につい図８のシーケンス図を用いて説明する。

図８に示す各ステップＳ３０１〜Ｓ３０７の動作は、ファイルバージョン１．０の動作（上述のステップＳ２０１〜Ｓ２０７）の動作とほぼ同様である。したがって、以下では、ファイルバージョン１．１のＡＰＬプログラム３１の動作について、ファイルバージョン１．０の動作との差異のみを説明する。

ファイルバージョン１．１のＡＰＬプログラム３１を構成するサービスレイヤプログラム３２では、図４（ｂ）に示すように、迷惑着信お断り処理部３２７及び三者通話処理部３２８が追加されている。また、それにともなって、通信事業者Ｂ向けのバージョン１．１のＡＰＬプログラム３１では、読込むコンフィグファイルＦの内容（一部のＳＱＬ構文Ｃの内容）も更新（迷惑着信お断り処理部３２７及び三者通話処理部３２８に関する構成の追加）が成されている。

具体的には、当該ＡＰＬプログラム３１では、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２（タグＩＤが２のＳＱＬ構文）の内容が、「ＳＥＬＥＣＴ 契約者名、電話番号、留守番電話契約、不在転送契約、キャッチフォン契約 三者通話契約、迷惑着信お断り契約ＦＲＯＭ 加入者契約情報」という内容になっている。すなわち、ファイルバージョン１．１のＡＰＬプログラム３１では、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２に、追加された通信サービスに係る情報「三者通話契約、迷惑着信お断り契約」が追加されている。

（Ａ−２−４）通信事業者Ａ向けのシステム（バージョン１．１）の動作
次に、通信事業者Ａ向けのバージョン１．１のＡＰＬプログラム３１の動作につい図１のシーケンス図を用いて説明する。

図１に示す各ステップＳ４０１〜Ｓ４０７の動作は、ファイルバージョン１．０の動作（上述のステップＳ２０１〜Ｓ２０７）の動作とほぼ同様である。したがって、以下では、通信事業者Ａ向けのファイルバージョン１．１のＡＰＬプログラム３１の動作について、ファイルバージョン１．０の動作との差異のみを説明する。

ただし、通信事業者Ａ向けのバージョン１．１のＡＰＬプログラム３１では、ＤＢアクセスライブラリプログラム３３１自体の構成は、通信事業者Ｂ向けのＡＰＬプログラム３１と同じとなる（ソースプログラムが同じであるため）。したがって、通信事業者Ａ向けのバージョン１．１のＡＰＬプログラム３１では、サービスレイヤプログラム３２向けのインタフェースで用いるデータ構造体（加入者契約情報の取得要求に対して返答する際のデータ構造体）の構造自体には、通信事業者Ａの通信システム１では実装されていない（データベース２１上にデータが存在しない）「三者通話」及び、「迷惑着信お断り」の項目が含まれている。

ただし、通信事業者Ａ向けのバージョン１．１のＡＰＬプログラム３１では、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２（タグＩＤが２のＳＱＬ構文）の内容が、「ＳＥＬＥＣＴ 契約者名、電話番号、留守番電話契約、不在転送契約、キャッチフォン契約、”契約なし”、”契約なし”ＦＲＯＭ 加入者契約情報」という内容を設定し、データベース２１の構成との差異（ギャップ）を吸収することができる。このＳＱＬ構文Ｃ２では、通信事業者Ｂ向けのＳＱＬ構文で「三者通話契約、迷惑着信お断り契約」となっていた部分について、定数（所定のデフォルト値、所定の固定データ）として「契約なし」を取得するように記述している。これにより、通信事業者Ａ向けのバージョン１．１のＡＰＬプログラム３１では、データベース２１上にデータが存在しない「留守番電話契約、不在転送契約」の２つの通信サービスに係る契約情報（カラム）にアクセスせずに、一律に「契約なし」という定数を取得することができる。

この時、コンフィグファイルＦの、加入者契約情報を読み出すＳＱＬ構文が、通信事業者Ａ向け、つまり、三者通話と迷惑着信お断りの契約についてＳＥＬＥＣＴしない、もしくは、「契約なし」（「非契約」）をデフォルト値としてＳＥＬＥＣＴするような構文が書かれていれば、サービスレイヤの機能部プログラムにおいても、顧客要件に対して動作を制限するような、プログラムの改修を必要とせずに済む。上述のような例を、具体的なＳＱＬ構文で表すと以下のような内容となる。

例えば、通信事業者Ｂ向けのファイルバージョン１．１（ＡＰＬプログラム３１）において、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２（タグＩＤが２のＳＱＬ構文）の内容は「ＳＥＬＥＣＴ 留守番電話契約，不在転送契約，キャッチフォン契約，三者通話契約，迷惑着信お断り契約 ＦＲＯＭ 加入者契約情報」となる。これに、対して、通信事業者Ａ向けのファイルバージョン１．１（ＡＰＬプログラム３１）において、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２は、「ＳＥＬＥＣＴ 留守番電話契約，不在転送契約，キャッチフォン契約，”契約なし”，”契約なし”ＦＲＯＭ 加入者契約情報」という内容に置き換えることができる。これは、つまり、実行するＳＱＬ文上で「契約なし」という定数（デフォルト値）を返却する動作となり、ＤＢ上に三者通話契約や、迷惑着信お断り契約のカラムが存在しなくても問題（例えば、データベース２１へのアクセス上のエラー等）は発生しない。

このように、コンフィグファイルＦに記述される各ＳＱＬ構文Ｃの内容は、データベース２１の構成（カラム構成や表構成）と、サービスレイヤプログラム３２の構成との差分を吸収する内容となっている。具体的には、コンフィグファイルＦに記述される各ＳＱＬ構文Ｃのうち、サービスレイヤプログラム３２に搭載されている処理部（機能）であって、データベース２１に存在しない処理部（機能）に係るカラムのデータ取得については、データベース２１にアクセスせずに定数を取得するように記述されているものとする。

（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。

ＤＢクライアント３のＡＰＬプログラム３１では、コンフィグファイルＦに記述される各ＳＱＬ構文Ｃの内容は、データベース２１の構成（カラム構成や表構成）と、サービスレイヤプログラム３２の構成との差分を吸収する内容となっている。その結果、ＤＢアクセスライブラリ内プログラムではＳＱＬ構文をコンフィグファイルＦから読み込むことにより、通信事業者Ａと通信事業者Ｂに提供するＤＢアクセスライブラリのプログラム、すなわち、ソースファイルは同一のものとなり、バージョンアップ（更新）や開発を行う工数を抑制することができる。一方、この実施形態のようなＳＱＬ構文の処理を採用しない従来のＤＢクライアントＡＰＬを適用したデータベースシステムでは、通信事業者Ａ向けと通信事業者Ｂ向けに異なるＤＢアクセスライブラリプログラムを開発する必要があるため、バージョンアップ（更新）に必要な工数がその分増大することになる。

また、上述の例で、ファイルバージョン１．１から、通信事業者Ａへの機能追加により、さらにファイルバージョン１．２が作成され、提供された場合を想定する。例えば、ＡＰＬプログラム３１開始時に、ＤＢサーバ２から、ＤＢクライアント３が収容する加入者（端末４）の情報をダウンロード（加入者契約情報取得要求による取得）すると、取得した加入者契約情報の中には、通信事業者Ｂで提供される「三者通話」と「迷惑着信お断り」の契約有無に対する処理が動作するはずであるが、実際には、通信事業者Ａ向けのデータベース２１には、これら２つの通信サービスの契約に対するカラムは存在しないはずである。具体的には、例えば、通信事業者Ｂ向けのファイルバージョン１．１（ＡＰＬプログラム３１）において、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２（タグＩＤが２のＳＱＬ構文）の内容は、上述の通り「ＳＥＬＥＣＴ 留守番電話契約，不在転送契約，キャッチフォン契約，三者通話契約，迷惑着信お断り契約 ＦＲＯＭ 加入者契約情報」となる。これに対して、通信事業者Ａ向けのファイルバージョン１．２（ＡＰＬプログラム３１）においても、加入者契約情報の取得要求に対応するＳＱＬ構文Ｃ２を上述と同様に、「ＳＥＬＥＣＴ 留守番電話契約，不在転送契約，キャッチフォン契約，”契約なし”，”契約なし”ＦＲＯＭ 加入者契約情報」とする。この場合、ＤＢアクセスライブラリプログラム３３１が実行するＳＱＬ構文上で「契約なし」という定数を返却する動作となり、データベース２１に「三者通話契約」や、「迷惑着信お断り契約」のカラムが存在しなくても問題は発生しない。

このように、ＡＰＬプログラム３１では、更新に伴って、誤動作させたくない機能（プログラム）や利用しない機能（プログラム）に係るパラメータについて、ＤＢアクセスライブラリプログラム３３１が実行するＳＱＬ構文上で「契約なし」という定数（所定のデフォルト値）を返却する動作を行うことにより、複数のシステム（複数の顧客）で共通的なソースコードを用いた開発やバージョンアップを行った場合でも、ＤＢサーバ２（データベース２１）の構成変更（カラム追加等の変更）を行わずに、誤動作発生（例えば、バグの発生）のおそれを抑制することができる。

仮に、この実施形態のようなＳＱＬ構文の処理を採用しないＤＢクライアントＡＰＬを適用したデータベースシステムで、同様の更新（バージョンアップ）を行おうとした場合を想定する。この場合、運用中のＤＢサーバの構成変更作業（表構成をカラム追加等により変更する作業）が発生するが、運用中システムを停止後に実施する必要があり、サービス中断に発展する。すなわち、ＤＢクライアントＡＰＬが共通化されたことにより、当該顧客が必要としない機能を実装するために、ＤＢサーバを停止した作業の実施は（未使用機能が、既存システムに悪影響がないことを担保したとしても）、当該顧客の承諾を得る事は難しいと考えられる。また、ＤＢサーバの構成変更作業は、運用中システムを停止後に実施する必要があり、サービス中断に発展するが、この実施形態のデータベースシステム１０では上述のような問題の発生を抑制することができる。

（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｂ−１）上記の実施形態では、顧客毎に異なるデータベースの表構成（上記例では、加入者契約情報のカラム構成）の差分を吸収するＳＱＬ構文について説明したが、表自体の差分について吸収するＳＱＬ構文をコンフィグファイルに設定するようにしてもよい。例えば、ＤＢサーバ２（データベース２１）に表自体が存在しない機能（他の顧客のシステムでは利用されている機能）が、ＡＰＬプログラム３１に追加された場合、当該機能に係るＳＱＬ構文として、「ＳＥＬＥＣＴ 定数，定数，定数，定数，定数・・・ ＦＲＯＭ ＤＵＡＬ」という内容を適用するようにしてもよい。これは、実体を持たない架空の表（ＯＲＡＣＬＥ（登録商標）データベースの場合は、ＤＵＡＬという表名）から、必要なカラム数分の定数を取得する定義であり、差分となる表を構成するカラムを全て、ＳＱＬ構文上で定数定義をすれば良いことを示している。

１…通信システム、１０…データベースシステム、２…ＤＢサーバ、２１…データベース、３…ＤＢクライアント、３１…ＡＰＬプログラム、３２…サービスレイヤプログラム、３２１…コマンド制御処理部、３２２…局データ管理処理部、３２３…加入者管理処理部、３２４…留守番電話処理部、３２５…不在転送処理部、３２６…キャッチフォン処理部、３２７…迷惑着信お断り処理部、３２８…三者通話処理部、３３…共通部レイヤプログラム、３３１…ＤＢアクセスライブラリプログラム、３３１ａ…アクセスライブラリ、３３２…端末信号制御ライブラリ、４…端末、Ｃ…ＳＱＬ構文、Ｆ…コンフィグファイル。

Claims (6)

1. データベースにアクセスする構文を保持する構文データ保持手段と、
   上記構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づく上記データベースへのアクセス実行を行うデータベースアクセス手段と、
   上記データベースアクセス手段を介した上記データベースへのアクセスを伴うプログラムの実行を行うプログラム実行手段と、
   上記構文データ保持手段に保持される構文が、上記データベースの構成と、上記プログラム実行手段の構成との差分を吸収する内容となっていること
   を特徴とするデータ処理装置。
2. 上記構文データ保持手段に保持される構文のうち、上記プログラム実行手段に搭載されている機能であって、上記データベース上に存在しない機能に係るカラムのデータ取得については、上記データベースにアクセスせずに所定データを取得するように記述されていることを特徴とする請求項１に記載のデータ処理装置。
3. コンピュータを、
   データベースにアクセスする構文を保持する構文データ保持手段と、
   上記構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づく上記データベースへのアクセス実行を行うデータベースアクセス手段と、
   上記データベースアクセス手段を介した上記データベースへのアクセスを伴うプログラムの実行を行うプログラム実行手段として機能させ、
   上記構文データ保持手段に保持される構文が、上記データベースの構成と、上記プログラム実行手段の構成との差分を吸収する内容となっていること
   を特徴とするデータ処理プログラム。
4. データ処理装置が行うデータ処理方法において、
   構文データ保持手段、データベースアクセス手段、及びプログラム実行手段を備え、
   上記構文データ保持手段は、データベースにアクセスする構文を保持し、
   上記データベースアクセス手段は、上記構文データ保持手段から構文を読込んで管理し、要求に応じて管理している構文に基づく上記データベースへのアクセス実行を行い、
   上記プログラム実行手段は、上記データベースアクセス手段を介した上記データベースへのアクセスを伴うプログラムの実行を行い、
   上記構文データ保持手段に保持される構文が、上記データベースの構成と、上記プログラム実行手段の構成との差分を吸収する内容となっていること
   を特徴とするデータ処理方法。
5. データベースと、上記データベースにアクセスしてプログラムの実行を行うデータ処理装置とを備えるデータベースシステムにおいて、上記データ処理装置として請求項１又は２に記載のデータ処理装置を適用したことを特徴とするデータベースシステム。
6. 複数の通信装置と、データベースと、上記データベースにアクセスして上記通信装置に通信サービスを提供するデータ処理装置とを備える通信システムにおいて、
   上記データ処理装置として、請求項１又は２に記載のデータ処理装置を適用したことを特徴とする通信システム。

Images