トップ :: G 物理学 :: G06 計算;計数




【発明の名称】 データベースシステム
【発明者】 【氏名】松浦 洋

【氏名】小倉 隆宏

【氏名】久保田 敦紀

【氏名】高野 誠
【要約】 【課題】汎用的で高い再利用性をもつエンタープライズJava Beansによるデータベースシステムを実現する。

【解決手段】クライアントからデータベースのコラムとデータを指定されると共に演算要求があったとき、指定されたコラムに対して指定されたデータの演算を行い、演算結果をクライアントに返すデータ演算手段（plusInt （String,int）２２４、minusInt（String,int）２２５、multiplyInt （String,int）２２６、divideInt （String,int）２２７、plusFloat(String,float) ２２９等）を、Javaのデータ型と演算（加、減、乗、除）毎に設けると共に、クライアントからデータベースのコラムを指定されると共にデータ取得要求があったとき、指定されたコラムのデータを取得しクライアントに返すデータ取得手段（currentIntValue （String）２２３、currentFloatValue（String）２２８等）を、Javaのデータ型毎に設けたことを特徴とする。
【特許請求の範囲】
【請求項１】 エンタープライズJava BeansのEntity Beansを用いてリレーショナルデータベースへのアクセスを容易にするデータベースシステムにおいて、クライアントからデータベースのコラムとデータを指定され、演算要求があったとき、前記指定されたコラムに対して前記指定されたデータの演算を行い、演算結果を前記クライアントに返すデータ演算手段を、Javaのデータ型と演算毎に設けたことを特徴とするデータベースシステム。
【請求項２】 エンタープライズJava BeansのEntity Beansを用いてリレーショナルデータベースへのアクセスを容易にするデータベースシステムにおいて、クライアントからデータベースのコラムを指定され、データ取得要求があったとき、指定されたコラムのデータを取得し前記クライアントに返すデータ取得手段を、Javaのデータ型毎に設けたことを特徴とするデータベースシステム。
【請求項３】 エンタープライズJava BeansのEntity Beansを用いてリレーショナルデータベースへのアクセスを容易にするデータベースシステムにおいて、クライアントからデータベースのコラムとデータを指定され、演算要求があったとき、前記指定されたコラムに対して前記指定されたデータの演算を行い、演算結果を前記クライアントに返すデータ演算手段を、Javaのデータ型と演算毎に設けると共に、クライアントからデータベースのコラムを指定され、データ取得要求があったとき、指定されたコラムのデータを取得し前記クライアントに返すデータ取得手段を、Javaのデータ型毎に設けたことを特徴とするデータベースシステム。
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、データベース管理技術に関し、JavaBeans を用いてデータベースに対してアクセスを行うフレームワークであるEntity Beansをリレーショナルデータベースに適用した場合のデータベースシステムに関するものである。
【０００２】
【従来の技術】1999年 7月にSun Microsystemsが提唱した“Enterprise JavaBeans Specification，v1.1”（EJB ）は、複数のベンダにより実装されており、主にデータベースアクセスへの簡素化、トランザクション管理に広く利用され始めている。EJB では２つのBeanを定義している。一つはSession Beanで、もう一つはEntity Bean である。本発明はEntity Bean に関するものである。
【０００３】Entity Bean の構造を図３に示す。図３において、クライアント１は、EJBHome ２１、２２と、EJBObject ３１〜３６にアクセスすることにより、Container １１が管理するEnterprise Bean1４１、Enterprise Bean2 ４２に対してアクセスする。EJBHome ２１は、EntityBean Instance ５１〜５３の作成、検索、削除を行う。EJBHome ２２は、EntityBean Instance ５４〜５６の作成、検索、削除を行う。EJBObject3３１〜３６は作成されたEntity Bean Instance ５１〜５６のリモートインタフェースを提供するオブジェクトである。
【０００４】Enterprise Bean1 ４１、Enterprise Bean2 ４２等のEnterprise Bean の実装は、Enterprise Bean 提供者によって行われ、EJBHome ２１、２２、EJBObject３１〜３６クラスの実装はContainer １１の提供者によって行われる。
【０００５】Entity Bean には２つの永続化手法がある。一つはBMP （Bean Managed Persistence）という手法であり、他はCMP （Container Managed Persistence ）という手法である。BMP では、Enterprise Bean ４１、４２のInstance５１〜５６がデータベースへの永続化（データ生成／削除／検索／読み書き）を行うのに対し、CMP では、Container １１が、Enterprise Bean の永続化項目を抽出することにより、データのデータベースへの永続化（データ生成／削除／検索／読み書き）を行う。
【０００６】CMP の方が、Enterprise Bean に永続化のための振る舞いを記述する必要がないので、Enterprise Bean を容易に生成できるメリットがあるが、反面あるBeanInstance にアクセスされた場合に、固定的な永続データ（属性）を全てデータベースとの間で同期を取る必要がある等のデメリットがあると考えられる。
【０００７】図４は、Entity Bean のクライアント(Client)１からのBean Instance のcreate（args）９２要求についてのシーケンスを示す。尚、このシーケンスはBMP の場合を示している。また、トランザクションの開始は、Client１からのJavax.transaction.UserTransaction.begin （）９１によって行われる例を示しているが、このトランザクションの開始はContainer １１によって自動的に開始される場合もある。
【０００８】Create（args）９２を受け取ったEJB Home２１は、Entity Bean Instance ５１のejbCreate （args）９３メソッドを呼び出す。EjbCreate （args）９３は引数に従いBean Instance の活性化９４を行い、同時にEntity Bean Instance ５１に相当するデータをDatabase８１内に作成要求する。リレーショナルデータベースでは、行を１行追加要求することになる。
【０００９】また、DBMSは追加するDatabase８１内のデータをTransaction Service ７１内のResource Managerに登録９６する。これは、トランザクションがロールバックされたとき等に、追加要求されたデータを元に戻すときに利用される。
【００１０】次に、EJB Home２１は新規に作成されたBean Instance に対応するリモートインタフェースを持つEJB objectをContainer １１内に作成する。さらにはEntityBean Instance４１のejb PostCreate（args）９８メソッドを呼び出す。さらに、Synchronization ６１を新たにnew し、registerSynchronization （Synchoronization）１００メソッドでTransaction Service ７１に登録する。
【００１１】このnew ９９されたSynchronization ６１オブジェクトは、Transaction がCommitされたときにTransaction Service ７１から呼び出され、registerSynchronization （Synchronization）１００後に、Transaction に関係したEntity BeanInstance群がDatabase８１との間で同期をとる処理のトリガとなる。
【００１２】図５は、クライアント（Client）１からのBean Instance のcreate（args）９２要求をCMP で処理した場合のシーケンスを示すものである。図４と異なる部分は、９４のBean Instance 活性化の後に、Container の１クラスであるEJB Home２１が、当該Bean Instance ９４の属性の中でDatabase内へ永続化する属性を抽出１０１し、Bean Instance ９４に相当するデータをDatabase８１内に作成要求１０２する。リレーショナルデータベースでは行を１行追加要求することになる。
【００１３】図４と図５の比較から分かるように、CMP ではEntity Bean InstanceがDatabase内へのデータ作成要求をする必要がないので、Bean Provider にとってはプログラム作成量が少なくなるメリットがある。
【００１４】図６は、クライアント（Client）１が、トランザクションの開始をJavax.transaction.UserTransaction.begin() で行った後に、Entity Bean instance ５１のBusiness method のリモートインタフェースであるEJB Object３１のBusinessmethod １１１を呼び出す場合のシーケンスを示している。尚、この処理はBMPを前提としている。トランザクション開始後最初のBusiness method １１１を呼び出されたEJB object３１は、対応するEntity Bean instance ５１のejbLoad （）１１２を呼び出す。Entity Bean instanceでは必要に応じて、Entity Bean instance ５１に対応するDatabase８１内のデータをEntity Bean instance ５１に反映１１３する。
【００１５】また、DBMSはこの処理でアクセスされたDatabase８１内のデータをTransaction Service ７１内のResource Managerに登録９６する。その後にEJBObject ３１は、Synchronization ６１を新たにnew し、registerSynchronization （Synchoronization）１００メソッドでTransaction Service ７１に登録する。このようなContainer 特有の処理を行った後に初めて、EJBobject ３１は対応するBusiness method １１４を呼び出すことになる。同一トランザクション中の２度目の同一Entity object ３１に対するBusiness method １１５要求は、既にDatabase８１の情報を必要に応じて反映しているので、直接Entity Bean instance ５１の対応するBusiness method １１６を呼び出す。
【００１６】図７は、図６と同様にクライアント（Client）１が、トランザクションの開始をJavax.transaction.UserTransaction.begin （）で行った後に、Entity Beaninstance ５１のBusiness method のリモートインタフェースであるEJB Object３１のBusiness method １１１を呼び出す場合のシーケンスを示している。ただし、この処理はCMP を前提としている。図６のBMP との違いは、Business method １１１に対応して１２１に示すように、EJB Objectに対応するDatabase８１内のデータを１２１でreadするところと、その取得したデータを永続属性抽出１０１後、その属性に反映するところである。
【００１７】図６と図７の比較から分かるように、CMP では、Entity Bean InstanceがDatabase８１内のデータをinstanceに反映する必要がないので、Bean Provider にとってはプログラム作成量が少なくなるメリットがある。逆に、図７に示すようにCMP では、Transaction に関わらず、Entity Bean instance ５１に一律の永続属性をDatabase８１から取得することになる。これらのデータはTransaction が終了するまでDatabase８１内で排他制御されることになるので、Database８１内の並列処理に制限を与えるデメリットがある。また、Container とDatabase８１との間で流通されるデータ量も多くなる。
【００１８】これに対して、図６に示すようにBMP では、Entity Bean Instance ５１のejbLoad （）１１２でDatabase８１のデータをEntity Bean Instance ５１に反映するタイミングがあるが、この際に反映するデータはプログラマにまかせられる。また、ejbLoad （）１１２ではデータの反映を行わずに、Business method １１４、１１６の中でデータベースにアクセスし、そのデータをEntity Bean Instance ５１に反映する手法も有効である。この手法を使えは、各Business methodが必要とするデータだけをDatabase８１から取得することが可能である。
【００１９】図８は、クライアント（Client）１からのトランザクションのCommit要求をJavax.transaction.UserTransaction.commit（）１３１関数でTransaction Service ７１が受けた場合のシーケンスである。尚、この処理はBMP を前提としている。Transaction Service ７１は、Javax.transaction.UserTransaction.commit（）１３１に呼応してContainer のsynchronization に対してbeforeCompletion（）１３２を要求する。このbeforeCompletion（）１３２要求を受けたSynchronization ６１は、当該Transaction に参加したEntity Bean Instance４１に対してejbStore（）１３３要求を行う。このejbStore（）１３３で、Transaction 中に更新されたEntity Bean Instance ５１の属性のDatabase８１内への反映要求１３４を行う。
【００２０】Transaction Service ７１は、その後にDatabase８１に対して２相コミットprepare （）１３５、commit（）１３６を行う。さらに、Transaction Service ７１はSynchronization に対して、afterCompletion （）１３７要求を行う。AfterCompletion （）要求を受けた場合のSynchronization の処理はContainer の設定によっても異なるが、活性化されていたEntity Bean Instanceを非活性化する場合等がある。
【００２１】図９は、図８と同様に、クライアント（Client）１からのトランザクションのCommit要求をJavax.transaction.UserTransaction.commit（）１３１関数でTransaction Service ７１が受けた場合のシーケンスを示す。ただし、この処理はCMP を前提としている。BMP との違いは、BMP でEntity Bean Instance４１がejbStore（）の中で行っていた、属性のDatabase８１への反映処理１３４をContainer の１クラスであるSynchronization が管理属性の抽出１０１、属性のDatabaseへのアップデート１４１により自動的に行うことである。
【００２２】図８と図９の比較から分かることは、CMP は、Entity Bean のejbStore（）のプログラミングをする必要がないため、BMP と比ベてプログラム作成の負担は軽減することである。ただし、図９に示すように、CMP では１０１と１４１の処理において、Entity Bean Instanceの全ての永続属性を抽出して、その永続属性をアップデートする必要がある。これらの永続属性はトランザクションが始まったときから、Database８１内でロックされていることになるので、Instance４１に対応する永続属性はDatabase８１内でロックされる期間が長くなることになる。また、Entity Bean Instance４１とDatabase８１の間でやりとりされるデータ量も多くなる。
【００２３】これに対し、図８に示すようにBMP では、Database８１に対するアクセスは、そのトランザクションに必要な永続属性に対するアクセスで行うことができる。すなわち、図８のejbStore（）１３３内でDatabase８１内に対するアクセス記述をしてもよいし、ejbStore（）１３３内ではDatabase８１に対するアクセス記述を行わず、Business method の中でデータベースヘの書き込みを行う方法も有効である。
【００２４】
【発明が解決しようとする課題】上述した従来のEntity Bean では、BMP 、CMP それぞれに次のような問題があった。BMP では、図４、図６、図８の例で示すように、データベースへのアクセスをプログラマが記述しなければならないので、工数がかかるという問題があった。
【００２５】また、CMP では、図５、図７、図９の例で示すように、データベースとEnterprise Java Beans との間のデータのやり取りをContainer が行ってくれるので、プログラマが記述する必要がない利点があるが、データベースとEnterprise Java Beans との間で常に一律の永続情報がやり取りされるので、Enterprise JavaBeans の永続属性数が多い場合は、Enterprise Java Beans とデータベースとの間の情報量が必要以上に多くなったり、データベース内でトランザクション中、排他制御される対象データが必要以上に多くなる可能性があるという問題があった。
【００２６】もう一つのCMP の問題点を図１０に示す。この例は、BankBeanという名のEntity Bean で、普通／定期／外貨（アメリカドル）のそれぞれの預金残高を参照するものである。図１０において、BankBeanに対するEJBHome １５１の中のcreate（String）関数１５２とfind（String）関数１５３は、それぞれ指定されたStringをPrimaryKey （ここではid１７４）とするBankBean instance の活性化と検索を行う。
【００２７】１６１、１６２、１６３のEJBObject はそれぞれ、１７１、１７２、１７３のBankBean Instance に対応し、BankBeanのリモートのBusiness method であるget-ordinary（）１６４、get ＿time（）１６５、get ＿america （）１６６を提供する。BankBean instance には、PrimaryKeyであるString型のid１７４（名前）の外に、integer 型のordinary１７５、 time １７６、 america１７７でそれぞれの預金残高を永続情報としてもっている。
【００２８】また、その残高を返す関数である、get ＿ordinary（）１７８、get ＿time（）１７９、get ＿america （）１８０が含まれる。永続情報に指定したordinary１７５、time１７６、america １７７は、Transaction の開始と共に、Database８１内のAccount Table １９１からContainer １１によりアップデートされ、Transaction のCommit時にContainer １１によりDatabase８１内のAccount Table１９１に格納される。
【００２９】つまり、BankBeanはデータベースに対するアクセス処理を、そのBusiness method であるget ＿ordinary（）１７８、get ＿time（）１７９、get ＿america（）１８０で記述する必要はなく、変数であるordinary１７５、time１７６、america １７７の値をreturnする記述を行うだけでよいのである。
【００３０】ただ、問題は、Bank Service Provider １８１が他の預金（ここでは外貨（韓国のWON ）を新預金として加えたときに生じる。この韓国預金に対しては、EJBObject内にリモートのBusiness Method が存在しないし、BankBeanにも対応する永続属性、及びBusiness Method が存在しない。このように新規のテーブル追加の際にEntity Bean の属性、メソッドを追加して、その永続属性の指定をEntityBean のContainer 内への配布時に指定しなくてはならないことになる。
【００３１】この制約により、新預金追加のたびにクライアントからの要求を一時ストップしなくてはならないような事態が起きかねない。また、Entity Bean の変更はプログラマが人手で行うので、変更時にバグや食い違いが起きることが懸念される。
【００３２】本発明は上述したCMP の問題を解決し、様々なリレーショナルデータベースのデータに対して汎用的に再利用できるEntity Bean を用いたデータベースシステム及びデータベースへのアクセス方法を提供することを目的としている。
【００３３】
【課題を解決するための手段】上記の目的を達成するために、本発明によるデータベースシステムは、エンタープライズJava BeansのEntity Beansを用いてリレーショナルデータベースへのアクセスを容易にするデータベースシステムにおいて、クライアントからデータベースのコラムとデータを指定され、演算要求があったとき、前記指定されたコラムに対して前記指定されたデータの演算を行い、演算結果を前記クライアントに返すデータ演算手段を、Javaのデータ型と演算毎に設けたものである。
【００３４】また、本発明による他のデータベースシステムは、エンタープライズJava BeansのEntity Beansを用いてリレーショナルデータベースへのアクセスを容易にするデータベースシステムにおいて、クライアントからデータベースのコラムを指定され、データ取得要求があったとき、指定されたコラムのデータを取得し前記クライアントに返すデータ取得手段を、Javaのデータ型毎に設けたものである。
【００３５】また、本発明による他のデータベースシステムは、エンタープライズJava BeansのEntity Beansを用いてリレーショナルデータベースへのアクセスを容易にするデータベースシステムにおいて、クライアントからデータベースのコラムとデータを指定され、演算要求があったとき、前記指定されたコラムに対して前記指定されたデータの演算を行い、演算結果を前記クライアントに返すデータ演算手段を、Javaのデータ型と演算毎に設けると共に、クライアントからデータベースのコラムを指定され、データ取得要求があったとき、指定されたコラムのデータを取得し前記クライアントに返すデータ取得手段を、Javaのデータ型毎に設けたものである。
【００３６】また、本発明によるデータベースシステムにおいて、前記演算は、加、減、乗、除のうちの少なくとも一つである。
【００３７】
【作用】従って、本発明によれば、クライアントからデータベースのコラムとデータを指定されると共に演算要求があると、これに応じて、前記指定されたコラムに対して前記指定されたデータの演算をJavaのデータ型に応じて行い、その演算結果を前記クライアントに返す処理が実行される。
【００３８】また、クライアントからデータベースのコラムを指定されると共にデータ取得要求があると、これに応じて、指定されたコラムのデータをJavaのデータ型に応じて取得し、クライアントに返す処理が実行される。上記により、様々なリレーショナルデータベースのデータ型に対して、汎用的にEntity Bean を再利用することができる。
【００３９】以下、本発明の実施の形態を図面を参照して説明する。前述したように、CMP という手法は、データベースヘのアクセス内容をアプリケーション側で自動生成するためプログラマの負担が少ないという利点があるが、データベースにアクセスするための情報量が大きい、排他制御が多くなる、データベースのスキーマ変更に柔軟に対応できないといった欠点があった。
【００４０】本実施の形態は、CMP のこれらの問題を解決すると共に、再利用性の高いコンポーネントとして提案するEntity Bean （本実施の形態においては、UtilityBean と命名する）を様々な環境で、プログラムレスで適用できることに特徴がある。
【００４１】本実施の形態においては、BMP を利用するが、BMP の問題であるEntity Beanプログラム量の増大を軽減するために多くのアプリケーションでプログラムの変更なしにEntity Bean （Utitity Bean）が再利用できるようにしている。この新しい手法では、BMP におけるプログラム量の増大を軽減するために、リレーショナルデータベースに対する汎用的なアクセス手法（加減乗除）を利用可能としており、これにより、従来から利用していたアプリケーションを流用してデータベースヘのアクセス制御を行うことができ、新たなプログラムの追加を行う必要がなくなった。これにより、様々なリレーショナルデータベースのデータに対して、UtilityBean を汎用的に再利用できるという効果を得ることができる。
【００４２】図１は、本発明の実施の形態によるEntity Bean （以下、Utility Bean２３１と呼ぶ）と、その主なBusiness Method と、そのリモートインタフェースを持つEJBObject であるUtility ２１１、及びそのライフサイクル、検索を主に司るEJBHome であるUtilityHome ２０１を示している。２２２はString型のidであり、対応するリレーショナルデータベースのPrimary Key と同じ項目をString型で保持する。
【００４３】２２３〜２２９はUtility Beanの主なBusiness Method を示している。currentIntValue （String）２２３は、引数で指定されたString型のコラムに対する値を取得する関数である。plusInt （String,int）２２４は、第１引数で指定されたリレーショナルデータベースのコラムの値に対して第２引数で指定された整数値を加える関数である。minusInt（String,int）２２５は、第１引数で指定されたリレーショナルデータベースのコラムの値から第２引数で指定された整数値を減ずる関数である。multiplyInt （String,int）２２６は、第１引数で指定されたリレーショナルデータベースのコラムの値に対して第２引数で指定された整数値を乗ずる関数である。divideInt （String,int）２２７は、第１引数で指定されたリレーショナルデータベースのコラムの値を第２引数で指定された整数値で除する関数である。
【００４４】また、currentFloatValue（String）２２８は、２２３と同様に指定されたコラムに対する値を取得する関数であるが、その値がFloat 型の場合である。plusFloat(String,float) ２２９は、２２４と同様に指定されたコラムに第２引数の値を加える関数であるが、その加える値がFloat 型となる。整数型の２２５〜２２７に相当するFloat 型の関数も同様に存在する。また、Short,Double型等の数値に対する関数も同様にして存在する。
【００４５】尚、上記currentIntValue （String）２２３、currentFloatValue（String）２２８は、本発明におけるデータ取得手段を構成し、上記plusInt （String,int）２２４、minusInt（String,int）２２５、multiplyInt （String,int）２２６、divideInt （String,int）２２７、plusFloat(String,float) ２２９は、本発明におけるデータ演算手段を構成する。
【００４６】２０１は２２１等のUtility Bean instance のライフサイクル、及びその検索を行うことを可能にするEJBHome であるUtilityHome を示している。その中には、インスタンスの活性化を行うcreate（String）２０２、検索を行うfind（String）２０３が存在する。両者の引数はどちらもPrimary Key であるidの値を示しており、そのidをもつInstanceの活性化、検索を行う。
【００４７】２１１はUtility Bean instance ２２１のリモートインタフェースを提供するEJBObject であるUtility である。これはUtility BeanのBusiness Method である２２３〜２２９の関数のリモートインタフェースをクライアントに対して提供する。
【００４８】図２に、上記Utility Beanを利用したアプリケーション適用例を示す。このシステムはバンキングシステムである。図２において、２３１はUtility Bean、２４１はWeb ブラウザ等を利用したお客様用の口座操作画面（お客様用ブラウザ）、２５１は銀行の顧客のID、パスワード等の認証を行うための情報をもつデータベース、２６１は新規顧客口座を関設する機能、預金（例えば韓国WON の外貨預金）を追加／削除する機能をもつ、銀行側の顧客、預金管理をするためのWEB ブラウザ等を利用した操作画面（銀行メンテナンスブラウザ）、２７１はデータベース２８１に対して、預金の追加／削除、現状預金種類の把握をするためのアプリケーションである。２８１は顧客の預金データを管理するためのデータベースである。
【００４９】次に、このバンキングシステムにおけるUtility Bean２３１の利用方法について説明する。まず、銀行窓口等で新規顧客の申請（ここでは、顧客名を「松浦」と仮定する）を受けた銀行側は、銀行メンテナンスブラウザ２６１を用いて松浦を顧客管理データベース２５１に登録すると共に、UtilityHome ２０１のcreate（String）メソッドを利用して、松浦のUtility Beanインスタンスを活性化すると共に、EJBObject であるUtility を松浦用に作成する。
【００５０】一方、顧客である松浦はお客様ブラウザ２４１を用いて、まず、認証後に、口座に対するお金の入金、引落し等の処理を行う。顧客は現在サービスされている預金種類を預金listをクリックすることにより知ることができる。これは、お客様ブラウザ２４１の預金リストが預金種類管理アプリケーション２７１のcurrentIntColumns （）２７３関数を呼び出すことにより、現在の預金種別を認識することができるからである。
【００５１】また、預金種別を選択した後にその預金に対する残高を知りたい場合は、UtilityBean のリモート関数であるcurrentIntValue （String）２２３に指定した預金名がStringで指定され要求が送られることになる。同様にして、入金を行う場合は、plusInt （String,int）２２４が、引き落としを行う場合はminusInt（String,int）がそれぞれ預金の種類（String）と、額（int ）を指定して呼び出されることになる。Utility Bean２３１は、呼び出された関数と指定された引数に従い、その顧客である松浦の指定された預金に指定された額の処理を行うことになる。
【００５２】Utility Bean２３１の良さは、Stringを新預金名に指定することにより、柔軟に追加された預金に対するアクセスを行うことができることである。また、この例では銀行に対するアプリケーションに対して示したので、整数型の例を示したが、currentIntColumn（）２７３の代わりにcurrentFloatColumn（）等の関数で現在のFloat 型コラムのString配列を返すようにすれば、現状のFloat 型の型をもつコラムを認識してアクセスすることも可能である。
【００５３】このように、Utility Bean２３１は、リレーショナルデータベースで列追加／削除が行われるような状況では柔軟に対応することを可能にしているので、多くのシステムで再利用が可能になる。
【００５４】次に、本発明の実施の形態によるコンピュータ読み取り可能な記録媒体について説明する。図１、図２におけるUtility Bean２３１のプログラムを格納する記録媒体は、本実施の形態によるコンピュータ読み取り可能な記録媒体を構成する。
【００５５】この記録媒体としては、光磁気ディスク、光ディスク、半導体メモリ、磁気記録媒体等を用いることができ、これらをＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、フロッピーディスク、メモリカード等に構成して用いてよい。
【００５６】またこの記録媒体は、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部のＲＡＭ等の揮発性メモリのように、一定時間プログラムを保持するものも含まれる。
【００５７】また上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから伝送媒体を介して、あるいは伝送媒体中の伝送波により他のコンピュータシステムに伝送されるものであってもよい。上記伝送媒体とは、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体をいうものとする。
【００５８】また、上記プログラムは、前述した機能の一部を実現するためであってもよい。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００５９】従って、この記録媒体を図１、図２のシステム又は装置とは異なるシステム又は装置において用い、そのシステム又は装置のコンピュータがこの記録媒体に格納されたプログラムを実行することによっても、各実施の形態で説明した機能及び効果と同等の機能及び効果を得ることができ、本発明の目的を達成することができる。
【００６０】
【発明の効果】以上説明したように本発明によれば、リレーショナルデータベースのコラムの追加／削除に、再コンパイルの必要なく、柔軟に対応することが可能になる。また、整数型、Float 型、short 型等、各データ型に対する加減乗除の演算を備えているので、様々なリレーショナルデータベース上のアプリケーションで再利用が可能になり、汎用的で高い再利用性をもつエンタープライズJava Beansによるデータベースシステムを実現することができる。
【出願人】 【識別番号】３９９０４１１５８
【氏名又は名称】西日本電信電話株式会社
【出願日】 平成１２年１０月３日（２０００．１０．３）
【代理人】 【識別番号】１０００６４９０８
【弁理士】
【氏名又は名称】志賀 正武
【公開番号】 特開２００２−１０８６８９（Ｐ２００２−１０８６８９Ａ）
【公開日】 平成１４年４月１２日（２００２．４．１２）
【出願番号】 特願２０００−３０４１４２（Ｐ２０００−３０４１４２）