JP6789799B2 - データ統合装置、データ統合システム、データ統合方法 - Google Patents

Description

本発明は、複数の情報ソースから収集したデータを統合し、統合したデータを利用して、ユーザサービスを実現させるようにしたデータ統合装置等に関する。

従来から、複数のシステム夫々からデータを収集して統合し、統合したデータをユーザ側端末のアプリケーションプログラムに提供するデータ統合装置が実現されている。複数の情報ソース夫々が互いに異なる種類のデータを管理していても、アプリケーション端末は、統合データを利用することによって、複数の情報ソースを横断した検索サービス等の融合サービスをユーザに提供することができる。この種のデータ統合装置として、例えば、特許文献１に記載されたものがある。

特許文献１に係るデータ統合装置は、ソースシステムに含まれる１つ以上のデータ項目と当該データ項目のデータ値の型を含む定義である物理データモデルと、利用者側アプリケーションで用いられる１つ以上のデータ項目と当該データ項目のデータ値の型を含む定義である論理データモデルと、前記論理データモデルのデータ項目と前記物理データモデルのデータ項目との対応関係を示すマッピング情報を記憶し、前記論理データモデルに対する検索条件を前記利用者側アプリケーションから受け付け、受け付けた検索条件と前記マッピング情報に基づいて、前記物理データモデルに対する検索条件を生成して、ソースシステムからデータを収集し、さらに、前記マッピング情報に基づいて、複数のソースシステムの夫々から収集したデータを統合することを特徴としている。

このデータ統合装置によれば、ユーザ側アプリケーション端末からの検索条件に応じて物理データモデルに対する検索条件が生成され、検索の都度、データがソースシステムから収集されるため、収集されるデータが刻々と変動するようなリアルタイムデータであっても、データの変動に対応しながらデータ統合を達成することができる。

特許第５７３３４３４号公報

ソースシステムによって実行されている業務の運用環境が変化すると、それに応じて、ソースシステムから収集されるデータ相互間の優劣等、データの意義や価値等データの属性も変化する。従来のデータ統合装置には、これに対する配慮がなされていないため、本発明は、収集されるデータの属性に変化が生じ得る状況であっても、アプリケーション端末がユーザサービスを提供するのに適した統合データを生成可能なデータ統合装置等を提供することを目的とする。

前記目的を達成するために、本発明は、複数の情報ソース夫々からデータを収集し、収集したデータに基づいて、アプリケーションデータを生成し、当該アプリケーションデータを端末装置に提供する、データ統合装置であって、前記アプリケーションデータを生成するためのプログラムを実行するコントローラと、制御情報を記録するメモリと、を備え、前記コントローラは、前記複数の情報ソース夫々について、データを収集するための情報ソース検索用クエリを生成し、前記複数の情報ソース検索用クエリを評価し、当該評価に基づいて、前記複数の情報ソース夫々からデータを収集し、当該収集したデータを前記制御情報としてのルールに基づいて推論して、前記アプリケーションデータを生成することを特徴とする。

本発明によれば、収集されるデータの属性に変化が生じ得る状況であっても、アプリケーション端末がユーザサービスを提供するのに適した統合データを生成可能なデータ統合装置等を提供することができる。

データ統合システムのブロック図の一例である。 データ統合装置のハードウェアブロック図である。 データ統合装置からアプリケーション端末に提供されるアプリケーションデータのデータフォーマット（テーブル）の一例である。 経路データモデルの一例としてのテーブルである。 座席情報としての座席（空席）データモデル一例に係るテーブルである。 座席（空席）データモデルの一例に係るテーブルである。 クエリ評価基準格納テーブルの一例である。 推論ルール格納テーブルの一例である。 データ統合装置が、アプリケーションデータをユーザ側端末に送信するまでの動作を示すフローチャートの一例である。 情報ソースに対するクエリを生成するステップの詳細を示すフローチャートの一例である。 クエリを評価するステップの詳細を示すフローチャートの一例である。 ユーザ側端末にインストールされている経路・空席検索アプリケーションプログラムのＧＵＩの一例である。 端末からデータ統合装置に送信されるクエリの一例である。 “経路”に対するソースクエリの一例である。 “空席”モデルに対するソースクエリの一例である。 “空席”モデルに対するソースクエリの他の例である。 空席管理サーバに対するソースクエリ（再生成後のクエリ）の一例である。 空席管理サーバに対するソースクエリ（再生成後のクエリ）の他の例である。 経路空席検索結果の情報の表示例である。 ソークエリに対応した“座席”モデルに係るテーブルの他の例である。 ソークエリに対応した“座席”モデルに係るテーブルのさらに他の例である。 座席管理データベースの“座席”モデルの一例に係るテーブルである。 座席管理データベースの“座席”モデルの他の例に係るテーブルである。 経路モデルに対するソースクエリ（再生成後のクエリ）の一例である。 経路データモデルの他の例としてのテーブルである。 経路空席モデルの一例である。 経路空席検索結果情報の他の表示例である。

本発明に係るデータ統合装置は、例えば、複数の情報ソースにデータが分散されている環境に適用される。さらに詳しくは、列車を管理するシステムでは、複数の情報管理サーバが運用されており、複数の種類の情報を利用して様々な旅客用案内サービスが提供されている。この種のサービスとして、経路検索サーバの列車運行情報を利用した経路検索サービス、座席管理サーバの座席情報を利用した空席予約サービスがある。データ統合装置は、経路情報と座席情報とを統合し、統合データをユーザ側端末装置のアプリケーションプログラムに提供して、ユーザが統合サービス（経路・空席検索）を利用できるようにしている。

データ統合装置を利用するシステムは、データの元となる情報ソースの持つデータベースからデータを抽出し、ユーザ側端末のアプリケーションプログラムが利用しやすい形に加工（統合）し、ユーザ側端末にロードするというステップを行うことから、ＥＴＬシステムに対応するものでもある。

図１は、データ統合システム１０のブロック図の一例である。データ統合システム１０は、データ統合装置１００と、ユーザ側端末（アプリケーション端末）１３０と、情報ソース１４０とを備える。ユーザ側端末１３０と情報ソース１４０とは、夫々、ネットワーク１６０を介して、データ統合装置１００に接続される。

ユーザ側端末１３０は、スマートフォン、パソコン等のコンピュータ端末でよい。ユーザ側端末１３０には、例えば、経路・空席検索のための旅客案内用のアプリケーションプログラムがインストールされている。

情報ソース（ソースシステム）１４０は、データベース等のデータ群を管理する管理サーバであり、例えば、列車の運行管理サーバ、及び、列車の座席管理サーバである。列車の運行管理サーバは、列車の運行管理情報データベースを備え、列車の座席管理サーバは座席管理情報データべースを備える。複数の情報ソース１４０が、ネットワーク１６０を介して、データ統合装置１００に接続される。データ統合装置１００は、経路検索サーバ、そして、列車座席予約サーバ夫々から収集したデータを統合し、統合データ（アプリケーションデータ）をユーザ側端末１３０に提供するサーバであってよい。

管理システム１０は、複数の鉄道事業者の管理サーバを網羅するものであってよい。複数の鉄道事業者によって、経路検索サーバ、そして、座席管理サーバが別々に運用されることがあるが、データ統合装置１００は、複数の事業者夫々の管理サーバに接続してデータを収集することができる。

データ統合装置１００は、通信モジュール１２０と、管理用ユーザインタフェースモジュール１２１と、クエリ生成モジュール１０１と、クエリ評価モジュール１０２と、クエリ実行モジュール１０３と、データ推論モジュール１０４と、データ格納モジュール１１０と、を備える。モジュールとは、データ統合を実現するための諸機能の一つ、又は、複数であり、プログラム、及び／又は、ハードウェアによって実現される。モジュールをユニット、又は、手段に言い換えてもよい。

通信モジュール１２０は、ネットワーク１６０を介して、ユーザ側端末１３０と情報ソース１４０夫々と通信して、データを送受信する。ユーザ側端末１３０のアプリケーションプログラムは、データ統合装置１００に、論理データモデルに基づいてデータ検索用クエリ（アプリケーションクエリ）を送信する。アプリケーションクエリとしては、例えば、経路・空席検索クエリがある（後述の図１０Ａ参照）。

データ統合装置１００はデータ検索クエリを受け付けると、アプリケーションのデータモデルと情報ソースのデータモデルとの間の対応関係であるマッピング情報（後述の推論ルール）に基づいて、複数の情報ソース１４０夫々に対するデータ検索クエリ（ソースクエリ）を生成する（クエリ生成モジュール１０１）。データ統合装置１００のクエリ評価モジュール１０２は、生成した複数のソースクエリを評価する。クエリ実行モジュール１０３は、評価結果に基づいて複数の情報ソース１４０の夫々にクエリを送信する。

データ統合装置１００のデータ推論モジュール１０４は、ソースクエリによって情報ソース１４０から収集したデータモデル（ソースデータ）を、推論ルール１１２にしたがって、ユーザ側端末のアプリケーションプログラム用のデータモデル（アプリケーションデータ）に推論、即ち、複数のソースデータを統合してアプリケーションデータを生成する。データ統合装置１００は、このアプリケーションデータを、アプリケーションクエリの実行結果として、ユーザ側装置１３０のアプリケーションプログラムに送信する。なお、アプリケーションデータを統合データと呼ぶこともある。

“推論”とは、入力データから出力データを得るための処理を意味し、既述のとおり、入力データは、複数の情報ソース１４０から収集されたソースデータであり、出力データは、アプリケーションデータである。推論のためのルールを“推論ルール”という。複数のソースデータを統合するという推論ルールは，ＳＱＬにおける、テーブル結合（ジョイン）と同じである。

データ格納モジュール１１０は、データ統合のための管理データ、例えば、複数のソースクエリを評価するための基準（クエリ評価基準格納テーブル１１１）と、既述の推論のルール（推論ルール格納テーブル１１２）と、を格納する。さらに、データ格納モジュール１１０は、中間データ（アプリケーションデータを生成するためのデータ、即ち、ソースデータ）を格納する中間データ格納テーブル１１３を備える。

モジュール１２１は、管理端末（管理計算機）１５０に、データ統合のための管理用ユーザインタフェースを提供する。管理端末１５０は、例えば、クエリ評価基準格納テーブル１１１と推論ルール格納テーブル１１２とを設定する、又は、これらテーブルを更新する等の管理処理を、管理用ユーザインタフェースモジュール１２１を介して、データ統合装置１００に適用する。

通信モジュール１２０は、例えば、ネットワークカードである、データ格納モジュール１１０は、記憶モジュールとしてのメモリ（非一時的記録媒体）である。ユーザ側端末１３０は、通信モジュール１３１と、記憶モジュール１３２と、制御モジュール１３３と、表示モジュール１３４と、入力モジュール１３５とを備える。制御モジュール１３３は、アプリケーションプログラムによる制御機能を備える。表示モジュール１３４は、例えば、液晶表示装置である。入力モジュール１３５は、例えば、ユーザからの入力を受けるタッチパネルである。情報ソース１４０も、通信モジュール１４１と、記憶モジュール１４２と、制御モジュール１４３とを備える。

図１Ｂに、データ統合装置１００のハードウェアブロック図を示す。データ統合装置１００は、サーバシステムとして構成されてよく、プロセッサ、又は、コントローラ１２としてのＣＰＵと、更新処理を実行するための制御プログラムや制御用データを記録するメモリ１４（非一時的記録媒体）と、各種データ及びデータベースを記録するストレージ装置１６と、を備える。

ストレージ装置１６は、データ統合装置１００に内蔵されるハードディスク等、及び／又は、ネットワーク１６０に接続されたストレージシステム、データセンタであってよい。プロセッサ１２は、制御プログラムを実行することによって、既述のモジュール（１０１〜１０４）を実現する。クエリ評価基準格納テーブル１１１、推論ルーツ格納テーブル１１２は、中間データ格納テーブル１１３は、メモリ１４又はストレージ装置１６に格納される。

データ統合装置１００からユーザ側端末１３０に提供されるアプリケーションデータは、例えば、図２に示すデータフォーマット（テーブル）１５００のように構成される。アプリケーションデータは、経路データモデルと座席データモデルとが統合された経路座席データモデルであり、その項目には、経路ＩＤ（１５０１）と、経路乗車駅（１５０２）と、経路降車駅（１５０３）と、乗車時刻（１５０４）と、経路順序（１５０５）と、列車ＩＤ（１５０６）と、乗車駅（１５０７）と、降車駅（１５０８）と、空席（１５０９）と、料金（１５１０）とがある。

データ統合装置１００は、経路検索サーバ（第１の情報ソース１４０）から経路データモデルを収集する。経路検索サーバは、データ統合装置１００からのソースクエリに応答して、記憶モジュール１４２の列車運行管理データベースに記録されている物理データモデルに基づいて、経路データモデルを生成してデータ統合装置１００に送信する。図３は、経路データモデルの一例としてのテーブルである。

図３のテーブル９００は、経路ＩＤ（９０１）と、出発駅（９０２）と、目的駅（９０３）と、出発時刻（９０４）と、経路順序（９０５）と、列車ＩＤ（９０６）と、乗車駅（９０７）と、降車駅（９０８）とを含む。

データ統合装置１００は、座席管理サーバ（第２の情報ソース１４０）から座席（空席）データモデルを収集する。座席管理サーバは、データ統合装置１００からのソースクエリに応答して、記憶モジュール１４２の座席管理データベースに基づいて、座席データモデル生成してデータ統合装置１００に送信する。図４Ａは、Ａ社の座席管理サーバによって生成された、座席情報としての座席（空席）データモデル１０００の一例に係るテーブル、図４Ｂは、Ｂ社の座席管理サーバによって生成された、座席（空席）データモデル１１００の一例に係るテーブルである。

Ａ社は出発駅“八重洲”から、途中駅“原田町”の間で列車を運行し、Ｂ社は、途中駅“原田町”から目的駅“吉田町”までの間で列車を運行する。ユーザ側端末１３０のユーザが、出発駅“八重洲”から目的駅“吉田町”までの経路と座席を検索すると、検索される経路の情報は、出発駅“八重洲”から乗換駅“原田町”までの列車情報（列車ＩＤと乗降時間）と、乗換駅“原田町”から目的駅“吉田町”までの列車情報（列車ＩＤと乗降時間）とから構成される。

そして、検索される座席の情報は、Ａ社の路線（“八重洲”から“原田町”）の座席データ（図４Ａ）と、Ｂ社の路線（“原田町”から“吉田町”）の座席データ（図４Ｂ）とである。

図４Ａに示すテーブル１０００は、列車ＩＤ（１００１）と、乗車駅（１００２）と、降車駅（１００３）と、空席（１００４）と、料金（１００５）とを含み、図４Ｂに示すテーブル１１００は、列車ＩＤ（１１０１）と、乗車駅（１１０２）と、降車駅（１１０３）と、空席（１１０４）と、料金（１１０５）とを含む。

なお、経路検索サーバは、Ａ社の列車運行情報と、Ｂ社の列車運行情報と、を統合して管理する。二つの路線をＡ社の路線とＢ社の路線として説明したが、二つの路線がＡ社に属する第１の路線と第２の路線であってもよい。

クエリ評価基準格納テーブル（１１１）とは、クエリ生成モジュール１０１が、アプリケーションクエリに基づいて生成した、複数の情報ソース１４０の夫々に対するソースクエリについて、複数のソースクエリ相互間の優劣を規定する指標である。クエリ実行モジュール１０３は、優先度が高いクエリから実行し、そのクエリによって、情報ソース１４０からデータモデルを収集する。そして、アプリケーションクエリと収集したデータ（或いは、データモデル）とに基づいて、優劣判断によって実行されなかった他のクエリに代えて、クエリを再生成することができる。換言すれば、実行されなかったクエリを、収集されたデータを利用して修正、補正する。クエリ実行モジュール１０３は、このような“２次クエリ”をクエリの送信対象である情報ソース１４０に適用する。

クエリを評価することが有用である理由について説明する。列車の管理データの態様、状況、形態等は列車の運行環境に依存して変動する。例えば、利用客が多い繁忙期、即ち、休日、祝日、週末、通勤通学時間帯等では空席が少なく、一方、利用客が少ない閑散期では、空席が十分にある。そこで、経路・空席検索に際して、閑散期では座席が容易に予約できるため、データ統合装置１００は、経路を座席よりも優先して情報ソースを検索すれば、ユーザには、座席を予約できる経路の候補を多様に提供でき、一方、利用客が多い繁忙期では、座席の予約が困難であるため、座席を経路よりも優先して検索することにより、座席が予約できる確かな経路をユーザに提示できる。このように、列車の運行環境や外部要因に応じて、ユーザに提供できる検索結果を変化させることの方が好ましく、かつ、検索を効率的に進めることができる。

そこで、クエリ評価モジュール１０２は、経路を検索するためのクエリと、座席を検索するクエリとを、列車の運行環境に基づく等して評価し、そして、夫々のクエリの優劣を判定し、クエリの優先度に基づいてクエリを実行することによって、情報ソース１４０から収集されるデータをユーザの要望に適した検索結果になるようにしている。クエリ評価モジュール１０２は、ソースクエリを、例えば、クエリ評価基準格納テーブル１１１を利用して評価する。

図５は、ソースクエリを評価するためのクエリ評価基準格納テーブル１１１の一例である。クエリ評価基準格納テーブル１１１は、情報ソース１４０に対するクエリを評価するための複数の基準を定義している。クエリ評価基準格納テーブル１１１は、基準毎のＩＤ：基準項目（１１１１）と、クエリへの基準の適用の要否を判定するための適用条件（１１１２）と、クエリ種別（１１１３）と、クエリに適用される評価点（１１１４）とを含む。クエリ評価基準テーブル１１１は、業務の状況（例えば、既述の繁忙期、又は、閑散期等）に応じて、データ項目（“空席”、“乗車駅”、“降車駅”等）毎に評価量（評価点）を規定する。なお、基準項目毎に、有効又は無効を設定することができる。

クエリ評価モジュール１０２は、複数のソースクエリ夫々について、評価要件（適用条件１１１２、クエリ種別１１１３）を判定して、評価点の適用の要否を決定する。評価点が高いほど、ソースクエリの優先度は高くなる。例えば、繁忙期（適用要件）では、列車座席の検索クエリの評価点を高くして、座席検索クエリが経路検索クエリよりも優先的に実行されるようにしている。

図６に推論ルール格納テーブル１１２の一例を示す。このテーブルは、データ統合装置１００のデータ推論モジュール１０４が複数の情報ソース１４０から夫々ソースデータを収集し、これからアプリケーションデータを生成するための規則を規定する。推論ルール格納テーブル１１２は、複数のルール毎のＩＤ（ルールＩＤ）１１２１と、頭部１１２２と、体部１１２３とを含む。

頭部１１２２は、アプリケーションデータのデータモデルを定義する。“経路空席”がデータの論理モデルであり、経路ＩＤ、順序、列車ＩＤ、乗車駅、降車駅、乗車時刻、空席、及び、料金が夫々データモデルのデータ項目である。

体部１１２３は、頭部１１２２のデータモデルを生成するためのサブモデルを定義するものであって、“経路”及び“座席”が夫々サブモデルである。サブモデルの論理和によって、頭部１１２２の“経路座席”のデータモデルが算出される。経路ＩＤ、順序、列車ＩＤ、乗車駅、降車駅、そして、乗車時刻は経路データモデルのデータ項目であり、列車ＩＤ、乗車駅、降車駅、空席、そして、料金が座席データモデルのデータ項目である。

データ推論モジュール１０４は、列車ＩＤ、乗車駅、そして、降車駅が同じ値のデータモデル（経路、座席）について論理和を適用して、“経路座席”のデータを算出する。なお、推論ルール格納テーブル１１２のデータモデル“経路座席”、“経路”、“座席”とは、複数のデータ項目と、各データ項目のデータ値との集合として定義された論理モデルである。

図７は、データ統合装置１００が、アプリケーションデータをユーザ側端末１３０に送信するまでの動作を示すフローチャートの一例である。クエリ生成モジュール１０１（図１）は、ユーザ側端末１３０のアプリケーションプログラムからクエリ（アプリケーションクエリ）を受信すると（５００）、情報ソース１４０へのデータ検索クエリ（ソースクエリ）を生成する（５０１）。図８は、ソースクエリを生成するステップ（５０１）の詳細を示すフローチャートの一例である。

アプリケーションクエリは、アプリケーションデータとしてのデータモデル“経路座席”（頭部：図６（１１２２））中の所定のデータ項目を用いて定義される検索条件である。クエリ生成モジュール１０１は、アプリケーションクエリで指定された情報をキーとして推論ルール格納テーブル１１２を検索し、当該キーを頭部１１２２に持つルールを抽出する。そして、クエリ生成モジュール１０１は、抽出したルールの体部１１２３に含まれる全てのサブモデルを入力モデルとしたリストを作成し、全ての入力モデル夫々に対するクエリを生成する（５０２１）。既述の推論ルール格納テーブル１１２（図６）を例にすると、“経路”、“座席”が夫々入力モデルである。

クエリ生成モジュール１０１は、全ての入力モデルのリストについてループ処理を行う（５０２２〜５０２４）。クエリ生成モジュール１０１は、ループ処理において、複数の入力モデルの夫々対してソースクエリを生成する（５０２３）。この結果、既述の推論ルール格納テーブル１１２（図６）を例にすると、第１の情報ソース（経路検索サーバ）に対する第１のソースクエリと、第２の情報ソース（座席管理サーバ）に対する第２のソースクエリとが生成される。なお、クエリ生成モジュール１０１は、推論ルール格納テーブル１１２以外の、例えば、一般の推論エンジンを用いて、ソースクエリを算出してもよい。

クエリ生成モジュール１０１が図７のステップ５０１（図８：５０２１〜２０２４）を終了すると、クエリ評価モジュール１０２は、クエリ生成モジュール１０１が生成したソースクエリを、既述のクエリ評価基準テーブル１１１を参照して、評価する（図７：５０２）。

図９は、クエリを評価するステップ（５０２）の詳細を示すフローチャートの一例である。クエリ評価モジュール１０２は、クエリ生成モジュール１０１から複数のソースクエリを受領すると、フローチャートを開始する。クエリ評価モジュール１０２は、複数のソースクエリの夫々ついてループ処理を適用する（図９：５０３１）。クエリ評価モジュール１０２は、ソースクエリについて、クエリ評価基準格納テーブル１１１を参照し、複数の基準が当てはまる場合には、夫々の基準についてループ処理を適用する（５０３２）。

クエリ評価モジュール１０２は、一つのソースクエリについて一つの評価基準を適用し、ソースクエリが、クエリ評価基準格納テーブル１１１（図５）の適用条件１１１２に一致するか否かを判定する（５０３３）。クエリ評価モジュール１０２は、一致しないことを判定すると（５０３３：ＮＯ）、次の評価基準の処理に移行する（５０３２）。クエリ評価モジュール１０２は、一致することを判定すると（５０３３：ＹＥＳ）、続いて、クエリの内容的要件（クエリ種別：１１１３）を判定する（５０３４）。

クエリ評価モジュール１０２は、クエリが種別要件に合致することをすると（５０３４：ＹＥＳ）を肯定すると、クエリの評価点に評価基準の得点１１１４を加算する（５０３５）。クエリ評価モジュール１０２は、ステップ５０３４を否定すると、ステップ５０３２に移行して、次の評価基準の処理を継続する。

クエリ評価モジュール１０２は、ステップ５０３３〜ステップ５０３５を繰り返し、全ての評価基準を処理すると（５０３６）、ステップ５０３７に移行し、全てのクエリについて、ループ処理を完了すると（５０３７）、図９のフローチャートを終了する。クエリ評価モジュール１０２は、複数クエリ夫々の評価点の合計に基づいて、複数クエリの間の優劣を設定、決定、判定する。

続いて、クエリ実行モジュール１０３は、クエリを実行するステップ５０３（図７）において、複数のクエリの中から優先度、即ち、クエリの評価点の合計が最も高いクエリを、当該クエリにとって検索となる情報ソース１４０に送信し、当該情報ソースからデータを収集する。

次いで、データ推論モジュール１０４は、ステップ５０４において、収集したソースデータに、推論ルール格納テーブル１１２のルールにしたがって、ジョインを適用する（推論の実行）。データ推論モジュール１０４は、ステップ５０４を終了すると、ステップ５０５に移行し、推論結果（アプリケーションデータ）が増えているか否かを判定する。

クエリ実行モジュール１０３が、評価点が最も高いクエリを情報ソースに送信してソースデータを収集した段階では、データ統合装置１００は、一つのデータモデルしか収集していないために、データ推論モジュール１０４は、ステップ５０５を否定判定して、ステップ５０１にリターンする。クエリ生成モジュール１０１は、アプリケーションクエリと収集したソースデータを利用してクエリを再度生成し、このクエリに基づいて収集したソースデータを既に収集されているソースデータと統合する（５０４）。

クエリ実行モジュール１０３が、複数のソースクエリを夫々の優先度に基づいて、順に実行する過程で、データ推論モジュール１０４は、複数のソースデータを継続的に統合してアプリケーションデータを生成する。データ推論モジュール１０４は、ステップ５０５において、前回の処理で得られたアプリケーションデータと、今回の処理で得られたアプリケーションデータとを比較して、アプリケーションデータ（推論結果）が増えていれば、データの統合はまだ途中であるとしてステップ５０５を否定判定し、ステップ５０１にリターンしてフローチャートを継続し、一方、ステップ５０５を肯定判定すると、アプリケーションデータは完成されてユーザ側端末１３０に提供されてよいとして、ステップ５０６に移行する。データ統合装置１００は、ユーザ側装置１３０にアプリケーションデータをアプリケーションプログラム用データとして送信し（５０６）、フローチャートを終了する。

次に、ここまでの説明に基づいて、データ統合装置１００の動作を具体的に説明する。図１０Ａは、ユーザ側端末１３０にインストールされている経路・空席検索アプリケーションプログラムのＧＵＩ８００の一例を示す。ユーザ側端末１３０の制御モジュール１３３は、記憶モジュール１３２に記憶されている経路・空席検索アプリケーションプログラムを起動すると、ＧＵＩ８００を表示モジュール１３４に表示させる。そして、制御モジュール１３３は、入力モジュール１３５へのユーザ入力をＧＵＩ８００に適用する。

データ検索用の項目は、ユーザ側端末１３０が関与するデータモデル“経路座席”に属するデータ項目から選択されてよい。ＧＵＩ８００は、出発駅を入力する領域８０１と、目的駅を入力する領域８０２と、経路、空席検索を開始させるための入力領域８０３と、を備える。ユーザが出発駅名と目的駅名を入力した後、領域８０３を操作すると、制御モジュール１３３は、ＳＱＬを利用して、アプリケーションクエリ８０４（図１０Ｂ）を生成し、これを、通信モジュール１３１を介して、データ統合装置１００に送信する。

クエリ生成モジュール１０１は、アプリケーションクエリを受信すると（図７：５００）、入力モデルのリストを生成する（図７：５０１、図８：５０２１）。クエリ生成モジュール１０１は、推論ルール格納テーブル１１２（図６）に基づいて、アプリケーションクエリに対応するサブモデル“経路”と“座席”を特定し、“経路”と“座席”とを入力モデルとしたリストを生成する。

次いで、クエリ生成モジュール１０１は、“経路”モデルと“座席”モデルとの夫々について、アプリケーションクエリに基づいて、ソースクエリを生成する（図８：５０２２〜５０２４）。図１１Ａは、“経路”に対するソースクエリ、即ち、経路検索サーバ（情報ソース１４０）に対するソースクエリ１２０１のＳＱＬを示す。このクエリ１２０１は、アプリケーションクエリ８０４（図１０Ａ）に基づいて、出発駅（八重洲）と、目的駅（吉田町）の情報を備えている。

図１１Ｂは“空席”モデルに対するソースクエリ１３０１（Ａ社の管理サーバに送信される）のＳＱＬを示し、図１１Ｃは“空席”モデルに対するソースクエリ１３０１（Ｂ社の管理サーバに送信される）のＳＱＬを示す。ソースクエリ１３０１のＳＱＬ（図１１Ｂ）は、アプリケーションクエリ８０４に基づいて、出発駅“八重洲”と、可能性のある“列車ＩＤ”と、“空席”とを備えている。ソースクエリ１４０１のＳＱＬ（図１１Ｃ）は、アプリケーションクエリ８０４に基づいて、目的駅“吉田町”と、“列車ＩＤ”と、“空席”とを備えている。

クエリ評価モジュール１０２は、ソースクエリ１２０１、１３０１、そして、１４０１の夫々を、クエリ評価基準テーブル１１１（図５）に基づいて評価する（図７：５０２、図９）。クエリ評価モジュール１０２は、ソースクエリ１２０１とクエリ評価基準テーブル１１１の夫々の基準と、を比較する。ソースクエリ１２０１は、“出発駅”と“空席”を含むために、クエリ評価基準テーブル１１１の基準ＩＤ：Ｃ０３と基準ＩＤ：Ｃ０４との二つの基準夫々について、クエリ評価モジュール１０２は、ステップ５０３３とステップ５０３４（図９）とを肯定し、ソースクエリ１２０１がこれら二つの基準に合致することを判定する。そして、クエリ評価モジュール１０２は、二つの基準夫々の点数“５０”を加算した値である“１００”をソースクエリ１２０１の基準点の合計として決定する（図９：５０３５）。

クエリ評価モジュール１０２は、ソースクエリ１３０１とクエリ評価基準テーブル１１１の夫々の基準と、を比較し、ソースクエリ１３０１は、“出発駅”と“空席”とを含むために、基準ＩＤ：Ｃ０２と基準ＩＤ：Ｃ０３との二つの基準について、ステップ５０３３とステップ５０３４（図９）とを肯定し、ソースクエリ１３０１がこれら二つの基準に合致することを判定する。

そして、クエリ評価モジュール１０２は、基準ＩＤ：Ｃ０２の評価点“１０”と、基準ＩＤ：Ｃ０３の評価点“５０”とを加算した値である“６０”をソースクエリ１３０１の合計点として決定する（図９：５０３５）。

さらに、クエリ評価モジュール１０２は、ソースクエリ１４０１とクエリ評価基準テーブル１１１の夫々の基準と、を比較し、ソースクエリ１３０１は、“降車駅”と“空席”とを含むために、基準ＩＤ：Ｃ０２と基準ＩＤ：Ｃ０４との二つの基準について、ステップ５０３３とステップ５０３４（図９）とを肯定し、ソースクエリ１４０１がこれら二つの基準に合致することを判定する。

そして、クエリ評価モジュール１０２は、基準ＩＤ：Ｃ０２の評価点“１０”と、基準ＩＤ：Ｃ０４の評価点“５０”とを加算した値である“６０”をソースクエリ１４０１の合計点として決定する（図９：５０３５）。なお、クエリ評価モジュール１０２は、ユーザ側端末１３０による検索の実行（図１０Ａ）が閑散期に行われたものとして、基準ＩＤ：Ｃ０２に対するステップ５０３３（図９）の判断を肯定している。

クエリ実行モジュール１０３は、ソースクエリ１２０１、１３０１、そして、１４０１とを互いに比較して、評価点が最も高いソースクエリ１２０１を優先して実行する（図７：５０３）。クエリ実行モジュール１０３は、ソースクエリ１２０１を経路検索サーバ（情報ソース１４０）に送信する。経路検索サーバ（情報ソース１４０）の制御モジュール１４３は、通信モジュール１４１を介してソースクエリ１２０１を受けると、ソースクエリ１２０１に基づいて記憶モジュール１４２の列車運行管理データベース（物理モデル）を検索して、出発駅が“八重洲”であり、目的駅が“吉田町”である“経路”モデル９００（推論ルールテーブル１１２（図６）の体部１１２３の経路データモデルに相当する図３のテーブル）を生成し、これをデータ統合装置１００に送信する。

そして、データ推論モジュール１０４がステップ５０５（図７）を否定判定することにより、クエリ生成モジュール１０１は、クエリ生成を再度行う（図７：５０１）。クエリ生成モジュール１０１は、アプリケーションクエリ８０４（図１０Ｂ）と“経路”データモデル９００とに基づいて、Ａ社の空席管理サーバに対するソースクエリと、Ｂ社の空席管理サーバに際するソースクエリとを、再度生成する。図１１Ｄは、Ａ社の空席管理サーバに対するソースクエリ１３０２（再生成後のクエリ）のＳＱＬを示し、図１１Ｅは、Ｂ社の空席管理サーバに対するソースクエリ１４０２（再生成後のクエリ）のＳＱＬを示す。

クエリ生成モジュール１０１は、“経路”モデル９００（図３）を参照することによって、これに含まれる乗換駅“原町田”を認識し、これを含めて空席管理サーバに対するクエリを生成することができる。この事は、再生成前のクエリと再生成後のクエリとを比較すると容易に理解される（クエリ１３０１と１３０２との比較、クエリ１４０１と１４０２との比較）。

クエリ評価モジュール１０２は、クエリ評価基準格納テーブル１１１（図５）を参照して、ソースクエリ１３０２と１４０２とを夫々評価する。その結果、スースクエリ１３０２及び１４０２は共に評価点が“１００”になるため、クエリ実行モジュール１０３は、ソースクエリ１３０２をＡ社の座席管理サーバ（情報ソース１４０）に送信し、ソースクエリ１４０２をＢ社の座席管理サーバ（情報ソース）に送信する。これら情報ソース１４０の制御モジュール１４１は、通信モジュール１４１を介して、ソースクエリを受信すると、ソースクエリに基づいて、記憶モジュール１４２の座席管理データベース（物理モデル）を検索して、ソースクエリ１３０２，１４０２の夫々対応する“座席”モデル（推論ルールテーブル１１２（図６）の体部１１２３の座席データモデルに相当するテーブル１０００（図４Ａ）、同テーブル１１００（図４Ｂ））を生成する。

データ推論モジュール１０４は、ステップ５０４（図７）によって、“経路”モデル９００（図３）、“座席”モデル１０００（図４Ａ）、“座席”モデル１１００（図４Ｂ）を、推論ルール格納テーブル１１２の頭部１１２２のルールにしたがってジョインし（テーブル統合）、ステップ５０５を経て、アプリケーションデータ（“経路空席”モデル１５００：図２）を構成し、ユーザ側端末１３０に、アプリケーションクエリ８０４（図１０Ｂ）の応答として送信する。

ユーザ側装置１３０の制御モジュール１３３は、アプリケーションデータに基づいて、経路空席検索結果のビジュアル情報を、表示モジュール１３４に表示する。図１２は、経路空席検索結果の情報の表示例である。図１２によれば、経路空席の候補が５件あることが提示され、そして、５件の候補のうちの１件の系統図が提示される。

経路・座席の統合モデルを検索する場合、閑散期では、座席に余裕があるために、経路モデルの検索を優先することができ、経路検索の結果に基づいて座席検索を進めればよい。この結果、ユーザが所望する経路について座席を提示することができると共に、座席モデルの検索数を制限できるために、検索を効率よく進めながら、データ量を制限してネットワーク負荷を抑えることができる。

既述の説明は、列車運行の閑散期における経路・空席検索に関するものであったが、以下説明するのは、列車運行の繁忙期における経路・空席検索に関するものである。

列車運行の繁忙期では、予約可能な座席数が減少するため、経路・空席検索に際しては、経路検索よりも空席検索を優先し、空席がある列車について経路検索を行う方が、座席を確保しようとするユーザの要望に適することは先に説明したとおりである。そこで、データ統合装置１００は、座席検索のためのクエリを経路検索のためのクエリよりも優先されるように、前者のクエリの評価点を高くしている。

データ統合装置１００のクエリ生成モジュール１０１は、アプリケーションクエリ８０４（図１０Ｂ）に基づいて、ソースクエリ１２０１（図１１Ａ）、ソースクエリ１３０１（図１１Ｂ）、ソースクエリ１４０１（図１１Ｃ）とを生成する。そして、クエリ評価モジュール１０２は、これらクエリを、クエリ評価基準格納テーブル１１１を参照して評価する。

ソースクエリ１３０１は、クエリに“出発駅”と“空席”を含むため、基準ＩＤのＣ０１（繁忙期）とＣ０３に合致し（図５）、ソースクエリ１３０１の評価点は合計で１５０になる。ソースクエリ１４０１は、クエリに“目的駅”と“空席”を含むため、基準ＩＤのＣ０１（繁忙期）とＣ０４に合致し、これも１５０点として評価される。一方、ソースクエリ１２０１は、クエリに、空席を含まず、乗車駅と目的駅を含むため、繁忙期か閑散期かに拘わりなく、基準ＩＤのＣ０３とＣ０４に合致し、１００点として評価される。

クエリ実行モジュール１０３は、ソースクエリ１２０１、１３０１、そして、１４０１を互いに比較して、評価値がもっと高いソースクエリ１３０１と１４０１とを、ソースクエリ１２０１よりも優先して実行する（図７：５０３）。クエリ実行モジュール１０３は、ソースクエリ１３０１をＡ社の座席管理サーバ（情報ソース１４０）に送信し、ソースクエリ１４０２をＢ社の座席管理サーバ（情報ソース１４０）に送信する。これら情報ソース１４０の制御モジュール１４３は、通信モジュール１４１を介して、ソースクエリを受信すると、ソースクエリに基づいて記憶モジュール１４２の座席管理データベースを検索して、ソークエリに対応した“座席”モデル（図１３のテーブル１９１０、図１４のテーブル２０１０）を生成する。情報ソース１４０の通信モジュール１４１は、データ統合装置１００に“座席”モデルを送信する。

図１５は、Ａ社の座席管理サーバ（情報ソース１４０）の座席管理データベースの“座席”モデル１７００を示し、列車運行が繁忙期にあることから、座席に余裕が少ないことが分かる。Ａ社の座席管理サーバの制御モジュール１４３は、座席管理データベースから空席がある列車（ＩＤ：Ｔ０２）の管理データを抽出、選択、決定等して座席に余裕がある“座席”モデル（図１３：１９１０）を生成する。

図１６は、Ｂ社の座席管理サーバ（情報ソース１４０）の座席管理データベースの“座席”モデル１８００を示し、列車運行が繁忙期にあることから、座席に余裕が少ないことが分かる。Ｂ社の座席管理サーバの制御モジュール１４３は、座席管理データベースから空席がある列車（ＩＤ：Ｕ０２）の管理データを抽出、選択、決定等して座席に余裕がある“座席”モデル（図１４：２０１０）を生成する。なお、情報ソース１４０がソースクエリに対応する管理情報をデータ統合装置１００に送信し、データ統合装置１００がデータモデルを生成してもよい。

そして、データ推論モジュール１０４がステップ５０５（図７）を否定判定することにより、クエリ生成モジュール１０１は、先に実施されなかった経路検索クエリ（１２０１：図１１Ａ）を再生する（図７：５０１）。クエリ生成モジュール１０１は、アプリケーションクエリ８０４（図１０Ｂ）と、“座席”モデル１９１０（図１３）と、“座席”モデル２０１０（図１４）と、に基づいて、経路検索サーバへのソースクエリを生成する。図１７は、このソースクエリ２１０２のＳＱＬである。このＳＱＬをクエリ１２０１として示したＳＱＬ（図）１１Ａ）と比較すると、前者のＳＱＬによって、経路検索の対象を座席予約が可能な列車（Ｔ０２：図１３、Ｕ０２：図１４）に絞れることが分かる。

クエリ実行モジュール１０３は、ソースクエリ２１０２（図１７）を経路検索サーバ（情報ソース１４０）に送信する。経路検索サーバの制御モジュール１４３は、通信モジュール１４１を介してソースクエリ２１０２を受けると、ソースクエリ２１０２に基づいて記憶モジュール１４２の列車運行管理データベースを検索して、出発駅が“八重洲”であり、目的駅が“吉田町”であり、列車ＩＤがＴ０２、又はＵ０２である“経路”モデル２１１０（図１８）を生成してデータ統合装置１００に送信する。

データ推論モジュール１０４は、ステップ５０４（図７）によって、“経路”モデル２１１０（図１８）、“座席”モデル１９１０（図１３）、“座席”モデル２０１０（図１４）を、推論ルール格納テーブル１１２の頭部１１２２のルールにしたがって、“経路”モデルと“座席”モデルとのジョイン（テーブル結合）を行い、ステップ５０５を経て、アプリケーションデータ（“経路空席”モデル：２２００（図１９））を生成して、ユーザ側端末１３０に、アプリケーションクエリ８０４（図１０Ｂ）の応答として送信する。

ユーザ側端末１３０の制御モジュール１３３は、アプリケーションデータに基づいて、経路空席検索結果の情報を、表示モジュール１３４に表示する。図２０は、経路空席検索結果の情報２３０１の表示例である。図２０によれば、経路空席の候補が１件あることが提示され、その１件の系統図が提示されている。なお、ユーザ側端末１３０は、アプリケーションデータを、データ統合装置１００から論理モデルとして受け取るため、情報ソースの１４０の物理データを二重に管理する必要はない。

既述の実施形態は、本発明の例であって、本発明は、実施形態に限定されない。データ統合装置１００は、列車の運行を管理するシステムに適用される他、ユーザが購入を望む商品を検索するシステム等、複数の情報を統合しながら各種の検索を行うような各種の検索システムに適用することができる。

１０ データ統合システム
１００ データ統合装置
１３０ アプリケーション端末
１４０ 情報ソース
１５０ 管理端末
１６０ 通信ネットワーク

Claims (4)

1. 複数の情報ソース夫々からデータを収集し、
   収集したデータに基づいて、アプリケーションデータを生成し、
   当該アプリケーションデータを端末装置に提供する、
   データ統合装置であって、
   コントローラと、
   メモリと、
   を備え、
   前記コントローラは、前記メモリに記録されたプログラムを実行することによって、
   前記端末装置から送信されたクエリから、前記複数の情報ソース夫々に対する検索用クエリを生成し、
   前記メモリに記録された評価基準に基づいて、前記複数の検索用クエリの夫々を評価し、評価が最も高い検索用クエリを他の検索用クエリより優先して実行して、前記評価が最も高い検索用クエリのデータ収集対象である情報ソースからデータを収集し、
   当該収集されたデータと前記端末装置から送信されたクエリとに基づいて、前記複数の情報ソースのうち当該データの収集対象である情報ソース以外の情報ソースに対する検索用クエリを再作成し、
   当該再作成された検索用クエリを実行し、
   前記評価が最も高い検索用クエリに基づいて収集したデータと前記再作成された検索用クエリに基づいて収集したデータとを前記メモリに記録されたルールに基づいて統合して前記アプリケーションデータを生成し、
   当該アプリケーションデータに基づく出力を前記複数の情報ソースに対する検索結果として前記端末装置に実行させ、
   前記複数の検索用クエリの夫々を前記ルールに基づいて生成する、
   データ統合装置。
2. 前記ルールにおいて、前記収集されるデータのデータモデルと前記アプリケーションデータのデータモデルとの対応関係が規定され、前記端末装置は当該アプリケーションデータのデータモデルのデータ項目に基づいて、当該端末装置から送信される前記クエリを生成する、
   請求項１記載のデータ統合装置。
3. 請求項１記載の複数の情報ソースと、
   請求項１記載の端末装置と、
   請求項１記載のデータ統合装置と、
   を備える、
   データ統合システム。
4. サーバが、
   複数の情報ソース夫々からデータを収集し、
   収集したデータに基づいて、アプリケーションデータを生成し、
   当該アプリケーションデータを端末装置に提供する、
   データ統合方法であって、
   前記サーバは、
   前記端末装置から送信されたクエリから、前記複数の情報ソース夫々に対する検索用クエリを生成し、
   メモリに記録された評価基準に基づいて、前記複数の検索用クエリの夫々を評価し、評価が最も高い検索用クエリを他の検索用クエリより優先して実行して、前記評価が最も高い検索用クエリのデータ収集対象である情報ソースからデータを収集し、
   当該収集されたデータと前記端末装置から送信されたクエリとに基づいて、前記複数の情報ソースのうち当該データの収集対象である情報ソース以外の情報ソースに対する検索用クエリを再作成し、
   当該再作成された検索用クエリを実行し、
   前記評価が最も高い検索用クエリに基づいて収集したデータと前記再作成された検索用クエリに基づいて収集したデータとを前記メモリに記録されたルールに基づいて統合して前記アプリケーションデータを生成し、
   当該アプリケーションデータに基づく出力を前記複数の情報ソースに対する検索結果として前記端末装置に実行させ、
   前記複数の検索用クエリの夫々を前記ルールに基づいて生成する、
   データ統合方法。

Images