JP2015099416A - データベース連携装置及びデータベース連携プログラム - Google Patents

Abstract

【課題】ユーザによる問合せ文の作成負荷を軽減しつつ、複数のＤＢＭＳを連携して動作させることを目的とする。
【解決手段】データベース連携装置１００は、第１データベース装置２００と第２データベース装置３００とを連携させる。データベース連携装置１００は、第２データベース装置３００へ問合せ１１を発行し、問合せ１１に対する結果１２を受信する。データベース連携装置１００は、第１データベース装置２００における第１データ型と第２データベース装置３００における第２データ型との対応関係を規定した対応規則に従い、受信した結果１２の第１データ型を特定する。データベース連携装置１００は、受信した結果１２を、特定した第１データ型で出力した出力表を生成する。
【選択図】図１

Description

この発明は、複数のデータベース装置を連携させる技術に関する。

同種又は異種の複数のデータベース管理システム（以下、ＤＢＭＳ）を、仮想的に１つのＤＢＭＳとして扱いたいという要求がある。例えば、様々なＤＢＭＳにデータが分散して格納されている状況において、これらのＤＭＢＳを仮想的な１つのＤＢＭＳとして扱うことができれば、これらのデータを参照するアプリケーションの開発・構築コストの削減が可能となる。

このような要求に応えるため、データベース連携に関して様々な技術が研究されている。その中の１つとして、表値型のユーザ定義関数を用いる方法が知られる。
表値型の関数とは、単一の値ではなく、レコードから成る集合、すなわち表を返すような関数のことである。最も単純な表値型関数の例の１つとして、表名を入力として、指定された表内の全レコードを出力するという関数が考えられる。また、ユーザ定義関数とは、ＤＢＭＳが提供する機能拡張機構であり、問合せ文の中に関数呼び出しを記述することで、ユーザが定義した処理を問合せ処理の一部として実行させられる仕組みである。

表値型関数を利用してデータベース連携を実現する既存の技術として、ＰｏｓｔｇｒｅＳＱＬのｄｂｌｉｎｋがある。ＰｏｓｔｇｒｅＳＱＬのｄｂｌｉｎｋは、連携元ＤＢと連携先ＤＢが共にＰｏｓｔｇｒｅＳＱＬであるような場合のデータベース連携を実現する。ＰｏｓｔｇｒｅＳＱＬ及びｄｂｌｉｎｋについては、非特許文献１に詳細が開示されている。

表値型のユーザ定義関数を利用したデータベース連携の利点として、ＤＢＭＳの改修やミドルウェアの導入なしに、データベース連携の機能をアドオンとして気軽に享受できる点が挙げられる。ユーザ定義関数は、ＤＢＭＳが本来備えている機能拡張機構であるため、問合せ文にユーザ定義関数の呼び出しを記述しさえすれば、ＤＢＭＳを一切改修することなく、データベース連携の機能を導入することができる。

国際公開第２０１２／０９０２８０号公報

ＰｏｓｔｇｒｅＳＱＬ， ｈｔｔｐ：／／ｗｗｗ．ｐｏｓｔｇｒｅｓｑｌ．ｊｐ／ｄｏｃｕｍｅｎｔ／ｃｕｒｒｅｎｔ／ｉｎｄｅｘ．ｈｔｍｌ

表値型のユーザ定義関数を利用したデータベース連携を採用する場合、問合せ文の作成付加が増大するという課題がある。
具体的には、表値型のユーザ定義関数の戻り値である出力表の定義情報を、問合せ文の中に埋め込む必要があり、ユーザやアプリケーションによる問合せ文の作成負荷が増大する。ここで、出力表の定義情報とは、出力表に含まれる列の数、各列の名前、データ型、精度を含む情報である。

さらに、異種のＤＢＭＳを連携させる際には、データ型の対応付けを考慮しながら、出力表の定義情報を作成しなければならない。ＤＢＭＳが備えるデータ型は、一般にＤＢＭＳの種類によって異なる。そのため、ユーザは連携元ＤＢと連携先ＤＢが備えるデータ型を考慮して、両者を対応付けながら出力表の定義情報を作成する必要がある。この作業は、ユーザによる問合せ文の作成負荷をさらに増大させる。

この発明は、ユーザによる問合せ文の作成負荷を軽減しつつ、複数のＤＢＭＳを連携して動作させることを目的とする。

この発明に係るデータベース連携装置は、
第１データベース装置と第２データベース装置とを連携させるデータベース連携装置であり、
前記第２データベース装置への問合せの入力を受け付ける受付部と、
前記受付部が受け付けた問合せを、前記第２データベース装置へ発行する問合せ発行部と、
前記問合せ発行部が発行した問合せに対するデータを、前記第２データベース装置から受信するデータ受信部と、
前記第１データベース装置におけるデータ型である第１データ型と前記第２データベース装置におけるデータ型である第２データ型との対応関係を規定した対応規則を記憶する対応規則記憶部と、
前記対応規則記憶部が記憶した対応規則に従い、前記データ受信部が受信したデータの前記第１データベース装置における第１データ型を特定するデータ型特定部と、
前記データ受信部が受信したデータを、前記データ型特定部が特定した第１データ型で出力した出力表を生成する出力表生成部と
を備えることを特徴とする。

この発明に係るデータベース連携装置では、備えるデータ型の種類が異なる２つのデータベース装置を連携する際にも、連携先データベース装置と連携元データベース装置との両者のデータ型を考慮して、自動的に適切なデータ型を選択するため、ユーザの問合せ文作成負荷を軽減することが可能となる。

表値型関数を用いたデータベース連携の方法の説明図。 問合せ文１０の具体例として、ＰｏｓｔｇｒｅＳＱＬのｄｂｌｉｎｋを用いて、２つのデータベースを連携してデータを検索する例を示す図。 実施の形態１に係るデータベース連携装置１００を適用したデータベースシステム１０００の構成図。 データベース連携装置１００の動作を示すフローチャート。 対応規則記憶部１５０が記憶する対応規則の例１を示す図。 対応規則記憶部１５０が記憶する対応規則の例２を示す図。 対応規則記憶部１５０が記憶する対応規則の例３を示す図。 実施の形態１に示したデータベース連携装置１００のハードウェア構成の例を示す図。

実施の形態１．
図１は、表値型関数を用いたデータベース連携の方法の説明図である。図１では、表値型関数を用いて２つのＤＢＭＳ（第１データベース装置と第２データベース装置）を連携するシステムの構成を示す。
データベース連携装置１００は、第１データベース装置２００（以下、連携元ＤＢ）で動作する表値型のユーザ定義関数によって実現される。クライアント装置４００は、データベース連携装置１００の呼び出しを含む問合せ文１０を連携元ＤＢに発行する。この際、データベース連携装置１００である表値型関数の引数には、第２データベース装置３００（以下、連携先ＤＢ）への問合せ文１１が文字列として渡される。表値型関数は、連携先ＤＢのクライアントとして動作し、問合せ文１１を連携先ＤＢへ発行する。表値型関数は、関数の戻り値として連携先ＤＢの検索結果（結果１２）を表として受け取り、連携元ＤＢへ返す。連携元ＤＢは、受け取った表を加工したり、連携元ＤＢ自身が持つ表と結合したりして、クライアント装置４００に結果１３を返す。

図２は、問合せ文１０の具体例として、ＰｏｓｔｇｒｅＳＱＬのｄｂｌｉｎｋを用いて、２つのデータベースを連携してデータを検索する例を示す図である。
ＰｏｓｔｇｒｅＳＱＬのｄｂｌｉｎｋでは、関数ｄｂｌｉｎｋ（）の第１引数には連携先ＤＢの名前を指定し、第２引数に連携先ＤＢへの問合せ文１１を指定する。

ここで、関数ｄｂｌｉｎｋ（）の戻り値である出力表の定義情報は、問合せ文１１が与えられることで初めて決定される。すなわち、関数ｄｂｌｉｎｋ（）の戻り値の定義情報は、具体的な問合せ文が与えられるまで決定できないという特徴がある。一方で、一般に、定義情報が与えられないと、データベース装置は与えられた問合せに対する実行プランを作成することができない。そのため、問合せ文１０では、関数ｄｂｌｉｎｋ（）の呼び出し直後に、ＡＳ句の中で出力表の定義情報を与えている。
図２の例では、ｄｂｌｉｎｋ（）の戻り値は、ｔｅｘｔ型のｎａｍｅという列と、ｉｎｔｅｇｅｒ型のａｇｅという列との２列から成る表である。なお、ＡＳ句によって出力表の定義情報を与える記述方法はＰｏｓｔｇｒｅＳＱＬのＳＱＬ構文規則によるものである。

このように、関数の戻り値の定義情報を問合せ文に記述しなければならないことは、ユーザによる問合せ文作成負荷を増大させる。図２の例では、高々２列の定義情報を記述するだけであるが、表値型関数が１，０００列の表を返すような問合せ文を作成する場合、１，０００列分の定義情報を問合せ文に記述しなければならない。

適切なデータ型の対応付けが必要となる具体例を説明する。
連携元ＤＢがＯｒａｃｌｅ Ｄａｔａｂａｓｅ １１ｇ Ｒｅｌｅａｓｅ ２（以下、Ｏｒａｃｌｅ（登録商標））である場合を考える。Ｏｒａｃｌｅ（登録商標）には、可変長文字列型としてＶＡＲＣＨＡＲ２型とＣＬＯＢ型を含む複数の型が用意されている。ＶＡＲＣＨＡＲ２型には、扱える文字列の最大長が４，０００バイトという制限がある。一方で、ＣＬＯＢ型は、最大長制限が４ＧＢと大幅に緩和されるが、速度性能が低下する場合があるという特徴を持つ。このように、ＶＡＲＣＨＡＲ２型とＣＬＯＢ型には扱える文字列長と速度性能のトレードオフがあるため、ユーザは、連携先ＤＢから返却される文字列長に応じて、本トレードオフを考慮した適切なＯｒａｃｌｅ（登録商標）のデータ型を選択する必要がある。具体的には、連携先ＤＢから返却される文字列長が４，０００バイト以下と分かる場合にはＶＡＲＣＨＡＲ２型を選択し、４，００１バイト以上のデータが返却される可能性がある場合には、ＣＬＯＢ型を選択する等の判断がユーザに求められる。

なお、異種ＤＢＭＳ間でデータを連携させる技術は、例えば特許文献１に示すように、スキーママッチングの分野で研究されている。特許文献１には、既知の表に既知の形式でデータが格納されている場合に、その格納形式が異なる表の間でのデータ形式変換を容易化するという効果がある。しかしながら、表値型関数を用いたデータベース連携においては、連携したい表が動的に定まるため、特許文献１では、上記のような課題を解決することはできない。

図３は、実施の形態１に係るデータベース連携装置１００を適用したデータベースシステム１０００の構成図である。
データベースシステム１０００は、データベース連携装置１００、第１データベース装置２００、第２データベース装置３００、クライアント装置４００を備える。図３では、データベース連携装置１００は、第１データベース装置２００と第２データベース装置３００を連携するための装置であり、第１データベース装置２００の部分装置として適用される。クライアント装置４００はネットワーク５００を介して第１データベース装置２００と接続されている。ユーザはクライアント装置４００を通して、第１データベース装置２００へアクセスする。

クライアント装置４００は、ユーザの要求に応じて問合せ文１０１を生成し、第１データベース装置２００へ問合せ文１０１を発行する。問合せ文１０１を記述するデータベース言語は、例えば、標準ＳＱＬや、各データベース管理システムで独自に拡張されたＳＱＬが挙げられるが、これらの言語に限定されるものではない。

データベース連携装置１００は、第１データベース装置２００で動作する表値型のユーザ定義関数で実現される。問合せ文１０１を記述するデータベース言語がＳＱＬである場合、問合せ文１０１に記述される関数はＳＱＬ関数と呼ばれる。問合せ文１０１内にデータベース連携装置１００を呼び出す命令が記述されている場合、第１データベース装置２００は、データベース連携装置１００を起動する。

データベース連携装置１００の構成の詳細を説明する。データベース連携装置１００は、受付部１１０、問合せ発行部１２０、データ受信部１３０、出力表生成部１４０、対応規則記憶部１５０、データ型特定部１６０、出力部１７０を備える。

受付部１１０は、データベース連携装置１００への関数の引数として渡された第２データベース装置３００への問合せ文１０２を受け付ける。データベース連携装置１００へ問合せ文１０２を渡す方法として、文字列型の関数引数として渡す方法が一般的であるが、任意の渡し方が可能である。
また、受付部１１０は、問合せ文１０２以外の任意のパラメータ１０３を受け取ることが可能である。パラメータ１０３は、関数の引数として渡されても良いし、関数内部で直接取得されても良い。パラメータ１０３の例については後述する。

問合せ発行部１２０は、受付部１１０で受け付けた問合せ文１０２を、第２データベース装置３００へ発行する。問合せ発行部１２０は、第２データベース装置３００が提供するＡＰＩによって実現される。
第２データベース装置３００が提供するＡＰＩとしては、例えば、ＯＤＢＣ（Ｏｐｅｎ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ）、ＪＤＢＣ（Ｊａｖａ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ）のようにある程度標準化されたものが良く知られるが、任意のＡＰＩを利用可能である。

データ受信部１３０は、問合せ発行部１２０によって発行された問合せの実行結果のデータを、第２データベース装置３００から受信する。受信した実行結果の中には、実行結果を構成する表の定義情報（以下、第２定義情報）が含まれる。実行結果を構成する表は、第２データベース装置３００から出力された表であるから、第２定義情報で定義されているデータ型は第２データベース装置３００におけるデータ型（以下、第２データ型）である。
データ受信部１３０もまた、問合せ発行部１２０と同様に、第２データベース装置３００が提供するＡＰＩによって実現される。

出力表生成部１４０は、データ受信部１３０で受け取った実行結果を元に、データベース連携装置１００の戻り値である出力表１０４を生成する。
出力表１０４の最も単純な例として、データ受信部１３０で受け取った実行結果のデータの表構造を変えずに、第１データベース装置２００が備えるデータ型にキャストしただけの表を考えることができる。もう少し複雑な例としては、データベース連携装置１００への入力である問合せ文１０２及びパラメータ１０３と、データ受信部１３０で受け取った実行結果のデータとから計算可能な値を、出力表１０４に含めるようなものを考えることができる。

対応規則記憶部１５０は、第２データベース装置３００が備える第２データ型、及び、データ長を含む定義情報に対し、第１データベース装置２００が備えるデータ型（以下、第１データ型）を対応付けた対応規則を記憶した記憶装置である。

データ型特定部１６０は、出力表生成部１４０で作成する出力表１０４の定義情報（以下、第１定義情報）を特定する。
データ型特定部１６０の入力として、データ受信部１３０で受け取った第２定義情報を用いる。あるいは、データ型特定部１６０の入力として、受付部１１０で受け取った問合せ文１０２を直接的に用いる。

出力部１７０は、出力表生成部１４０によって作成された出力表１０４を出力し、第１データベース装置２００へ返却する。

図４は、データベース連携装置１００の動作を示すフローチャートである。
データベース連携装置１００が第１データベース装置２００によって起動されると、受付部１１０は、問合せ文１０２及びパラメータ１０３を受け付ける（Ｓ１１０）。パラメータ１０３には複数個のパラメータが含まれてもよいし、パラメータが全く含まれなくてもよい。問合せ発行部１２０は、Ｓ１１０で受け付けた問合せ文１０２を第２データベース装置３００へ発行する（Ｓ１２０）。
データ受信部１３０は、第２データベース装置３００からＳ１２０で発行した問合せ文１０１の実行結果のデータに関する第２定義情報を受信する（Ｓ１３０）。データ型特定部１６０は、Ｓ１３０で取得した第２定義情報と、パラメータ１０３と、対応規則記憶部１５０が記憶した対応規則とに基づき、出力表１０４の第１定義情報を作成する（Ｓ１４０）。

次に、第２データベース装置３００から問合せ文１０２の実行結果のデータをレコード毎にフェッチして、出力表１０４に出力する（Ｓ１５０〜Ｓ１８０）。具体的には、未フェッチのレコードが存在すれば（Ｓ１５０でＹＥＳ）、データ受信部１３０は、次のレコードをフェッチし（Ｓ１６０）、出力表生成部１４０は、出力表１０４に１レコード分の領域を作成し（Ｓ１７０）、出力部１７０は、ステップＳ１７０で作成した出力表１０４に１レコード分のデータを出力する（Ｓ１８０）。そして、ステップＳ１５０に戻る。一方、未フェッチのレコードが存在しなければ（Ｓ１５０でＮＯ）、データベース連携装置１００は処理を終了する。

続いて、対応規則記憶部１５０が記憶する対応規則の具体例を交えて、Ｓ１４０の動作の詳細を説明する。

（例１）
図５は、対応規則記憶部１５０が記憶する対応規則の例１を示す図である。
例１は、対応する第１データベース装置２００としてＯｒａｃｌｅ Ｄａｔａｂａｓｅ １１ｇ Ｒｅｌｅａｓｅ ２（以下、Ｏｒａｃｌｅ（登録商標））を、第２データベース装置３００としてＰｏｓｔｇｒｅＳＱＬ９．２（以下、ＰｏｓｔｇｒｅＳＱＬ）を想定している。
但し、これらの想定は本質ではなく、重要なのは、ＰｏｓｔｇｒｅＳＱＬの可変長文字列型（ｃｈａｒａｃｔｅｒ ｖａｒｙｉｎｇ， ｖａｒｃｈａｒ， ｔｅｘｔ）、及びバイナリ型（ｂｙｔｅａ）には、文字列長制限が無いのに対し、Ｏｒａｃｌｅ（登録商標）の対応するデータ型には、文字列長の制限が存在する場合があることである。具体的には、Ｏｒａｃｌｅ（登録商標）の可変長文字列型であるＶＡＲＣＨＡＲ２型には最大長４，０００バイトの制限があるが、同じく可変長文字列型であるＣＬＯＢ型は最大長の制限が大幅に緩和される。しかしながら、ＣＬＯＢ型は速度性能の面でＶＡＲＣＨＡＲ２型に劣っている。バイナリ型も同様であり、Ｏｒａｃｌｅ（登録商標）のＲＡＷ型には最大長２，０００バイトの制限があるが、ＢＬＯＢ型はより大きなバイナリ列を扱える反面、速度性能の面でＲＡＷ型に劣っている。

このような特性を考慮し、図５に示すような対応規則では、可変長文字列型とバイナリ型とについて、第２データ型に対して、データ長毎に第１データ型を対応付けている。これにより、可変長文字列型とバイナリ型について、データが欠落しない範囲において、速度性能が有利となるようなデータ型を選択するようにしている。
このような対応規則を用いることで、ユーザは可変長文字列型やバイナリ列型の長さを意識して、明示的に問合せ文に記述することなく、常に最適なデータ型を選択することが可能となる。

（例２）
図６は、対応規則記憶部１５０が記憶する対応規則の例２を示す図である。
例２は、図５に示す例１と類似しているが、データ型の選択にパラメータ１０３の利用を取り入れた点が異なっている。
例２では、パラメータ１０３として、ｍｏｄｅ（データ型特定条件の一例）というパラメータが含まれる状況を想定している。ｍｏｄｅは、「速度優先」と「精度優先」との２値を取るパラメータである。「速度優先」が指定された場合には、速度性能が優先され、「精度優先」が指定された場合に、データの欠落が無いことが優先されるように、対応規則は設定さている。
具体的には、「速度優先」が指定された場合には、ＶＡＲＣＨＡＲ２やＲＡＷなど、速度性能が有利なデータ型が選択される。もし「速度優先」が指定された場合に、ＶＡＲＣＨＡＲ２やＲＡＷでは扱えない長さのデータが出現すれば、最大長以降のデータを無視するなどし、データを一部欠落させる。一方、「精度優先」が指定された場合には、データの欠落が生じない範囲で、最も速度性能が有利となるデータ型を選択する。例２では、「精度優先」が指定された際の動作は、図５に示す対応規則を用いた動作と同等となる。

図６に示すような対応規則を用いることで、ユーザは速度性能と精度とのトレードオフを簡単に選択することが可能となる。

（例３）
図７は、対応規則記憶部１５０が記憶する対応規則の例３を示す図である。
例３は、第２データベース装置３００から返される１つの列に対し、第１データベース装置２００で複数の列を割り当てる例となっている。図７に示す例では、タイムスタンプ型とバイナリ型について、それぞれ複数列に割り当てる例を示している。

図７に示すような対応規則を用いることで、通常はクライアント装置４００にて実装すべきデータ加工処理の一部を、データベース連携装置１００に組み込むことができ、アプリケーションの開発コストを低減させることができる。

以上で述べたように、実施の形態１に係るデータベース連携装置１００は、データ型特定部１６０を備え、データ型の対応規則を用いて出力表１０４のデータ型を特定する。そのため、出力表１０４のデータ型を問合せ文１０１に記述することなく、データベース連携装置１００を利用可能となる。
特に、備えるデータ型の種類が異なる２つのデータベース装置を連携する際にも、両者のデータ型を考慮して対応規則を設定することにより、自動的に最適なデータ型を選択するようことが可能となる。その結果、ユーザの問合せ文１０１の作成負荷を軽減することが可能となる。

図８は、実施の形態１に示したデータベース連携装置１００のハードウェア構成の例を示す図である。
データベース連携装置１００はコンピュータであり、データベース連携装置１００の各要素をプログラムで実現することができる。
データベース連携装置１００のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。

演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等である。外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置等である。主記憶装置９０３は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等である。通信装置９０４は、例えば通信ボード等である。入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。

プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、受付部１１０、問合せ発行部１２０、データ受信部１３０、出力表生成部１４０、対応規則記憶部１５０、データ型特定部１６０、出力部１７０として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、上記プログラムを実行する。
また、実施の形態１の説明において、「〜の受け付け」、「〜の発行」、「〜の受信」、「〜の生成」、「〜の特定」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。

なお、図８の構成は、あくまでも各装置のハードウェア構成の一例を示すものであり、各装置のハードウェア構成は図８に記載の構成に限らず、他の構成であってもよい。

１００ データベース連携装置、１０１，１０２ 問合せ文、１０３ パラメータ、１０４ 出力表、１１０ 受付部、１２０ 問合せ発行部、１３０ データ受信部、１４０ 出力表生成部、１５０ 対応規則記憶部、１６０ データ型特定部、１７０ 出力部、２００ 第１データベース装置、３００ 第２データベース装置、４００ クライアント装置、１０，１１ 問合せ文、１２，１３ 結果。

Claims (7)

1. 第１データベース装置と第２データベース装置とを連携させるデータベース連携装置であり、
   前記第２データベース装置への問合せの入力を受け付ける受付部と、
   前記受付部が受け付けた問合せを、前記第２データベース装置へ発行する問合せ発行部と、
   前記問合せ発行部が発行した問合せに対するデータを、前記第２データベース装置から受信するデータ受信部と、
   前記第１データベース装置におけるデータ型である第１データ型と前記第２データベース装置におけるデータ型である第２データ型との対応関係を規定した対応規則を記憶する対応規則記憶部と、
   前記対応規則記憶部が記憶した対応規則に従い、前記データ受信部が受信したデータの前記第１データベース装置における第１データ型を特定するデータ型特定部と、
   前記データ受信部が受信したデータを、前記データ型特定部が特定した第１データ型で出力した出力表を生成する出力表生成部と
   を備えることを特徴とするデータベース連携装置。
2. 前記受付部は、前記第１データベース装置に対する問合せの一部として含まれる前記第２データベース装置への問合せの入力を受け付け、
   前記データベース連携装置は、さらに、
   前記出力表生成部が生成した出力表を前記第１データベース装置へ出力する出力部
   を備えることを特徴とする請求項１に記載のデータベース連携装置。
3. 前記データ受信部は、データを、そのデータの第２データ型とともに受信し、
   前記データ型特定部は、前記対応規則に従い、前記データ受信部が受信した第２データ型に対応する第１データ型を特定する
   ことを特徴とする請求項１又は２に記載のデータベース連携装置。
4. 前記対応規則は、第２データ型に対して、データ長毎に第１データ型を対応付けており、
   前記データ型特定部は、前記データ受信部が受信したデータの第２データ型及びデータ長に対応する第１データ型を特定する
   ことを特徴とする請求項１から３までのいずれかに記載のデータベース連携装置。
5. 前記対応規則は、第２データ型に対して、データ型特定条件毎に第１データ型を対応付けており、
   前記受付部は、データ型特定条件を含む問合せの入力を受け付け、
   前記データ型特定部は、前記データ受信部が受信したデータの第２データ型と、前記受付部が受け付けた問合せに含まれるデータ型特定条件とに対応する第１データ型を特定する
   ことを特徴とする請求項１から３までのいずれかに記載のデータベース連携装置。
6. 前記対応規則は、第２データ型に対して、複数の第１データ型を対応付けており、
   前記データ型特定部は、前記データ受信部が受信したデータの第２データ型に対応する複数の第１データ型を特定し、
   前記出力表生成部は、前記データ受信部が受信したデータを、前記データ型特定部が特定した各第１データ型で出力した出力表を生成する
   ことを特徴とする請求項１から３までのいずれかに記載のデータベース連携装置。
7. 第１データベース装置と第２データベース装置とを連携させるデータベース連携プログラムであり、
   前記第２データベース装置への問合せの入力を受け付ける受付処理と、
   前記受付処理で受け付けた問合せを、前記第２データベース装置へ発行する問合せ発行処理と、
   前記問合せ発行処理で発行した問合せに対するデータを、前記第２データベース装置から受信するデータ受信処理と、
   記憶装置に記憶された対応規則であって、前記第１データベース装置におけるデータ型である第１データ型と前記第２データベース装置におけるデータ型である第２データ型との対応関係を規定した対応規則に従い、前記データ受信処理で受信したデータの前記第１データベース装置における第１データ型を特定するデータ型特定処理と、
   前記データ受信処理で受信したデータを、前記データ型特定処理で特定した第１データ型で出力した出力表を生成する出力表生成処理と
   をコンピュータに実行させることを特徴とするデータベース連携プログラム。
   
   

Images