(57)【特許請求の範囲】
【請求項１】
サーバと、複数の列を含む１以上のテーブルが格納された第１の記憶装置と、前記テーブルへのインポート対象データを有するインポートファイルを格納するための第２の記憶装置を備え、
前記サーバは、前記テーブルのテーブル名と、前記テーブルへのインポート対象データを有するインポートファイルのファイル名及び処理状態とを対応付けて記録するための、データファイル管理表を管理しており、
前記サーバは検索要求を受け付けると、
前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有し、かつ前記テーブルへのインポート処理が完了していないインポートファイルであるインポート未完了ファイルが、前記第２の記憶装置に存在するか判定し、
前記インポート未完了ファイルが存在しない場合、前記検索要求で指定されたデータを前記テーブルの中から検索し、
前記インポート未完了ファイルが存在する場合、前記検索要求で指定されたデータを前記テーブルの中から検索するとともに、前記インポート未完了ファイルの中からも前記検索要求で指定されたデータを検索し、
前記サーバは、前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有するインポート未完了ファイルが、前記第２の記憶装置に存在する場合、
前記検索要求で指定された条件に該当するレコードを前記テーブルから検索する、第１の部分クエリを生成し、
前記インポート未完了ファイルから前記検索要求で指定された条件に該当するレコードを検索するクエリである、第２の部分クエリを生成し、
前記第１及び第２の部分クエリの出力結果の和集合を求めるクエリを生成し、
前記クエリに係る処理を実行し、
前記サーバは、前記第２の記憶装置に新たなインポートファイルが格納されたことを検出した時、前記インポートファイルのファイル名を前記データファイル管理表に記録するとともに、前記インポートファイルの前記処理状態がインポート未完了である旨を記録し、
前記インポートファイルのインポート処理が完了した時で、前記データファイル管理表に前記インポートファイルの前記処理状態がインポート完了状態である旨を記録し、
前記サーバは、前記第２の部分クエリを生成する時、
前記データファイル管理表の中から、前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有する前記インポートファイルのうち、前記処理状態がインポート未完了である前記インポートファイルを検索する第３の部分クエリを生成し、
前記第２の部分クエリとして、前記第３の部分クエリを含む部分クエリを生成する、
データ処理システム。
【請求項２】
前記第２の部分クエリは、前記インポート未完了ファイルから前記テーブルの形式のデータを出力するための表関数を含む、
請求項１に記載のデータ処理システム。
【請求項３】
前記サーバは、前記生成されたクエリを解析して、少なくとも前記第１の部分クエリに係るタスクと前記第２の部分クエリに係るタスクを生成し、前記生成されたタスクを並列実行する、
請求項１に記載のデータ処理システム。
【請求項４】
前記サーバは検索要求を受け付けた時に、前記第２の記憶装置に新たなインポートファイルが格納されたか否かを判定する、
請求項１に記載のデータ処理システム。
【請求項５】
複数の列を含む１以上のテーブルが格納された第１の記憶装置と、前記テーブルへのインポート対象データを有するインポートファイルを格納するための第２の記憶装置と、を備えるデータ処理システムにおいて、  前記データ処理システムは、前記テーブルのテーブル名と、前記テーブルへのインポート対象データを有するインポートファイルのファイル名及び処理状態とを対応付けて記録するための、データファイル管理表を管理しており、  前記データ処理システムが、ａ）  検索要求を受け付ける工程と、ｂ）  前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有し、かつ前記テーブルへのインポート処理が完了していないインポートファイルであるインポート未完了ファイルが、前記第２の記憶装置に存在するか判定する工程と、ｃ−１）  前記インポート未完了ファイルが存在しない場合、前記検索要求で指定されたデータを前記テーブルの中から検索する工程と、ｃ−２）  前記インポート未完了ファイルが存在する場合、前記検索要求で指定されたデータを前記テーブルの中から検索するとともに、前記インポート未完了ファイルの中からも前記検索要求で指定されたデータを検索する工程と、を実行し、  前記工程ｃ−２）において、前記データ処理システムは、  前記検索要求で指定された条件に該当するレコードを前記テーブルから検索する、第１の部分クエリを生成し、  前記インポート未完了ファイルから前記検索要求で指定された条件に該当するレコードを検索するクエリである、第２の部分クエリを生成し、  前記第１及び第２の部分クエリの出力結果の和集合を求めるクエリを生成し、  前記クエリに係る処理を実行し、  前記データ処理システムがさらに、  ア）  前記第２の記憶装置に新たなインポートファイルが格納されたことを検出する工程と、  イ）  前記工程ア）において新たなインポートファイルが格納されたことを検出した時、前記インポートファイルのファイル名を前記データファイル管理表に記録するとともに、前記インポートファイルの前記処理状態がインポート未完了である旨を記録する工程と、  ウ）  前記インポートファイルのインポート処理が完了した時で、前記データファイル管理表に前記インポートファイルの前記処理状態がインポート完了状態である旨を記録する工程と、を実行し、  前記データ処理システムは前記第２の部分クエリを生成する時、  前記データファイル管理表の中から、前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有する前記インポートファイルのうち、前記処理状態がインポート未完了である前記インポートファイルを検索する第３の部分クエリを生成し、  前記第２の部分クエリとして、前記第３の部分クエリを含む部分クエリを生成する、データ処理システムのデータ検索方法。
【請求項６】
前記第２の部分クエリは、前記インポート未完了ファイルから前記テーブルの形式のデータを出力するための表関数を含む、
請求項５に記載のデータ処理システムのデータ検索方法。
【請求項７】
前記工程ア）及びイ）は、前記工程ａ）と前記工程ｂ）の間に実行される、
請求項５に記載のデータ処理システムのデータ検索方法。
【請求項８】
複数の列を含む１以上のテーブルが格納された第１の記憶装置と、前記テーブルへのインポート対象データを有するインポートファイルを格納するための第２の記憶装置と、を備えるデータ処理システムであって、
前記データ処理システムは、前記テーブルのテーブル名と、前記テーブルへのインポート対象データを有するインポートファイルのファイル名及び処理状態とを対応付けて記録するための、データファイル管理表を管理しており、
前記データ処理システムのプロセッサに、
ａ）  検索要求を受け付ける工程と、
ｂ）  前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有し、かつ前記テーブルへのインポート処理が完了していないインポートファイルであるインポート未完了ファイルが、前記第２の記憶装置に存在するか判定する工程と、
ｃ−１）  前記インポート未完了ファイルが存在しない場合、前記検索要求で指定されたデータを前記テーブルの中から検索する工程と、
ｃ−２）  前記インポート未完了ファイルが存在する場合、前記検索要求で指定されたデータを前記テーブルの中から検索するとともに、前記インポート未完了ファイルの中からも前記検索要求で指定されたデータを検索する工程と、
を実行させ、
前記工程ｃ−２）において、前記プロセッサに、
前記検索要求で指定された条件に該当するレコードを前記テーブルから検索する、第１の部分クエリを生成させ、
前記インポート未完了ファイルから前記検索要求で指定された条件に該当するレコードを検索するクエリである、第２の部分クエリを生成させ、
前記第１及び第２の部分クエリの出力結果の和集合を求めるクエリを生成させ、
前記クエリに係る処理を実行させ、
更に前記プロセッサに、
ア）  前記第２の記憶装置に新たなインポートファイルが格納されたことを検出する工程と、
イ）  前記工程ア）において新たなインポートファイルが格納されたことを検出した時、前記インポートファイルのファイル名を前記データファイル管理表に記録するとともに、前記インポートファイルの前記処理状態がインポート未完了である旨を記録する工程と、
ウ）  前記インポートファイルのインポート処理が完了した時で、前記データファイル管理表に前記インポートファイルの前記処理状態がインポート完了状態である旨を記録する工程と、を実行させ、
前記プロセッサは前記第２の部分クエリを生成する時、
前記データファイル管理表の中から、前記検索要求で検索対象とされている前記テーブルへのインポート対象データを有する前記インポートファイルのうち、前記処理状態がインポート未完了である前記インポートファイルを検索する第３の部分クエリを生成し、
前記第２の部分クエリとして、前記第３の部分クエリを含む部分クエリを生成する、
プログラムを記録した、コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システムに関する。
【背景技術】
【０００２】
近年、プラント設備などに設けられたセンサから得られるセンサ計測値や、金融分野における株価や為替等の、多量の時系列データに対する解析を行うことにより、診断や予測を行うビッグデータ解析が活発に行われている。このようなビッグデータ解析においては、時々刻々と更新される多量の時系列データが絶え間なく収集され、収集されたデータを用いた解析が行われる。【０００３】
ビッグデータ解析に用いられるデータは、いわゆるデータベース管理システム（ＤＢＭＳ）で管理されることが多い。ＤＢＭＳ、特にリレーショナルデータベース管理システム（ＲＤＢＭＳ）においては、複数のデータは「テーブル」と呼ばれる表形式の情報として管理される。ただし、データがＤＢＭＳで管理されるより前には、たとえばデータがセンサ等から取得された直後の時点においては、テキストファイル等の一般的なファイルの形式で、記憶装置に保存されることが一般的である。【０００４】
多くのＤＢＭＳでは、ファイルに格納されている複数のデータを、ＤＢＭＳで管理するテーブルに格納するための機能をユーザに提供している。以下ではこの機能のことを「インポート機能」と呼ぶ。ユーザはインポート機能を用いることで、テーブルに１レコードずつデータを挿入する作業を行う必要がなくなり、ファイル内のデータを一括してテーブルに格納する（「インポートする」と呼ばれる）ことができる。【０００５】
インポート中に、テーブル内のデータにアクセスできない場合、ユーザはその間解析等の業務を実行できなくなる。特にファイル内のデータが多量にある時、インポートに長時間を要するため、業務を実行できない期間が長期化することになる。そのような問題を解決するために、ＤＢＭＳによっては、テーブルへの検索要求を受け付けながら、データのインポートを可能にする技術（以下、“バックグラウンドインポート機能”と呼ぶ）をサポートしているものもある（非特許文献１）。バックグラウンドインポート機能を用いることにより、ユーザはインポート中であっても、テーブルにアクセスすることができるようになる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Hitachi Advanced Data Binder Setup and Operation Guide [online], Hitachi Ltd., (http://itdoc.hitachi.co.jp/manuals/3000/3000650150e/A0650150.PDF)
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ビッグデータ解析においては、多量の時系列データをリアルタイムに収集し解析することが求められている。バックグラウンドインポート機能を用いると、ファイルのデータをテーブルにインポートしている間でも、ユーザはテーブル内データの検索は可能だが、インポート中のファイルに記録されているデータに対する検索を行うことはできない。そのためユーザは、ファイルに記録されているデータに対する解析を行うためには、インポート処理が完了するまで待たなければならない。
【課題を解決するための手段】
【０００８】
本発明の一実施形態に係るデータ処理システムは、１以上のテーブルを管理し、該テーブルに対する検索要求を受け付けるとともに、ファイルに記録されたデータをテーブルへインポート可能に構成されている。データ処理システムは、テーブルに対するデータ検索要求を受け付けると、該テーブルに対するインポート対象のデータを記録しているファイルの有無を確認し、インポート未完了のファイルがない場合は、テーブル内から検索要求で指定されたデータを検索し、インポート未完了のファイルがある場合には、検索要求で指定されたデータをテーブルの中から検索するとともに、ファイルに対しても検索要求で指定されたデータの検索を行う。
【発明の効果】
【０００９】
本発明によれば、データのインポート完了を待たずに、即座にデータにアクセスすることができる。
【図面の簡単な説明】
【００１０】
【図１】データ処理システムの構成図である。
【図２】検索対象データの格納されるテーブルの一例である。
【図３】インポートファイルのフォーマットの一例である。
【図４】サーバの機能ブロック図である。
【図５】ディクショナリの一例である。
【図６】ディクショナリの一例（２）である。
【図７】データファイル管理表の一例である。
【図８】ファイル監視処理のフローチャートである。
【図９】ファイル更新チェック処理のフローチャートである。
【図１０】インポート処理のフローチャートである。
【図１１】バックグラウンドインポート機能の概念図である。
【図１２】検索処理のフローチャートである。
【図１３】書き換え前クエリの一例である。
【図１４】部分クエリ２の例である。
【図１５】書き換え後のクエリの例である。
【図１６】クエリ書き換え処理のフローチャートである。
【図１７】書き換え前のクエリの一般化例である。
【図１８】書き換え後のクエリの一般化例である。
【図１９】実施例２におけるクエリ書き換え処理で生成される部分クエリ２の例である。
【図２０】実施例２におけるクエリ書き換え処理のフローチャートである。
【図２１】実施例３における検索処理のフローチャートである。
【図２２】実施例１または２と、実施例３との比較図である。
【図２３】テーブルにインポートファイルのデータを格納するためのＳＱＬクエリの例である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施例について、図面を用いて説明する。なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
【実施例１】
【００１２】
（１）  システム構成
図１は、本発明の実施例に係るデータ処理システムのハードウェア構成を示す図である。データ処理システムは、データベースサーバ１（以下、「サーバ１」あるいは「ＤＢサーバ１」と略記する）、クライアント２、記憶装置３，４を有する。サーバ１とクライアント２は、例えばイーサネット（Ｅｔｈｅｒｎｅｔ）を用いて構成されたローカルエリアネットワーク（ＬＡＮ）６を介して、相互通信可能に接続される。サーバ１は、たとえばファイバチャネル（ＦｉｂｒｅＣｈａｎｎｅｌ）を用いて構成されたネットワーク５（またはＳＡＮ５と呼ばれる）を介して、記憶装置３，４と接続される。【００１３】
サーバ１は、データ処理システムの利用者（以下、「ユーザ」と呼ぶ）から受領した、データベースへのアクセスリクエストの処理を行うコンピュータで、ＣＰＵ１１、メモリ１２、ＬＡＮ６に接続するためのネットワークポート１３、入出力デバイス１４、ストレージポート１６を有する。メモリ１２はたとえばＤＲＡＭ等の記憶デバイスで、ＣＰＵ１１がプログラムを実行する時に、そのプログラムまたはプログラムの実行時に用いられる制御情報等を格納するために用いられる。ＣＰＵ１１はデータベースアクセス処理を実施するためのプログラムを実行するコンポーネントである。本実施例に係るデータ処理システムにおいて、サーバ１はいわゆるＳＭＰ（Ｓｙｍｍｅｔｒｉｃ  Ｍｕｌｔｉ  Ｐｒｏｃｅｓｓｏｒｉｎｇ）サーバで、複数のＣＰＵ１１を有し、各ＣＰＵ１１が並列に処理を実行することができるよう、構成されていてよい。なお、サーバ１内に複数のＣＰＵ１１を設ける代わりに、サーバ１内にいわゆる複数のプロセッサコアを有するマルチコアプロセッサが１つ（または複数）設けられる構成でも良い。【００１４】
入出力デバイス１４はたとえば、キーボードやマウスなどの、ユーザが情報入力を行う際に用いるデバイスと、ディスプレイやプリンタ等の表示（出力）デバイスを含む。ストレージポート１６は、サーバ１と記憶装置３を接続するためのインタフェースである。【００１５】
クライアント２は、ユーザがサーバ１に対してデータベースへの参照更新要求を発行したり、サーバ１から返送される処理結果の出力を受領したりするために用いられるコンピュータである。クライアント２は、ＣＰＵ２１、メモリ２２、ＬＡＮ６に接続するためのネットワークポート２３、入出力デバイス２４を有する。ＣＰＵ２１、メモリ２２、ネットワークポート２３、入出力デバイス２４はそれぞれ、サーバ１のＣＰＵ１１、メモリ１２、ネットワークポート１３、入出力デバイス１４と同様のものである。またクライアント２は、メモリ２２の他に、磁気ディスクなどの補助記憶装置を備えていてもよい。【００１６】
記憶装置３，４は、磁気ディスク等の不揮発性記憶デバイスを有する装置で、データベース３１やインポートファイル３２を格納するための装置である。記憶装置３，４は、いわゆるディスクアレイ（またはＲＡＩＤ）のように、複数の不揮発性記憶デバイスを有する装置であってもよい。記憶装置３は、ＳＡＮ５を介してサーバ１のストレージポート１６に接続される。【００１７】
本実施例に係るデータ処理システムは、外部のデータソース８で生成されたデータを収集し、管理する。データソース８はたとえば、プラント設備などに設けられたセンサを含む装置で、ワイドエリアネットワーク（ＷＡＮ）７、ＬＡＮ６を介してサーバ１に接続される。図１ではデータソース８が１つだけ存在するが、データソース８は複数存在してもよい。【００１８】
データソース８は、センサによって計測された情報を多数格納したファイルを作成し、作成されたファイルをサーバ１に送信する機能を有する。サーバ１に送られてきたファイルは、一旦記憶装置４に格納され、ファイルに記録されている情報はその後、記憶装置３にあるテーブル３００に書き込まれる（インポートされる）。テーブル３００は、データベース管理プログラム１２０（後述）によって作成されるデータ構造である。本実施例では、データソース８から送られてくるファイルのことを、「インポートファイル」と呼ぶ（図１の、インポートファイル３２）。本実施例では、インポートファイル３２の格納される記憶装置４と、テーブル３００を格納する記憶装置３とは別の記憶装置である例を説明するが、テーブル３００とインポートファイル３２とが、同一の記憶装置３（または記憶装置４）に格納される構成が採用されてもよい。【００１９】
サーバ１のメモリ１２には、サーバ１で実行されるプログラムや、プログラムが使用する制御情報が格納される。サーバ１で実行されるプログラムとしては、たとえばデータベース管理プログラム１２０、ファイルシステムプログラム１２１、ＯＳ１２２、データ収集プログラム１２３がある。【００２０】
ＯＳ１２２は、サーバ１上で実行される各種プログラムのスケジュール制御を行うプログラムである。また本実施例に係るＯＳ１２２は、抽象化されたハードウェアリソースを各種プログラムに提供する処理を行うプログラムであるデバイスドライバを含んでもよい。【００２１】
ファイルシステムプログラム１２１は、ファイルを記憶装置４等に格納して管理するプログラムである。本実施例ではファイルシステムプログラム１２１は主に、記憶装置４に格納されるインポートファイル３２に対するアクセスを行い、データベース３１へのアクセスが行われる時には、ファイルシステムプログラム１２１は用いられない。ただし別の実施形態として、ファイルシステムプログラム１２１が作成したファイルシステム（ファイルを格納・管理するためのデータ構造）の上にデータベース３１を格納するように構成されてもよい。【００２２】
データベース管理プログラム１２０は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）と呼ばれることもあるプログラムで、「テーブル」と呼ばれる一種の表形式のデータ構造を作成し、テーブルにデータを格納して管理する。本実施例では、テーブルは記憶装置３に作成される。原則として、データベース管理プログラム１２０は、テーブル内のデータアクセスを主に行う。ただし本実施例に係るデータベース管理プログラム１２０は、表関数（後述）をサポートしており、ファイルシステムプログラム１２１によって管理されているファイル（記憶装置４に格納されるインポートファイル３２）内に格納されているデータの検索も行うことができる。詳細は後述する。なお、データベース管理プログラム１２０には、ユーザからのデータベースアクセス要求（「クエリ」または「ＳＱＬクエリ」と呼ばれる）を処理するためのプログラムのほか、ファイルに格納されたデータをテーブル３００にインポートするためのプログラム（本実施例ではインポートプログラムと呼ぶ）も含まれる。【００２３】
データ収集プログラム１２３は、データソース８からファイルを受信し、記憶装置４に格納する処理を行うプログラムである。【００２４】
また、これらのプログラムが使用する管理情報として、ディクショナリ５００、データファイル管理表７００がある。これらの詳細は後述する。【００２５】
なお、上で説明したプログラムや管理情報は、サーバ１が稼働していない時は記憶装置３または４（あるいはサーバ１に内蔵された、非図示の補助記憶装置）に格納されている。サーバ１が起動し、必要な時（検索処理等が行われる時）に、これらのプログラムや管理情報は記憶装置３または４からメモリ１２上に読み出され、ＣＰＵ１１によって使用される。なお、サーバ１は上で述べたプログラム以外のプログラム、そして上で述べた管理情報以外の情報を、メモリ１２に格納してもよい。【００２６】
クライアント２のメモリ２２には、クライアントプログラム２２１が存在しており、ＣＰＵ２１がクライアントプログラム２２１を実行する。クライアントプログラム２２１は、ユーザが情報検索指示を発行するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）またはＣＬＩ（Ｃｏｍｍａｎｄ  Ｌｉｎｅ  Ｉｎｔｅｒｆａｃｅ）を提供するプログラムである。【００２７】
（２）  データベースとインポートファイルの構成
続いて、本実施例に係るデータ処理システムで取り扱われるデータベース３１とインポートファイル３２の構成について説明する。本実施例に係るサーバ１では、データベース管理プログラム１２０により、記憶装置３内にテーブル３００等を定義するためのデータベースエリア（データベース３１と呼ぶ）が定義され、データベース３１内には１または複数のテーブル３００が定義されている。【００２８】
まず、サーバ１で管理されるテーブル３００の例を図２に示す。本実施例では、テーブル３００に格納されるデータ（レコード）は一例として、時系列データとする。時系列データとはたとえば、データソース８がセンサから継続的に取得した計測データの集合である。【００２９】
テーブル３００は、ＤＡＴＥ（３１１）、ＶＡＬＵＥ１（３１２）、ＶＡＬＵＥ２（３１３）、ＶＡＬＵＥ３（３１４）の４つのカラムを有するレコードを複数有する。ＶＡＬＵＥ１（３１２）、ＶＡＬＵＥ２（３１３）、ＶＡＬＵＥ３（３１４）のカラムは、センサで測定された、温度などの物理量の格納されるカラムである。ＤＡＴＥ（３１１）は、センサによる測定の行われた日時を格納するためのカラムである。ただし図２のテーブル３００は一例であり、各レコードは４以上のカラムを有していてもよい。逆にテーブル３００のカラム数が４未満でもよい。【００３０】
インポートファイル３２の例を図３に示す。本実施例ではインポートファイル３２のファイル形式には、いわゆるＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅ）形式が採用される。ただしＣＳＶ形式以外のファイル形式が用いられてもよい。またインポートファイル３２に格納されるデータは圧縮された状態で格納されていてもよいが、本実施例では、インポートファイル３２には非圧縮状態でデータが格納されている例を説明する。【００３１】
インポートファイル３２の各行は、テーブル３００のレコードに相当する。つまり、テーブル内レコードのカラム（ＤＡＴＥ（３１１）、ＶＡＬＵＥ１（３１２）、ＶＡＬＵＥ２（３１３）、ＶＡＬＵＥ３（３１４））に格納される情報のそれぞれが、カンマで区切られた形で記述されている。図３において、行３２０が、テーブル内の１つのレコードに相当する情報のセットである。そして要素３２１，３２２，３２３，３２４はそれぞれ、テーブルのＤＡＴＥ（３１１）、ＶＡＬＵＥ１（３１２）、ＶＡＬＵＥ２（３１３）、ＶＡＬＵＥ３（３１４）に格納される情報である。以下では特に断りのない限り、インポートファイル３２の行のことも、テーブル３００のレコードと同じく、「レコード」と呼ぶ。【００３２】
（３）  機能ブロック構成
続いて図４を用いて、サーバ１の有する機能ブロックの説明を行う。本実施例に係るサーバ１は、上で説明したプログラム（主にデータベース管理プログラム１２０）がＣＰＵ１１で実行されることによって、ディクショナリ管理部２０１、ファイル収集部２０２、ファイル監視部２０３、クエリ受付部２０４、クエリ書換部２０５、クエリ最適化部２０６、クエリ実行部２０７、データベースアクセス部２０８、表関数処理部２０９という機能ブロックを備えた装置として動作する。以下、各機能ブロックの役割及び各機能ブロックが使用する管理情報を説明する。【００３３】
ディクショナリ管理部２０１は、ユーザから受け付けたテーブル作成要求に従って、テーブルの作成を行う。テーブル作成の際、ディクショナリ管理部２０１はテーブルの定義情報をディクショナリ５００に記録する。ディクショナリ５００の内容については後述する。【００３４】
クエリ受付部２０４は、ユーザからのデータベースアクセス要求を受け付け、適切な機能ブロックにその要求に係る処理を行わせ、処理結果をユーザに返送する。本実施例に係るＤＢサーバ１は、クライアント２からＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）で記述されたデータベースアクセス要求（「クエリ」または「ＳＱＬクエリ」と呼ばれる）を受領し、クエリの処理を行う。クエリ受付部２０４は、例えばクエリの書き換えが必要と判断した場合には、クエリ書換部２０５にクエリを渡す。【００３５】
クエリ書換部２０５は、受け付けたクエリの書き換えを行うための機能ブロックである。クエリ書換部２０５で行われる処理の詳細は、後述する。【００３６】
クエリ最適化部２０６は、受け付けたクエリを解析し、クエリに係る処理の実行手順（実行プラン）を決定する機能ブロックである。クエリ実行部２０７はクエリ最適化部２０６で決定された処理実行手順に従って、テーブルに格納されているレコードの検索等の処理を行う。【００３７】
データベースアクセス部２０８は、テーブル３００に格納されているレコードへのアクセスを行う機能ブロックである。データベースアクセス部２０８はクエリ実行部２０７からの指示に従って、レコードのリードやライトを行い、結果をクエリ実行部２０７に返送する。たとえばクエリ実行部２０７からの指示がレコード検索の指示であれば、データベースアクセス部２０８はテーブル３００からレコードを読み出して、クエリ実行部２０７に返送する。【００３８】
表関数処理部２０９は、ファイル（とくにインポートファイル３２）の読み出しを行う機能ブロックである。表関数とは、ＳＱＬ２００３で規格化されている機能で、本実施例に係るデータベース管理プログラム１２０は表関数をサポートしている。表関数処理部２０９は、インポートファイル３２を読み出して、インポートファイル３２に記述されている各行をテーブル形式のデータとして、クエリ実行部２０７に返却する機能を有する。【００３９】
ファイル収集部２０２は、データソース８から送信されたファイル（インポートファイル）を記憶装置４に格納する処理を行う機能ブロックである。ＣＰＵ１１がデータ収集プログラム１２３を実行することによって、サーバ１はファイル収集部２０２としての機能を果たす。またファイル監視部２０３は、記憶装置４に格納されるインポートファイル３２の監視を行う機能ブロックである。またファイル監視部２０３は、インポートファイル３２とテーブル３００との対応関係をデータファイル管理表７００に格納して管理する。【００４０】
なお、本実施例ではクエリ書換部等の機能ブロックを主語として、サーバ１で実行される処理の内容が説明される箇所がある。先に述べたとおり、本実施例に係るデータ処理システムでは、プログラム（主にデータベース管理プログラム１２０）がＣＰＵ１１で実行されることによって、サーバ１がこれら機能ブロックを備えた装置として動作するものであるから、実際の処理の主体は、正確にはサーバ１のＣＰＵ１１である。ただし説明が冗長になることを防ぐため、機能ブロックを主語として、各種処理の流れを説明することがある。そして機能ブロックを主語として処理内容が説明されている場合、その処理の主体はＣＰＵ１１であることを意味する。【００４１】
（４）  管理情報
次に、ディクショナリ５００、データファイル管理表７００について説明する。サーバ１がテーブルを作成する時、定義されるテーブルの属性情報等をディクショナリ５００に記録する。図２に示されたテーブル３００が定義（作成）された時に、ディクショナリ５００に記録される情報の例を、図５、図６を参照しながら説明する。ディクショナリ５００は、テーブル３００の属性が格納されるＳＱＬ＿ＴＡＢＬＥＳ（５１０）、テーブルの各カラムの属性が格納されるＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）を有する。図５はＳＱＬ＿ＴＡＢＬＥＳ（５１０）の構成を示し、図６はＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）の構成を示している。【００４２】
ＳＱＬ＿ＴＡＢＬＥＳ（５１０）は、スキーマ名（５１１）、表識別子（５１２）、表ＩＤ（５１３）、チャンク指定（５１４）、インポートファイル格納ディレクトリパス（５１６）のカラムを有するレコードを１以上有する。テーブルが作成されるたびに、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）に１つのレコードが作成される。スキーマ名（５１１）、表識別子（５１２）、表ＩＤ（５１３）はそれぞれ、作成されたテーブルの属するスキーマの名称（一般には、テーブル作成を指示したユーザのユーザ名である）、作成されたテーブルの識別子（ユーザが指定したテーブルの名称）、作成されたテーブルの識別番号である。これらは公知のＲＤＢＭＳでも管理される情報であるので、詳細説明は略す。なお、本実施例では、スキーマ名称とテーブルの識別子のセットのことを「テーブル名」と呼ぶことがある。【００４３】
また、本実施例に係るデータベース管理プログラム１２０によって管理されるテーブルの属性には、チャンク指定（５１４）、チャンク数最大値（５１５）、及びインポートファイル格納ディレクトリパス（５１６）という情報も含まれる。チャンク指定（５１４）は、チャンク作成可能か否かを指定する表である。本実施例に係るデータベース管理プログラム１２０は、１回のインポート処理でテーブルに格納されるデータを１つの塊として管理し、この塊を「チャンク」と呼ぶ。チャンク指定（５１４）が“Ｙ”の場合、テーブルにチャンクが作成可能であることを意味する。チャンク数最大値（５１５）は、テーブルに作成可能なチャンクの最大数である。チャンク指定（５１４）、チャンク数最大値（５１５）に格納される情報は、テーブル定義時にユーザから指定される。【００４４】
インポートファイル格納ディレクトリパス（５１６）には、インポートファイルの格納されるディレクトリ名が格納される。このディレクトリ名の情報は、ユーザがテーブルを定義する時に、ユーザから指定される。もしテーブル定義時に、ユーザからディレクトリ名の情報が指定されなかった場合には、インポートファイル格納ディレクトリパス（５１６）にはＮＵＬＬ値が格納される。なお本実施例では、テーブルごとにインポートファイル格納ディレクトリパス（５１６）の内容(ディレクトリ名)は異なるものとする（ユーザがそのように指定する）。つまり、ある１つのディレクトリに格納されている（１または複数の）ファイルは、特定の１つのテーブルにインポートされる。【００４５】
ＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）は、スキーマ名（５２１）、表識別子（５２２）、列名（５２３）、列ＩＤ（５２４）、データ型（５２５）、データ定義長（５２６）のカラムを有するレコードを１以上有する、一種の表である。これらは公知のＲＤＢＭＳでも管理される情報である。テーブルが作成されるたびに、そのテーブルについての情報を格納したＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）が１つ作成される。【００４６】
スキーマ名（５２１）、表識別子（５２２）はそれぞれ、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）の表識別子（５１２）、表ＩＤ（５１３）と同じ情報である。列名（５２３）は、テーブルに作成されたカラムの名称、列ＩＤ（５２４）は作成されたカラムの識別番号である。データ型（５２５）は、作成されたカラムに格納されるデータのタイプが指定される。データのタイプとは図６に示されているように、たとえば整数型（ＩＮＴＥＧＥＲ）、日付型（ＤＡＴＥ）等である。データ定義長（５２６）は、作成されたカラムに格納されるデータの長さ（最大長）が指定される。【００４７】
続いて、本実施例に係るデータ処理システムがインポートファイルを管理するための方法について説明する。【００４８】
データファイル管理表７００の例を図７に示す。データファイル管理表７００は、各インポートファイルについての情報を格納するための表で、１つのレコードに１つのインポートファイルの情報が格納される。【００４９】
ファイルパス（７０３）は、インポートファイルのファイル名である。ファイルパス（７０３）に格納されるファイル名には、絶対パス名が用いられる。【００５０】
一方、スキーマ名（７０１）及び表識別子（７０２）は、ファイルパス（７０３）に格納されている名称のファイル（インポートファイル）のインポート先となるテーブルの識別情報である。図７の先頭行のファイルパス（７０３）は“/home/data_dir/aaa.csv”、そしてスキーマ名（７０１）が“ＵＳＥＲ１”，表識別子（７０２）は“Ｔ１”であるから、インポートファイル“/home/data_dir/aaa.csv”は、スキーマ名（７０１）が“ＵＳＥＲ１”，表識別子（７０２）が“Ｔ１”のテーブルにインポートされるべきであること（またはインポートされたこと）を表す。インポート済みフラグ（７０７）は、インポートファイルの処理状態を表す。具体的には、ファイルパス（７０３）に記録されている名称のファイルが、テーブルにインポートされたか否かを表す情報が、インポート済みフラグ（７０７）に格納される。インポート済みフラグ（７０７）が“Ｎ”の場合、ファイルパス（７０３）で特定される名称のファイルがまだテーブルにインポートされていないことを意味し、一方インポート済みフラグ（７０７）が“Ｙ”の場合、ファイルがすでにテーブル（スキーマ名（７０１）及び表識別子（７０２）で特定されるテーブル）にインポートされたことを意味する。【００５１】
ファイル更新日時（７０５）は、ファイルの作成日時（または更新日時）を表し、一方行挿入日時（７０６）は、このレコードがデータファイル管理表７００に作成された日時（またはレコードが更新された日時）を表す。データファイル管理表７００にレコードが格納（挿入）される契機や、その時の処理の具体内容については、後述する。【００５２】
なお、本実施例では、データファイル管理表７００もデータベース管理プログラム１２０が管理するテーブルである。そのためサーバ１がデータファイル管理表７００のレコードにアクセスする際、ＳＱＬクエリを発行することでアクセスできる。またデータファイル管理表７００の属性情報もディクショナリ５００に格納される。【００５３】
（５）  処理の流れ
以下では、データ処理システムで実行される処理の流れを説明していく。【００５４】
（５−１）  ファイル監視処理
まずファイル監視処理の流れを説明する。ファイル監視処理はファイル監視部２０３が実行する。ファイル監視処理では、記憶装置４に新たにインポートファイルが格納されたか、或いは既に格納されていたインポートファイルが更新されたか、について確認が行われる。【００５５】
記憶装置４にファイルを格納する処理は、ファイル収集部２０２が実施する。ファイル収集部２０２はデータソース８からのファイル送信要求に応じて実行される。データソース８では常時、センサを用いた計測を行っており、計測結果の格納されたファイル（図３に示されたファイル）を適宜サーバ１に送信する。サーバ１へのファイル送信は定期的に行われてもよいし、或いは不定期なファイル送信が行われてもよい。【００５６】
データソース８がファイル送信要求をサーバ１に発行することに応じて、サーバ１ではファイル収集部２０２の実行が開始される。ファイル収集部２０２は、主にデータ収集プログラム１２３とファイルシステムプログラム１２１とがＣＰＵ１１で実行されることで実現される機能ブロックである。本実施例では、データソース８の発行するファイル送信要求に、ファイルと共に、ファイルの格納先ディレクトリ名も含まれている前提とする。つまりデータソース８では、あらかじめインポートファイルの格納先ディレクトリ名を把握している。そのためファイル収集部２０２は、データソース８から受領したファイルを、ファイル送信要求で指定されているディレクトリに格納する処理を行うだけであるため、詳細な説明は略す。【００５７】
以下、図８を参照しながら、ファイル監視処理の流れを説明する。ファイル監視処理は定期的に実行される処理である。つまりファイル監視処理の実行契機は、データソース８からサーバ１へのファイル送信の契機とは無関係（独立）である。もしユーザからファイル監視処理の停止要求を受け付けた場合には、ファイル監視処理は停止する。【００５８】
ステップ１００１：ファイル監視部２０３は、所定時間待機する。待機する時間の長さは、あらかじめ定められた固定値でも良いし、あるいは待機する時間をユーザが指定することができるように、ファイル監視部２０３が構成されていてもよい。【００５９】
ステップ１００２：ファイル監視部２０３はディクショナリ５００を参照し、インポートファイルの格納されるディレクトリ名を特定する。具体的にはファイル監視部２０３は、ディクショナリ５００が有するＳＱＬ＿ＴＡＢＬＥＳ（５１０）のカラム５１６（インポートファイル格納ディレクトリパス）を参照することで、インポートファイルの格納されるディレクトリ名を特定できる。ＳＱＬ＿ＴＡＢＬＥＳ（５１０）に複数のレコードが存在する場合（つまりサーバ１にテーブルが複数定義されている場合）、ファイル監視部２０３はＳＱＬ＿ＴＡＢＬＥＳ（５１０）の各レコードを参照し、インポートファイル格納ディレクトリパス（５１６）に格納されているディレクトリ名をすべて特定する。なお、以下では説明が複雑になることを避けるため、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）のレコードのうち、インポートファイル格納ディレクトリパス（５１６）にディレクトリ名が格納されているレコードが１つだけであったケースについて説明する。また、ここで特定されたディレクトリを「監視対象ディレクトリ」と呼ぶ。【００６０】
ステップ１００３：ファイル監視部２０３は、監視対象ディレクトリ内のファイルのチェックを行う。ここでの処理の詳細は後述するが（図９）、ステップ１００３が実行された結果、もし監視対象ディレクトリ内に新たにファイル（インポートファイル）が格納されていた場合には、データファイル管理表７００の内容が更新される。【００６１】
ステップ１００４：ステップ１００３において、ファイル監視部２０３がデータファイル管理表７００の内容を更新した場合（ステップ１００４：Ｙｅｓ）、ファイル監視部２０３は次にステップ１００５を実行する。もしステップ１００３でファイル監視部２０３がデータファイル管理表７００の内容を更新しなかった場合（ステップ１００４：Ｎｏ）、ファイル監視部２０３は次にステップ１００１に戻る。【００６２】
ステップ１００５：このステップは、ファイル監視部２０３がステップ１００３でデータファイル管理表７００の内容を更新した場合（つまり監視対象ディレクトリ内に新たなインポートファイルが格納された場合か、あるいは既に格納されていたインポートファイルの更新が行われていた場合）に実行される。ステップ１００５ではファイル監視部２０３は、新たに格納されたインポートファイル（または更新されたインポートファイル）のインポート処理を実施する。インポート処理の内容は後述する。【００６３】
ステップ１００６：ファイル監視部２０３は、ユーザがファイル監視処理の停止要求を発行したか確認する。もしユーザがファイル監視処理の停止要求を発行した場合には、ファイル監視部２０３は処理を終了する。ファイル監視処理の停止要求が発行されていない場合には、ファイル監視部２０３は再びステップ１００１から処理を繰り返す。【００６４】
ファイル監視部２０３は以上の処理を行う。なお上では、ステップ１００２で監視対象ディレクトリが１つだけ特定されたケースについて説明したが、もしステップ１００２で複数のディレクトリ名が特定された場合、ファイル監視部２０３は特定されたそれぞれのディレクトリについて、ステップ１００３〜ステップ１００５の処理を行う。【００６５】
続いて、図８のステップ１００３で行われる処理（ファイル更新チェック処理と呼ぶ）の詳細を、図９を用いて説明する。なお、図８の説明と同様に、ここでは図８のステップ１００２で監視対象ディレクトリが１つだけ特定されたケースについて説明する。もしステップ１００２で複数のディレクトリが特定された場合には、特定されたそれぞれのディレクトリについて、以下で述べるファイル更新チェック処理が行われる。【００６６】
ステップ１２０１：ファイル監視部２０３は、監視対象ディレクトリ内に格納されている、各ファイルの情報を取得する。ここでファイル監視部２０３が読み出す必要のある情報は、データファイル管理表７００に記録される情報で、具体的にはファイルパス（７０３）、ファイルサイズ（７０４）、ファイル更新日時（７０５）に記録される情報である。データソース８から送られてきたファイル（インポートファイル）が記憶装置４に格納される時、ファイル収集部２０２（データ収集プログラム１２３及びファイルシステムプログラム１２１）によって、ファイルにはファイル名やファイル作成日時（または更新日時）等の属性情報が付与されて格納される。そのためファイル監視部２０３は、ファイルシステムプログラム１２１によって付与された各ファイルの属性情報を記憶装置４から読み出すことで、必要な各ファイルの情報を取得できる。【００６７】
ステップ１２０２：もし、監視対象ディレクトリ内の全ファイルについて、ステップ１２０３以降の処理が行われた場合には、ファイル監視部２０３は処理を終了する。監視対象ディレクトリ内にまだステップ１２０３以降の処理が行われていないファイルが残っている場合には、ファイル監視部２０３は次にステップ１２０３を実行する。【００６８】
ステップ１２０３：ファイル監視部２０３は、ステップ１２０１で取得された各ファイルの情報のうち、ステップ１２０４以降の処理を行う対象となる１つのファイルの情報を選択する。以下の説明では、ここで選択されたファイルの情報のことを「対象ファイルの情報」と呼び、また対象ファイルの情報を属性情報として持つファイルのことを「対象ファイル」と呼ぶ。そしてファイル監視部２０３は、データファイル管理表７００内の行（レコード）のうち、ファイルパス（７０３）が、対象ファイルのファイル名と同じであるレコードがあるか検索する。【００６９】
ステップ１２０４：ファイル監視部２０３は、ステップ１２０３の処理の結果、対象ファイルのファイル名と同じであるレコードがデータファイル管理表７００内にない場合（ステップ１２０４：Ｎｏ）、次にステップ１２０５を行い、ある場合には、次にステップ１２０６を実行する。なおステップ１２０４の判定が否定的な場合とは、監視対象ディレクトリに新たなインポートファイルが格納された場合である。【００７０】
ステップ１２０５：ファイル監視部２０３は、データファイル管理表７００にレコードを１つ作成し、作成したレコードのファイルパス（７０３）、ファイルサイズ（７０４）、ファイル更新日時（７０５）に、対象ファイルの情報を格納する。またこの時ファイル監視部２０３は、作成したレコードの行挿入日時（７０６）に現在時刻（ステップ１２０５を実行している時点の時刻）を記録し、スキーマ名（７０１）及び表識別子（７０２）にはそれぞれ、対象ファイルがインポートされるべきテーブルのスキーマ名と表識別子を記
録する。ファイルがインポートされるべきテーブルのスキーマ名と表識別子は、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）に記録されているので、ファイル監視部２０３はＳＱＬ＿ＴＡＢＬＥＳ（５１０）のインポートファイル格納ディレクトリパス（５１６）のディレクトリ名が監視対象ディレクトリと同じである行を特定し、その行のスキーマ名（５１１）及び表識別子（５１２）の情報を、今回作成したレコードのスキーマ名（７０１）及び表識別子（７０２）に格納する。【００７１】
ステップ１２０６：ファイル監視部２０３は、対象ファイルの情報が、データファイル管理表７００内のレコードに記録されているファイルの情報より新しい場合（ステップ１２０６：Ｙｅｓ）、ステップ１２０７を実行し、そうでない場合にはステップ１２０２から処理を繰り返す。具体的にはファイル監視部２０３はファイルの更新日時を比較することで、ステップ１２０６の判定を行う。【００７２】
ステップ１２０７：対象ファイルの情報が、データファイル管理表７００内のレコードに記録されているファイルの情報より新しい場合、そのファイルが更新されたことを意味する。そのためファイル監視部２０３は、データファイル管理表７００内のレコードに記録されているファイルの情報を、ステップ１２０３で選択されたファイルの情報を用いて更新する。具体的には、ファイルサイズ（７０４）、ファイル更新日時（７０５）が、ステップ１２０３で選択されたファイルの情報を用いて更新される。またファイル監視部２０３は、行挿入日時（７０６）を現在時刻（ステップ１２０７を実行した時刻）に更新し、またインポート済みフラグ（７０７）には“Ｎ”を格納する。【００７３】
続いて、図８のステップ１００５で実行されるインポート処理について、図１０を用いて説明する。なお、説明が複雑になることを避けるため、以下ではインポート対象のファイル（インポートファイル）が１つのケース（つまりステップ１００３で、データファイル管理表７００のレコードのうち、１つのレコードだけが更新（または追加）されていた場合）について説明する。そして以下のインポート処理の説明においては、インポート処理（図１０に記載の処理）の対象となるインポートファイルのことを「インポートソースファイル」と呼ぶ。【００７４】
本実施例において、ファイル監視部２０３は、バックグラウンドインポート機能をサポートしている。バックグラウンドインポート機能は公知の機能で、インポート処理中に、インポート処理対象となっているテーブルに対する検索を可能とする機能である。この機能はたとえば、データベース管理プログラム１２０に含まれるインポートプログラムにより実現される機能である。たとえば以下で説明するステップ１１０１，１１０２は、サーバ１のＣＰＵ１１でインポートプログラムが実行されることにより行われる。またステップ１１０１，１１０２は公知の処理である。【００７５】
ステップ１１０１：ファイル監視部２０３は、インポート処理対象のテーブルにチャンクを作成する。ここでは、空のチャンクが作成される。【００７６】
ステップ１１０２：ファイル監視部２０３は、インポートソースファイルからインポート処理対象のテーブルにデータのインポートを行う。ここでインポートされるデータは、ステップ１１０１で作成されたチャンクに追加される。【００７７】
ステップ１１０３：インポートソースファイル内の全てのデータがインポートされた後、ファイル監視部２０３は、データファイル管理表７００のレコードのうち、インポートソースファイルについてのレコード（ファイルパス（７０３）にインポートソースファイルのファイル名が格納されているレコード）のインポート済みフラグ（７０７）を“Ｙ”に変更し、処理を終了する。【００７８】
バックグラウンドインポート機能、及び図１０のインポート処理で用いられるチャンクについて、図１１を用いて概要を説明する。図１１において、点線で囲まれた領域１５０１，１５０２はそれぞれチャンクを表している。チャンク１５０１はインポート処理の前から存在するもので、チャンク１５０２は、ステップ１１０１が実行された時に作成されたチャンク（空のチャンク）を表している。【００７９】
インポート処理中（ステップ１１０２）は、インポートソースファイルに格納されていたデータが、順次チャンク１５０２へと追加されていき、チャンク１５０１の内容に変更が発生しない。そのため、データインポート中（ステップ１１０２の実行中）にユーザがテーブルに対して検索要求を発行したとき、サーバ１はチャンク１５０１の内容を用いて検索処理を行って、ユーザに検索結果を返すことができる。【００８０】
そしてステップ１１０２が完了すると、チャンク１５０２に格納されたデータも、検索処理における検索処理対象に変更される。そのためステップ１１０２の完了後に、ユーザがテーブルに対して検索要求を発行した時には、サーバ１はチャンク１５０１及びチャンク１５０２からデータの検索を行う。【００８１】
（５−２）  検索処理
続いて検索処理の流れを説明する。先に述べたとおり、公知のバックグラウンド機能をサポートしているデータベースシステムであれば、インポート処理中にインポート処理対象のテーブルに対する検索要求をユーザから受け付けても、ユーザを待たせることなく検索結果を返すことができる。しかし先に述べたとおり、インポート処理中にインポート処理対象のテーブルに対する検索要求をユーザから受け付けた時、検索対象となるデータは、図１１のチャンク１５０１内のデータ（インポート処理開始時にテーブルに存在したデータ）に限られ、インポートファイルに記録されているデータの検索はできない。インポートファイルのサイズが極めて大きい場合、インポート処理に要する時間は長くなるため、インポートファイルに記録されているデータを利用できない時間が長くなる。【００８２】
その問題を解決するため、本実施例に係るサーバ１では、インポート処理中に検索要求を受け付けた時に、インポートファイルに格納されているデータの検索も可能にする。図１２は、本実施例に係るデータ処理システムで行われる検索処理の流れを示している。【００８３】
ステップ１３０１：クエリ受付部２０４は、ユーザが使用するクライアント２からＳＱＬクエリを受け付けると、そのクエリが、クエリ書き換えが必要かを判断するための解析を行う。具体的には、クエリ受付部２０４はまず、データファイル管理表７００に、受け付けたＳＱＬクエリのＦＲＯＭ句に記述されているテーブル名称と同じテーブル名が登録されているレコードがあるか判断する。もしそのようなレコードがあった場合、クエリ受付部２０４は、そのレコードのインポート済みフラグ（７０７）が“Ｎ”か判断する。インポート済みフラグ（７０７）が“Ｎ”のレコードがあった場合、それは検索対象のテーブルに対するインポートファイルが記憶装置４に格納されているが、まだそのインポートファイルがテーブルにインポートされていないことを意味する。【００８４】
ステップ１３０２：ステップ１３０１の処理の結果、まだ検索対象のテーブルにインポートされていないインポートファイルがあった場合（ステップ１３０２：Ｙｅｓ）、次にステップ１３０３が行われる。一方、データファイル管理表７００に、検索対象のテーブルに対するインポートファイルの情報が登録されていない場合、あるいは検索対象のテーブルに対するインポートファイルの情報が登録されているが、そのインポートファイルはインポート済み（インポート済みフラグ（７０７）が“Ｙ”））の場合、ステップ１３０３はスキップされる。【００８５】
ステップ１３０３：クエリ受付部２０４は、受け付けたＳＱＬをクエリ書換部２０５に渡す。クエリを渡されたクエリ書換部２０５は、クエリ書き換え処理を行うが、この処理は後述する。【００８６】
ステップ１３０４：クエリ受付部２０４は、クエリをクエリ最適化部２０６に渡す。クエリ最適化部２０６では、クエリについての実行プランが生成される。この処理は公知のＲＤＢＭＳで行われるものと同様である。【００８７】
ステップ１３０５：クエリの実行プランはクエリ実行部２０７に渡され、クエリ実行部２０７は実行プランに従って処理を行う。クエリ実行部２０７は、データベースアクセス部２０８や表関数処理部２０９を用いて、テーブル３００やインポートファイル３２からレコードの読み出しを行い、読み出されたレコードから、クエリで指定された条件に該当するレコードを抽出する。そしてクエリ実行部２０７は、抽出されたレコードをクエリ受付部２０４に返送する。クエリ受付部２０４は、返送されてきた結果をユーザ（クライアント２）へ出力する。【００８８】
これが検索処理の全体の流れである。以下では各ステップの詳細について説明していく。【００８９】
（５−３）  クエリ書換処理
ここでは、ステップ１３０３で行われるクエリ書き換え処理について説明する。ただしその前に、ユーザから渡されるクエリ（書き換え前クエリと呼ぶ）、そしてステップ１３０３において書き換えられた後のクエリ（書き換え後クエリと呼ぶ）の記述例を説明する。【００９０】
図１３に記載のクエリは、ユーザがサーバ１に対して発行するＳＱＬクエリ（書き換え前クエリ）の例である。ＳＱＬは公知であるため、ここではクエリの概要のみ説明する。なお、図１３等に示されているクエリの各行の先頭に付されている番号は、説明のために付されている行番号である。【００９１】
図１３の書き換え前クエリの記述内容を簡単に説明する。図１３の書き換え前クエリは、ＦＲＯＭ句で指定されているテーブル“USER1.T1”を検索対象とするクエリである。以下、クエリのＦＲＯＭ句で指定されているテーブルのことを、「検索対象テーブル」と呼ぶ。なお、本実施例では説明の簡単化のため、ＷＨＥＲＥ句（検索されるべきレコードの条件を指定するためのフレーズ）が指定されていないＳＱＬクエリを、ユーザが発行した場合の例を説明する。図１３のクエリは、検索対象のテーブル“USER1.T1”の中の全レコードを抽出して出力することを指示するクエリである。【００９２】
また、ＳＱＬクエリのＳＥＬＥＣＴ句の後に属性（カラム）が指定されることもあり、サーバ１がそのようなクエリを受け付けた場合には、指定されたカラムのみを出力する。ただしここでは説明の簡単化のため、ＳＱＬクエリのＳＥＬＥＣＴ句の後にはアスタリスク（＊）が記述されている例（レコード内の全属性を出力することをユーザから要求されているケース）について説明する。【００９３】
また、図１３では検索対象テーブルは１つしか指定されていない例を示している。ただし実際には、ＦＲＯＭ句に検索対象テーブルが複数指定されたクエリをユーザから受領することもある。そのような例については後述する。【００９４】
本実施例では、検索対象テーブルに対してデータインポート中のインポートファイル３２が記憶装置４に存在する場合には、クエリ書換部２０５はユーザから受け付けたＳＱＬクエリを書き換えることで、その後の処理を行うクエリ実行部２０７に、テーブル３００だけでなくインポートファイル３２からもレコードを取得させる。インポートファイル３２の読み出しをクエリ実行部２０７に行わせるために、クエリ書換部２０５は表関数を用いたクエリを生成する。表関数を用いて記述された、インポートファイル３２を読み出すためのクエリの例を図１４に示す。【００９５】
図１４に示されたクエリは、図１３の書き換え前クエリと同様の検索をインポートファイル３２（ファイル‘/home/data_dir/aaa.csv’）に対して行うクエリである。以下、このクエリを「部分クエリ２」と呼び、一方書き換え前クエリで指定されている検索対象テーブルからデータを検索するためのクエリを「部分クエリ１」と呼ぶ。部分クエリ１は、書き換え前クエリと実質的に同内容のクエリである。【００９６】
図１４のクエリと図１３のクエリの違いは、ＦＲＯＭ句に指定された情報だけである。具体的には図１３のクエリで指定されている検索対象テーブルの名称（USER1.T1）が、以下で説明する表関数(図１４の２行目〜７行目)に置き換えられている。それ以外には、両者に違いはない。【００９７】
ここで用いられている表関数の機能について説明する。表関数ＴＡＢＬＥ（）の引数部分（図１４の３行目〜６行目）に記述されている関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）は、引数に指定されたファイル（ＣＳＶファイル）から読み出した各行を出力する関数である。ＴＡＢＬＥ（）は、テキスト行をテーブル形式のデータとして出力する関数である。なお、図１４では、ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数に指定されているファイル名は１つだけだが、ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数には複数のファイル名を指定することができる。たとえばＡＤＢ＿ＣＳＶＲＥＡＤ（ＭＵＬＴＩＳＥＴ［’xxx.csv’，’aaa.csv’］）と記述されている場合、ファイルxxx.csv及びaaa.csvの読み出しが行われる。また、５行目に記述されている“ＣＯＭＰＲＥＳＳＩＯＮ＿ＦＯＲＭＡＴ＝ＮＯＮＥ”は、引数で指定されるファイルが圧縮形式でない場合に指定される引数で、リード対象のインポートファイル３２が圧縮形式の場合には、たとえば“ＣＯＭＰＲＥＳＳＩＯＮ＿ＦＯＲＭＡＴ＝ＧＺＩＰ”等の引数が記述される。【００９８】
クエリ書換部２０５は、上で述べた部分クエリ２を作成し、さらに部分クエリ２と、テーブル３００内のレコード検索を行うためのクエリ（部分クエリ１）の出力結果の和集合を求めるクエリを作成する。本実施例では、これを書き換え後クエリと呼ぶ。図１５は、図１３の書き換え前クエリを書き換えた後のクエリの例である。図中の「部分クエリ１」と記述された部分が、テーブル３００内のレコード検索を行うためのクエリで、この例では、部分クエリ１の内容は書き換え前クエリと同じである。図１５の５行目以降（部分クエリ２）がインポートファイル３２からレコードを検索するクエリで、図１４と同じ内容である。書き換え後クエリは、部分クエリ１と部分クエリ２を、３行目に記述されている“ＵＮＩＯＮ  ＡＬＬ”演算子（和集合を求めるための演算子）で連結したものである。【００９９】
ただし上で説明した書き換え後クエリは一例であり、図１５等に記載されたクエリと同じものが生成されなければいけないわけではない。書き換え前クエリで指定された条件のレコードを、テーブル３００とインポートファイル３２の両方から検索できるクエリが生成されればよい。また、本実施例に係るクエリ書換部２０５が実際に行う処理も、上で説明したものとは若干異なり、書き換え後クエリの記述内容も図１５に記載されたものと異なる点がある。クエリ書換部２０５が実際に行う処理については、以下で説明する。【０１００】
図１６を用いて、クエリ書換部２０５が実施する、クエリ書き換え処理の流れを説明する。以下の説明では、書き換え前クエリとして、図１７に記載のクエリが与えられた場合の例について説明する。図１７は図１３に記述されたクエリの例をより一般化したもので、検索対象テーブルが複数指定されたクエリである。ＦＲＯＭ句には、実際にはユーザから指定される具体的なテーブル名が入るが、以下ではクエリ書き換えの方法を一般化した例を説明するため、クエリ中で指定されるテーブル名の情報を、変数に置き換えたクエリを用いて説明を行う。【０１０１】
なお、説明が複雑になることを避けるために、書き換え前クエリの例として、ＷＨＥＲＥ句の指定がなく、またＳＥＬＥＣＴ句にはアスタリスクが指定されている例を説明する。【０１０２】
図１７において、ＦＲＯＭ句に含まれている変数（＄Ｂ１），（＄Ｂ２），．．．，（＄Ｂｎ）はそれぞれ、検索対象のテーブル名を表す。（＄Ｂ１），（＄Ｂ２），．．．，（＄Ｂｎ）のそれぞれが、１つのテーブル名に相当する。つまり図１７のクエリは、検索対象テーブルが複数ある場合の例である。なお、以下では（＄Ｂｘ）のことを「テーブル（＄Ｂｘ）」と呼ぶこともある（ｘは１以上ｎ以下の整数である）。【０１０３】
ここでは、ＦＲＯＭ句で指定されたテーブル（＄Ｂ１），（＄Ｂ２），．．．，（＄Ｂｎ）のうち、テーブル（＄Ｂ１）に対して、ファイル（ファイル名を“/home/data_dir/aaa.csv”とする）からのインポートが行われている場合に、図１７のクエリがクエリ書換部２０５によりどのように書き換えられるかを説明する。図１８が、図１７の書き換え前クエリが書き換えられた後の例で、３行目〜４行目が部分クエリ１、８行目〜１４行目が部分クエリ２である。【０１０４】
ステップ１４０１：クエリ書換部２０５は、クエリ受付部２０４から受領したＳＱＬクエリを解析し、検索対象のテーブル（ＦＲＯＭ句に記載されたテーブル）を１つ特定する。ここで特定されるべきテーブルは、まだステップ１４０３以降の処理対象になっていない検索対象テーブルである。【０１０５】
ステップ１４０２：クエリ書換部２０５は、ステップ１４０１の結果、まだステップ１４０３以降の処理が行われていない検索対象テーブルが存在した場合（ステップ１４０２：Ｎｏ）、次にステップ１４０３を行う。全ての検索対象テーブルについてステップ１４０３以降の処理が行われており、ステップ１４０３以降の処理を行うべき検索対象テーブルがステップ１４０１で特定できなかった場合には（ステップ１４０２：Ｙｅｓ）、処理を終了する。【０１０６】
なお、以下のステップ１４０３以降の説明では、ステップ１４０１でテーブル（＄Ｂ１）が特定されたケースの例を説明する。【０１０７】
ステップ１４０３：クエリ書換部２０５は、ステップ１４０１で特定されたテーブルのテーブル名（＄Ｂ１）をキーに、データファイル管理表７００の中からレコードの検索を行う。具体的には、データファイル管理表７００内のレコードのうち、テーブル名称（つまりスキーマ名（７０１）及び表識別子（７０２）の組み合わせ）がステップ１４０１で特定されたテーブル名（つまり（＄Ｂ１））と一致するレコードを検索する。この処理の結果、複数のレコードが見つかる場合がある。これは記憶装置４にインポートファイル３２が複数存在するケースである。【０１０８】
ステップ１４０４：クエリ書換部２０５は、ステップ１４０３で特定されたレコードの中に、インポート済みフラグ（７０７）が“Ｎ”のレコードがあるか判定する。インポート済みフラグ（７０７）が“Ｎ”のレコードが１つ以上あった場合（ステップ１４０４：Ｙｅｓ）、次にステップ１４０５が行われる。逆に、ステップ１４０３で特定されたレコードの中に、インポート済みフラグ（７０７）が“Ｎ”のレコードがなかった場合、あるいはデータファイル管理表７００内に、テーブル名称（スキーマ名（７０１）及び表識別子（７０２）の組み合わせ）が（＄Ｂ１）であるレコードがなかった場合（ステップ１４０４：Ｎｏ）、クエリ書換部２０５は次にステップ１４０１を行う。【０１０９】
ステップ１４０５：クエリ書換部２０５は、受け付けたクエリ、及びステップ１４０１で特定されたテーブル名を用いて、部分クエリ１を生成する。先に説明したとおり、部分クエリ１は、（インポートファイルではなく）検索対象テーブルからレコードを検索するクエリである。【０１１０】
図１８に示されているように、受け付けたクエリが図１７のもので、ステップ１４０１でテーブル（＄Ｂ１）が特定された場合、部分クエリ１として
SELECT * FROM ($B1)
が生成される。つまりここで生成される部分クエリ１では、ＳＥＬＥＣＴ句（３行目）に、受け付けたクエリと同じ内容(つまり”＊”)が指定される。またＦＲＯＭ句には、書き換え前クエリで指定されている複数の検索対象テーブルのうち、ステップ１４０１で特定されたテーブル（＄Ｂ１）が指定される。【０１１１】
ステップ１４０７：クエリ書換部２０５は、ステップ１４０３で特定された、データファイル管理表７００のレコードのファイルパス（７０３）の内容を用いて部分クエリ２を生成する。部分クエリ２のＳＥＬＥＣＴ句に指定される情報は、部分クエリ１のものと同じである。そして部分クエリ２のＦＲＯＭ句（図１８の９行目〜１４行目）には、ファイルパス（７０３）を引数に含む表関数が指定される。【０１１２】
ステップ１４０８：クエリ書換部２０５は、ここまでで作成された部分クエリ１及び部分クエリ２の出力結果の和集合を出力するクエリを生成する。具体的には、図１８（３行目〜１５行目）に示されているように、クエリ書換部２０５は、部分クエリ１と部分クエリ２を“ＵＮＩＯＮ  ＡＬＬ”演算子で連結したクエリを生成する。そして書き換え前クエリのＦＲＯＭ句に指定されている検索対象テーブル名を、ここで生成したクエリに書き換える。たとえばステップ１４０１でテーブル（＄Ｂ１）が選択された場合、書き換え前クエリのＦＲＯＭ句のうち、（＄Ｂ１）部分を、ここで生成したクエリに書き換える。図１８では（＄Ｂ１）が書き換えられた例が示されている。【０１１３】
この後クエリ書換部２０５は、再びステップ１４０１からの処理を実行する。書き換え前クエリに指定されている全ての検索対象テーブルについて、上で述べた処理が行われると、書き換え後クエリが完成し、クエリ書き換え処理は終了する。【０１１４】
（５−４）  実行プラン生成と最適化
最後に、ステップ１３０４、ステップ１３０５で行われる、実行プランの生成、実行処理について説明する。本実施例における実行プランの生成処理は、公知のＲＤＢＭＳで行われるものと大きく変わるところはないため、本実施例における実行プランの生成及び実行処理の概要を述べる。【０１１５】
本実施例に係るデータ処理システムでは、サーバ１が複数のＣＰＵ１１を有するので、幾つかの処理を並列に実行することができる。そこでクエリ最適化部２０６は、実行プランを生成する際、並列化可能な複数の処理がある場合、それらの処理が並列実行されるような実行プランを生成する。【０１１６】
並列化可能な処理とは、たとえば互いに依存関係のない処理である。逆に依存関係のある処理同士は並列実行できない。たとえば図１５等に記載の書き換え後クエリの中で、部分クエリ１と部分クエリ２の間には依存関係がない。部分クエリ１の実行のためには、記憶装置３内のテーブル３００を読み出す必要があり、また部分クエリ２の実行のためには記憶装置４内のインポートファイル３２を読み出す必要があるが、テーブル３００の読み出しとインポートファイル３２の読み出しには互いに依存関係がない（テーブル３００を読み出すまでインポートファイル３２を読み出すことができない等の制約がない）。そのためクエリ最適化部２０６は、テーブル３００の読み出しとインポートファイル３２の読み出しを並列に実行する実行プランを生成し、クエリ実行部２０７に実行させる。クエリ実行部２０７ではそのような実行プランを受領すると、たとえばテーブル３００の読み出しを行うタスク（スレッド）とインポートファイル３２の読み出しを行うタスクとを生成し、両者を並列実行する。【０１１７】
また、部分クエリ２に、リード対象のインポートファイル３２が複数（たとえばｍ個）存在する場合、ｍ個のインポートファイル３２の読み出し処理を並列実行可能である。そのためクエリ最適化部２０６は、インポートファイル３２の読み出しを並列実行する実行プランを生成し、クエリ実行部２０７に実行させる。【０１１８】
以上で、実施例１に係るデータ処理システムの説明を終える。実施例１に係るデータ処理システムでは上で述べた処理が行われるため、インポートファイル内のデータをテーブルへインポートしている間にユーザからクエリを受け付けた時、テーブル内のレコードだけでなくインポートファイル内のレコードも検索することができる。【０１１９】
なお、上では、データベース管理プログラム１２０に含まれるインポートプログラムと呼ばれる専用のプログラムが実行されることにより、インポートファイルからテーブルへのデータインポートがバックグラウンド実行される例を説明した。しかし専用のプログラムでインポートを行う以外の方法が採用されてもよい。たとえば、インポートファイル内のレコードをテーブルに挿入するためのＳＱＬクエリを作成し、それをサーバ１で実行させることで、インポート処理が行われてもよい。【０１２０】
図２３に、テーブルにインポートファイルのデータを格納するためのＳＱＬクエリの例を示す。図２３に示されたクエリの例は、インポート先のテーブル名が”USER1.T1”、そしてインポートファイルのファイル名が“/home/data_dir/aaa.csv”である場合の例である。このようなＳＱＬクエリを用いてインポート処理を実現する場合、ファイル監視部２０３は、図１０のステップ１１０１，１１０２に代えて、図２３のようなクエリを作成し、クエリ最適化部２０６、クエリ実行部２０７を用いてクエリを実行させるとよい。
【実施例２】
【０１２１】
続いて実施例２に係るデータ処理システムの説明を行う。実施例２に係るデータ処理システムのハードウェア構成や機能ブロックの構成は、実施例１で説明したものと同じであるため、図示は略す。【０１２２】
実施例２に係るデータ処理システムでは、クエリ書き換え処理の一部が、実施例１で説明したものと異なるが、その他の点は実施例１で説明したものと同じである。以下では実施例２におけるクエリ書き換え処理について、実施例１と異なる点について説明する。【０１２３】
図１９は、実施例２におけるクエリ書き換え処理で生成される部分クエリ２の例を示している。なおここでの部分クエリ２の例は、サーバ１が図１３のクエリ（検索対象テーブル名が“USER1.T1”(スキーマ名が”USER1”、表識別子が"T１"である)のクエリ）を書き換え前クエリとして受領した場合の例である。図１９に示されている部分クエリ２が、実施例１で説明した部分クエリ２（たとえば図１５や図１８を参照）と違う点は、関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数に指定されている内容である。実施例１で説明した部分クエリ２では、関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数にはファイル名が記述されている。一方図１９に示されている部分クエリ２では、図１９の５行目〜９行目に示されている通り、ファイル名の代わりにＳＱＬクエリが記述されている。以下ではこのクエリを「部分クエリ３」と呼ぶ。【０１２４】
部分クエリ３は図１９に示されているように、データファイル管理表７００の中からスキーマ名（７０１）が”USER1”、表識別子（７０２）が”T1”、そしてインポート済みフラグ（７０７）が”N”であるレコードのファイルパス（７０３）の内容を抽出するためのクエリである。これは、図１６に示すクエリ書き換え処理のうち、ステップ１４０３と同内容の検索を行うためのクエリである。【０１２５】
図２０を参照しながら、実施例２に係るクエリ書き換え処理の流れ、特に実施例１で説明した処理と異なる点について説明する。実施例２に係るクエリ書き換え処理は、実施例１で説明したクエリ書き換え処理に対してステップ１４０６が加えられ、また実施例１で説明したステップ１４０７の代わりにステップ１４０７’が行われる点が異なる。その他の処理は実施例１で説明したものと同じであるため、以下ではステップ１４０６、ステップ１４０７’について説明する。【０１２６】
ステップ１４０５の後、クエリ書換部２０５はステップ１４０６を実行する。ステップ１４０６ではクエリ書換部２０５は、上で説明したように、ステップ１４０３と同内容の検索を行うための部分クエリ３を生成する。【０１２７】
その後クエリ書換部２０５はステップ１４０７’において、部分クエリ３を含んだ部分クエリ２を生成する。ステップ１４０７’で行われる処理は、関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数に部分クエリ３が記述される以外は、実施例１のステップ１４０７と同様である。【０１２８】
部分クエリ３を含んだ部分クエリ２がクエリ最適化部２０６及びクエリ実行部２０７で処理される時、まず部分クエリ３に記述された検索処理（データファイル管理表７００内のレコード検索）が行われる。それにより、インポートファイルのファイル名が特定され、特定されたファイルについて部分クエリ２に記述された検索処理が行われることになる。【０１２９】
実施例１、２のいずれにおけるクエリ書き換え処理が実行されても、クエリ実行時（クエリ実行部２０７における処理）では、インポート中のインポートファイルからのデータ検索が行われる。つまり実施例１でも実施例２でも、ユーザが得られる結果は多くの場合同じである。ただしクエリ書き換え処理が行われてから、書き換え後クエリについての処理がクエリ実行部２０７で実行されるまでには、わずかながら時間遅れがあるため、実施例１においては以下のような事象が発生することがある。【０１３０】
実施例１で用いた図１２、図１６を参照しながら、実施例１に係るデータ処理システムにおいてクエリ書き換え処理が行われる時の一例を説明する。またクエリ書き換え処理（図１６）のステップ１４０３で、条件に合致するデータファイル管理表７００のレコードが１つ検出され、そのレコードのファイルパス（７０３）が“aaa.csv”であるケースについて説明する。【０１３１】
この場合、クエリ書き換え処理のステップ１４０７で生成される部分クエリ２には、ファイル名“aaa.csv”が関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数に記述される。その結果、クエリ実行部２０７がクエリについての処理を実行する時には、ファイル“aaa.csv”の読み出し、及び読み出したこのファイルからのレコード検索が行われる。【０１３２】
ただし、クエリ書き換え処理の実行後（図１２  ステップ１３０３の後）、クエリ実行部２０７の処理（図１２  ステップ１３０５）が開始されるまでの間に、ファイル“aaa.csv”のインポート処理が完了していることもある。インポート処理により、ファイル“aaa.csv”の内容はすでにテーブルに反映されているため、この場合、ファイル“aaa.csv”の読み出しは不要である。しかし実施例１では部分クエリ２にファイル名“aaa.csv”が関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数に記述されているため、ファイル“aaa.csv”のインポート処理が完了していても、クエリ実行部２０７はファイル“aaa.csv”の読み出しを行うことになる（不要なファイル読み出しが発生する）。【０１３３】
一方実施例２の場合、図１９のような部分クエリ２が生成され、部分クエリ２にファイル名が直接記述されない。ファイル名が特定されるのはクエリ実行部２０７の処理（図１２  ステップ１３０５）が開始される時点である。もしこの時点でファイル“aaa.csv”のインポート処理が完了していた場合、データファイル管理表７００のレコードのうち、ファイルパス（７０３）が“aaa.csv”であるレコードのインポート済みフラグ（７０７）は“Ｙ”に変更されている。そのため、実施例２におけるクエリ実行部２０７が部分クエリ２に係る処理を実行すると、ファイル“aaa.csv”は読み出されないので、実施例２では不要なファイル読み出しを抑止することができる。
【実施例３】
【０１３４】
続いて実施例３に係るデータ処理システムの説明を行う。実施例３に係るデータ処理システムのハードウェア構成や機能ブロックの構成は、実施例１または実施例２で説明したものと同じであるため、図示は略す。実施例３に係るデータ処理システムでは、検索処理の一部が、実施例１で説明したものと異なるが、その他の点は実施例１で説明したものと同じである。以下では実施例３における検索処理について、実施例１と異なる点について説明する。【０１３５】
図２１は、実施例３に係るデータ処理システムで行われる検索処理の流れを示している。【０１３６】
ステップ２３０１：クエリ受付部２０４は、ユーザが使用するクライアント２からＳＱＬクエリを受け付けると、そのクエリに指定されている検索対象テーブルを特定する。さらにクエリ受付部２０４はＳＱＬ＿ＴＡＢＬＥＳ（５１０）を参照し、検索対象テーブルのインポートファイル格納ディレクトリパス（５１６）を特定する。【０１３７】
ステップ２３０２：クエリ受付部２０４はファイル監視部２０３を呼び出して、ステップ２３０１で特定されたディレクトリ内のファイルのチェックを行わせる。ここで行われる処理は、実施例１で説明したステップ１００３（図８、図９）と同様で、ステップ２３０１で特定されたディレクトリ内に新たなインポートファイルが格納されたか、あるいはこのディレクトリ内に既に存在していたインポートファイルに更新が行われたか、確認される。そして実施例１で説明した処理と同様に、もし新たなインポートファイルが格納された（あるいはインポートファイルの更新が行われた）場合には、データファイル管理表７００の更新が行われる。【０１３８】
ステップ２３０３：クエリ受付部２０４は、受け付けたクエリについてクエリ書き換えが必要か判断する。ここで行われる処理はステップ１３０１と同様で、クエリ受付部２０４はデータファイル管理表７００の中に、受け付けたＳＱＬクエリのＦＲＯＭ句に記述されているテーブル名称と同じテーブル名が登録されているレコードで、かつインポート済みフラグ（７０７）が“Ｎ”のレコードがあるか否か判断する（つまり検索対象のテーブルにインポートされていないインポートファイルがあるか否か、判断される）。【０１３９】
ステップ２３０４：ステップ２３０３の処理の結果、まだ検索対象のテーブルにインポートされていないインポートファイルがあった場合（ステップ２３０４：Ｙｅｓ）、次にステップ２３０５が行われる。一方、データファイル管理表７００に、検索対象のテーブルに対するインポートファイルの情報が登録されていない場合、あるいは検索対象のテーブルに対するインポートファイルの情報が登録されているが、そのインポートファイルはインポート済み（インポート済みフラグ（７０７）が“Ｙ”））の場合、ステップ２３０５はスキップされる。【０１４０】
ステップ２３０５：この処理は、ステップ１３０３と同じで、クエリ書き換えが行われる。【０１４１】
ステップ２３０６：この処理はステップ１３０４と同じ処理であるので、ここでの説明は略す。【０１４２】
ステップ２３０７：この処理はステップ１３０５と同じ処理であるので、ここでの説明は略す。【０１４３】
実施例３と、実施例１（または実施例２）との違いを、図２２を用いて概説する。実施例３に係るデータ処理システムでは、インポートファイルが検索対象となる契機が、実施例１または２と異なる。図２２は、インポートファイル３２（このファイル名を“aaa.csv”とする）が記憶装置４に格納されてから、インポート対象のテーブル３００（テーブル名称を“USER1.T1”とする）に格納されるまでの流れ、そして各時点における検索対象を実施例ごとに示した概念図である。また、ここでの説明において、ユーザから発行されるクエリは、テーブル“USER1.T1”内のレコードを検索するクエリ（たとえば図１３に示されたクエリ）とする。【０１４４】
図２２（ａ）では、時刻ｔ０にデータソース８から記憶装置４にインポートファイル３２が格納され、そして時刻ｔ２に（ｔ２＞ｔ０である）、テーブル３００へのインポートが行われる例が示されている。もし時刻ｔ２以降（たとえば図２２（ｂ）における時刻ｔ１’）にユーザからクエリを受け付けると、実施例１〜３に係るデータ処理システムはいずれも、テーブル３００及びインポートファイル３２を検索対象とし、テーブル３００内のレコード及びインポートファイル３２内のレコードの両方がユーザに出力される。【０１４５】
一方、時刻ｔ２（インポート処理が開始される時）より前にユーザからクエリを受け付けた場合、たとえば時刻ｔ１（なおｔ１は、ｔ０＜ｔ１＜ｔ２の関係にある）にクエリを受け付けた場合、実施例１または２に係るデータ処理システムは、テーブル３００だけを検索対象とし、インポートファイル３２内のレコードは検索されない。インポート処理は定期的に実行される処理のため、インポートファイル３２が記憶装置４に格納されてから即座にインポート処理が開始されるわけではない。そのためインポートファイル３２が記憶装置４に格納されても、ユーザはインポートファイル３２内のレコードにアクセスできない時間がある。【０１４６】
しかし実施例３に係るデータ処理システムは、検索要求を受け付けた時にステップ２３０１やステップ２３０２の処理を行い、インポートファイル３２が新たに格納されたか、あるいはインポートファイル３２の更新が行われた場合には、クエリ書き換え処理を行うことで、インポートファイル３２を検索対象にする。そのためユーザは、インポートファイル３２が記憶装置４に格納されると即座にインポートファイル３２内のレコードにアクセスすることができる。【０１４７】
ここまでで、いくつかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。【０１４８】
たとえば上で説明した実施例に係るデータ処理システムでは、ＤＢサーバとは別にクライアントが設けられ、ユーザはクライアントの入力装置及び出力装置を用いる例が説明された。ただし、クライアントを設けることは必須ではなく、ＤＢサーバでクライアントプログラムが実行される構成にしてもよい。その場合ユーザは、ＤＢサーバの入出力デバイスを用いて、情報検索のリクエストを発行するとよい。【０１４９】
また、ＤＢサーバの台数は１台に限定されない。データ処理システムに複数のＤＢサーバを設けて、検索処理等を複数のＤＢサーバで並列実行させるようにしてもよい。【０１５０】
上で説明された各種プログラムは、プログラム配布サーバや計算機が読み取り可能な記憶メディアによって提供され、プログラムを実行する各装置にインストールされてもよい。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、例えばＩＣカード、ＳＤカード、ＤＶＤ等の不揮発性記憶媒体である。【０１５１】
また、上の実施例で説明されたプログラムの一部または全ての処理は、専用ハードウェアによって実現されてもよい。
【符号の説明】
【０１５２】
１：サーバ、２：クライアント、３，４：記憶装置、５：ＳＡＮ、６：ＬＡＮ、７：ＷＡＮ、８：データソース
【図１】
0006608544.tif 000002
【図２】
0006608544.tif 000003
【図３】
0006608544.tif 000004
【図４】
0006608544.tif 000005
【図５】
0006608544.tif 000006
【図６】
0006608544.tif 000007
【図７】
0006608544.tif 000008
【図８】
0006608544.tif 000009
【図９】
0006608544.tif 000010
【図１０】
0006608544.tif 000011
【図１１】
0006608544.tif 000012
【図１２】
0006608544.tif 000013
【図１３】
0006608544.tif 000014
【図１４】
0006608544.tif 000015
【図１５】
0006608544.tif 000016
【図１６】
0006608544.tif 000017
【図１７】
0006608544.tif 000018
【図１８】
0006608544.tif 000019
【図１９】
0006608544.tif 000020
【図２０】
0006608544.tif 000021
【図２１】
0006608544.tif 000022
【図２２】
0006608544.tif 000023
【図２３】
0006608544.tif 000024