JP2019125346A - グリッドインターフェースに基づくデータ入出力システム - Google Patents

Abstract

【課題】グリッドインターフェースに基づくデータ入出力システムを提供する。【解決手段】本発明は、グリッドインターフェースに基づくデータ入出力システムであって、マトリクスサーバ３０は、データベースからデータセットを要請するデータ要請部と、要請したデータセットをグリッドインターフェースに表示するグリッド表示部と、グリッド上において、レコードのうちの一部のデータを更新し、更新されたレコード及び更新種類を更新内容として書き込むグリッド更新部と、目的フィールドにおけるキーフィールド及び各目的フィールドに対するグリッド上のフィールドとのマッピングを設定することにより、反映計画を設定する反映計画設定部と、反映計画により、グリッドの更新内容をデータテーブルに反映するためのクエリ文を作成し、作成されたクエリ文を前記データベースに実行するように要請する反映計画実行部と、を備える。【選択図】図２

Description

本発明は、データベースから抽出したデータセットをウェブ上のグリッドインターフェースに提供し、グリッドの更新内容をデータテーブルに反映するための計画設定手段を提供し、設定された反映計画により更新されたグリッドの内容をデータテーブルに反映する、グリッドインターフェースに基づくデータ入出力システムに関する。

一般に、ウェブ上でデータベースを更新（アップデート）するためには、データベースを処理するウェブプログラムと、これを指示するためのクエリ文が必要である。すなわち、データベース管理システムにおいて構造化問い合わせ言語（ＳＱＬ：Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）のレベルにより更新演算が行われる（例えば、下記の特許文献１参照）。

具体的に、データベースに特定のテーブルに書き込まれたデータを入力したり、修正または削除したりするためには、ジャバサーバーページ（ＪＳＰ：Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）、アクティブサーバーページ（ＡＳＰ：Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ）、ハイパーテキストプレプロセッサ（ＰＨＰ：Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ）等のサーバ側のウェブプログラムを用いて更新を行う。具体的に、前記サーバ側のウェブプログラムはデータベースと接続し、対象テーブルのデータを処理するための構造化問い合わせ言語（ＳＱＬ）文等のクエリ文を作成せねばならない。作成されたクエリ文をデータベースに送信し、当該クエリを処理するように要請すると、データベースは受信した当該クエリを処理することにより、データベース内のテーブルが更新される。

このため、上述したウェブプログラムがデータベースのクエリ文を処理するために、それぞれのテーブルまたは当該項目別のウェブ画面を構成せねばならない。また、対象テーブルの個数だけ入力画面を別途に開発せねばならないという問題がある。この理由から、それぞれのクエリ文も開発者が自ら作成せねばならないため、多大な時間及び工数がかかるという問題がある。なお、作成された画面でも単件データまたは少量のデータしか取り扱うことができず、大量のデータの処理には不便さがあり、しかも、処理に長い時間がかかる。

このために、データベースをより効率よく修正するために、ネットワークに基づいて遠隔データベースをローカルで修正する様々な技術が提案されている。例えば、ユーザ装置上で多次元データベースのうちの一部をキャッシングして修正し、これを多次元データベースに反映して、データベースを修正する技術が提案されている（例えば、下記の特許文献２参照）。また、周期的にサンドファイル等の特定のファイルフォーマットを用いて更新する技術が提案されている（例えば、下記の特許文献３参照）。更に、部分データベースにおいてサブセットデータベースの更新を処理する技術が提案されている（例えば、下記の特許文献４参照）。

しかしながら、前記した先行技術等は、いずれもデータベースの一部である他のデータベースを修正して、これを母データベースに反映する技術である。このため、ローカルでもデータベースを構成して処理せねばならないという問題がある。すなわち、ローカルユーザは、データベースを取り扱う知識を有さなければならないという問題がある。

また、多数のデータテーブルを一つのワークシートに表示し、ワークシートの修正事項を多数のデータテーブルに更新させる技術が提案されている（例えば、下記の特許文献５参照）。また、スプレッドシートのインタフェースを用いてデータベースを更新する技術が提案されている（例えば、下記の特許文献６、７参照）。

しかしながら、前記した先行技術は、データベースから取り出されたデータテーブルの内容を直接更新する。すなわち、スプレッドシートまたはワークシートに表示されたデータセットは、データベースから取り出されたデータテーブルのデータであり、スプレッドシートまたはワークシートの変更された内容を当該データテーブルに直接反映して更新させる。ところが、実務では、データベースのテーブルを直接更新するよりも、当該データを加工して分析したり、新たなテーブルを作ったりすることがさらに多い。

したがって、取り出されたデータセットの更新内容を反映するための計画を簡単かつ多様に設定することができる技術が必要である。

大韓民国公開特許第１０‐１９９９‐００３８６９８号（１９９９年０６月０５日付け公開） 大韓民国公開特許第１０‐２００８‐００３１２０２号（２００８年０４月０８日付け公開） 大韓民国公開特許第１０‐２００４‐００５３２５４号（２００４年０６月２３日付け公開） 大韓民国公開特許第１０‐２０１２‐００５２３０１号（２０１２年０５月２３日付け公開） 日本国特開２０１５‐１９１２５８号（２０１５年１１月０２日付け公開） 大韓民国公開特許第１０‐２０１７‐００７７９３９号（２０１７年０７月０７日付け公開） 大韓民国公開特許第１０‐２０１７‐００７７９３５号（２０１７年０７月０７日付け公開）

本発明は、前記問題点に鑑みなされたものであり、データベースから抽出したデータセットをウェブ上のグリッドインターフェースに提供し、グリッドの更新内容を反映するための計画設定手段を提供し、設定された反映計画により更新されたグリッドの内容をデータテーブルに反映する、グリッドインターフェースに基づくデータ入出力システムを提供することを目的とする。

また、グリッドの内容をテーブルに反映する反映計画を設定するとき、グリッドとテーブルとの間のフィールドマッチング方式で設定するインタフェースを提供する、グリッドインターフェースに基づくデータ入出力システムを提供することを他の目的とする。

前記目的を達成するための本発明は、グリッドインターフェースに基づくデータ入出力システムに関し、データベースからデータセットを要請するデータ要請部と、要請したデータセットをグリッドインターフェースに表示するが、グリッドのカラムに前記データセットのフィールドを表示し、グリッドの各行に前記データセットのレコードを表示するグリッド表示部と、グリッド上において、レコードのうちの一部のデータを更新し、更新されたレコード及び更新種類を更新内容として書き込むグリッド更新部と、グリッドの更新内容をデータテーブルに反映するための計画（以下、反映計画という。）を設定するが、反映すべきデータテーブル(以下、目的テーブルという。) 、前記目的テーブルのフィールド (以下、目的フィールドという。)、目的フィールドにおけるキーフィールド、及び各目的フィールドに対するグリッド上のフィールドとのマッピングを設定することにより、反映計画を設定する反映計画設定部と、前記反映計画により、グリッドの更新内容をデータテーブルに反映するためのクエリ文を作成し、作成されたクエリ文を前記データベースに実行するように要請する反映計画実行部と、を備えることを特徴とする。

また、本発明は、グリッドインターフェースに基づくデータ入出力システムにおいて、前記反映計画実行部は、更新レコードの更新種類により、入力（ｉｎｓｅｒｔ）クエリ、アップデートクエリ（修正クエリ）、または削除（ｄｅｌｅｔｅ）クエリを生成することを特徴とする。

また、本発明は、グリッドインターフェースに基づくデータ入出力システムにおいて、前記反映計画実行部は、クエリ文を生成するとき、前記反映計画の目的テーブルを、参照するテーブルと記載し、前記反映計画の目的テーブルのフィールドを、参照するフィールドと記載し、参照フィールドにマッピングされるグリッドのレコードフィールドの値を参照フィールドの値と記載し、前記反映計画のキーフィールドを条件式の変数と記載し、当該キーフィールドにマッピングされるグリッドのレコードフィールドの値を変数値と記載することを特徴とする。

また、本発明は、グリッドインターフェースに基づくデータ入出力システムにおいて、前記反映計画実行部は、アップデートクエリの場合、テーブル名には、反映計画の目的テーブルの名前が記載され、条件式には、目的テーブルのキーフィールドと、これにマッピングされるグリッドフィールドのフィールド値が記載され、アップデートされるフィールド名とフィールド値は、反映計画に設定された目的テーブルのフィールドと、マッピングされるグリッドフィールドのフィールド値を全て記載するが、キーフィールドを除いて記載することを特徴とする。

また、本発明は、グリッドインターフェースに基づくデータ入出力システムにおいて、前記反映計画は、多数個が設定されてもよく、前記反映計画実行部は、多数個の反映計画を全て実行することを特徴とする。

また、本発明は、グリッドインターフェースに基づくデータ入出力システムにおいて、前記反映計画設定部は、一つの反映計画には、一つの目的テーブルのみを設定することを特徴とする。

また、本発明は、グリッドインターフェースに基づくデータ入出力システムにおいて、前記グリッド表示部は、ウェブブラウザ上において前記グリッドを表示するが、ウェブ標準のスクリプトで具体化されたプログラムシステムによりグリッドが表示されることを特徴とする。

上述したように、本発明に係るグリッドインターフェースに基づくデータ入出力システムによれば、グリッド更新内容をデータテーブルに反映することができる計画設定手段を提供することにより、ユーザの所望により、グリッドの更新内容を多様に反映することができるという効果が得られる。

また、本発明に係るグリッドインターフェースに基づくデータ入出力システムによれば、グリッドとデータテーブルとの間のフィールドマッチング方式を用いて反映計画を設定することにより、さらに直観的かつ簡単に反映計画を立てることができるという効果が得られる。

本発明を実施するための全体システムを示す構成図である。 本発明の一実施例に係るグリッドインターフェースに基づくデータ入出力システムの構成を示すブロック図である。 本発明の一実施例に係るデータセットを要請する画面の一例を示す図である。 本発明の一実施例に係るデータセットを要請する画面の一例を示す図である。 本発明の一実施例に係るデータセットを要請する画面の一例を示す図である。 本発明の一実施例に係るデータセットを要請する画面の一例を示す図である。 本発明の一実施例に係るデータセットを示す構造図である。 本発明の一実施例に係るグリッド画面の一例を示す図である。 本発明の一実施例に係るグリッド更新画面の一例を示す図である。 本発明の一実施例に係るグリッド更新画面の一例を示す図である。 本発明の一実施例に係る反映計画設定画面の一例を示す図である。 本発明の一実施例に係る反映計画により生成されたクエリ文の一例を示す図である。 本発明の一実施例に係る反映計画により生成されたクエリ文の一例を示す図である。 本発明の一実施例に係る反映計画により生成されたクエリ文の一例を示す図である。

以下、本発明の実施のための具体的な内容について添付図面に基づいて説明する。

また、本発明を説明するに当たって、同じ部分には同じ符号を付し、その重複する説明を省略する。

先ず、図１を参照して、本発明を実施するための全体システムの構成について説明する。

図１に示すように、本発明を実施するための全体システムは、ユーザ端末１０に設けられるクライアント２０と、クライアント２０とネットワークを介して連結されるマトリクスサーバ３０と、データを保存して管理するデータベース４０と、を備える。図２は、図１の全体システムを示す構成図である。図２に示された「ユーザ」が、ユーザ端末１０内の構成であり、クライアント２０により駆動される構成を表示している。

クライアント２０は、ユーザ端末１０に設けられるクライアント用プログラムシステムであり、ウェブブラウザを介してユーザインタフェースを有する。すなわち、ユーザは、ウェブブラウザまたはウェブブラウザ等の画面のインタフェースを介して、オンライン上でデータ更新等の処理作業を行う。このとき、ユーザ端末１０は、ユーザの命令等を入力されて当該命令を行い、処理結果を画面上にまたはウェブブラウザ上に表示する。

一方、ユーザ端末１０は、パソコン（ＰＣ）、ノート型パソコン、タブレット型パソコン、ファブレット、ＰＤＡ、スマートフォン等のコンピューティング機能を有するコンピュータ端末である。ユーザ端末１０及びマトリクスサーバ３０は、ネットワークを介して連結され、ユーザ端末１０上のクライアント２０は、オンライン上でデータ処理作業を行う。

また、クライアント２０は、データ要請、データ更新等のオンライン上で処理する作業をマトリクスサーバ３０に要請し、その結果を、サーバ３０から取り出してウェブブラウザ上に表示する。或いは、処理されたデータをマトリクスサーバ３０に送信する。特に、クライアント２０は、データベース４０から取り出されたデータセットをテーブル（またはピボットテーブル）の形態で表示されたグリッドを介して表示し、または命令／データを入力される。グリッドは、多数のセルが格子またはテーブルの形態からなるものをいう。グリッドの各セルには、データが入力されて表示され、ユーザの入力により更新される。

また、クライアント２０は、グリッドの更新内容を反映するための反映計画を設定する。反映計画は、グリッドの更新内容をデータテーブルに反映するための計画であって、保存すべきデータテーブルの構成及びフィールドに保存すべき内容を定義したものとをいう。このとき、保存すべきデータテーブルを目的テーブル（またはターゲットテーブル）と称する。目的テーブルの構成は、テーブル及びそのフィールドを定義したものである。

特に、反映計画には、目的テーブルの各フィールドに保存すべき内容として、前記グリッドのフィールドをマッピングさせて定義される。

また、クライアント２０は、グリッドに更新すべき内容を全て入力した後、反映計画を実行することをサーバ３０に要請する。サーバ３０は、設定された反映計画により、グリッドの更新内容を各反映計画のテーブルに反映させる。好ましくは、更新されたデータ内容のみが目的テーブルに反映されて保存されてもよい。

一方、クライアント２０の機能、例えば、データセットを取り出し、またはデータセットをグリッドで表示し、またはグリッドの反映計画を設定するような機能は、ウェブブラウザのウェブスクリプト機能により具体化される。すなわち、ＨＴＭＬ５．０等のウェブ標準によるスクリプトにより、クライアント２０の機能がプログラムシステムで具体化される。

次いで、マトリクスサーバ３０は、データベース４０からデータセットを取り出してクライアント２０に送信して表示し、またはクライアント２０から更新済みデータセット（またはグリッド）の内容またはそれを反映すべき反映計画を受信する。

また、マトリクスサーバ３０は、ユーザの命令により反映計画を立てる。すなわち、設定された反映計画により、各反映計画のテーブルにグリッドの更新内容を反映させる。このとき、マトリクスサーバ３０は、反映計画をクエリ文として作成し、クエリ文（ＳＱＬ文等）を実行させることにより、データベース４０を更新させる。

特に、マトリクスサーバ３０は、クライアント２０から新たに追加されたり、削除されたり、修正されたりしたデータを検出し、変更されたデータを処理するための各反映計画のデータベースクエリ文を自動的に作成する。マトリクスサーバ３０は、作成されたクエリ文をデータベース４０に要請して、その結果がデータベース４０に反映されるように要請する。

一方、上述したクライアント２０及びマトリクスサーバ３０の機能は一例に過ぎず、サーバ及びクライアントの実現技術に応じて多様に具体化される。すなわち、クライアント２０及びマトリクスサーバ３０は、一つの更新システムであり、これらの機能が性能に応じて互いに分配される。例えば、クライアント２０は、単にウェブブラウザ機能のみを有しており、全ての機能はマトリクスサーバ３０において構築される。すなわち、マトリクスサーバ３０は、データベース４０のインタフェース機能及び修正されたデータに対するクエリ文の作成機能だけではなく、グリッドに基づくインタフェースを用いてデータを修正する機能をいずれも有する。また他の例によれば、マトリクスサーバ３０は、単にデータベース４０とのインタフェース機能のみを有しており、クライアント２０は、グリッドに基づくインタフェースを介してデータの修正機能だけではなく、反映計画を設定し、または修正されたデータに対するクエリ文の自動生成機能まで有する。すなわち、サーバ−クライアントの実現方式により多様な形態で機能を分配することができる。

次いで、データベース６０は、データを保存するための通常のデータベース（ＤＢ）であり、データを管理するためのデータベース管理システム（ＤＢＭＳ：Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）を備え、データの保存、削除、検索等の作業をクエリ（またはクエリ文）を用いて行う。特に、データベース４０は、商用化されたデータベースであり、データセットを処理するための通常のクエリ機能を用いてデータクエリサービスを行う。

特に、データベース４０は、ビッグデータを保存するデータベースである。また、好ましくは、データベース４０は、関係型データベース（ＲＤＢ：Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ）である。

以下の説明において、データセットの修正、削除、挿入等の全体データセットを変更する作業を、「更新」する作業として表現する。すなわち、更新作業は、修正、削除、挿入を全て含む概念として用いる。すなわち、修正は、レコードのうちの一部のフィールド値を変更することを言い、更新は、レコードを修正、削除、挿入等の変更する作業のことをいう。意味の差が大きくないときは、「修正」の用語を「更新」の用語と混用してもいい。

次いで、図２を参照して、本発明の一実施例に係るグリッドインターフェースに基づくデータ入出力システムについて説明する。本発明に係るグリッドインターフェースに基づく入出力システムは、上述したように、クライアント−サーバシステムで構築される。

図２に示すように、本発明の一実施例に係るグリッドインターフェースに基づくデータ入出力システム３００は、データベースのデータセットを要請するデータ要請部３１と、要請したデータセットをグリッドインターフェースに表示するグリッド表示部３２と、グリッド上で、データセットのうちの一部のデータを更新し、更新された内容を書き込むグリッド更新部３３と、グリッドの更新内容をデータテーブルに反映するための計画を設定する反映計画設定部３４と、反映計画により、グリッドの更新内容をデータテーブルに反映する反映計画実行部３５と、を備える。また、処理するデータを一時的に保存する保存部３８をさらに備える。

先ず、データ要請部３１は、データベース４０に要請して目的データベースからデータセットを取り出す。データセットとは、同一のフィールドで構成される多数のレコードで構成されるデータの集まりのことをいう。すなわち、一つのレコードは、多数のフィールド値により構成されるが、全てのレコードのフィールド（カラム）は、同一のフィールド（またはカラム）を有する。

好ましくは、データセットは、一つまたは多数のデータテーブル（またはデータベース（ＤＢ）テーブル）から取り出されたデータである。このとき、データセットとは、一つまたは多数のデータテーブルを参照するクエリ文により抽出されたデータである。

また、データ要請部３１は、データセットの各フィールドに関するメタ情報（スキーマ情報）を一緒に取り出す。データセットのメタ情報（または各フィールドのメタ情報）は、各フィールドの名前、表示名、データのタイプ（種類）、条件等のデータの構造に関する情報を示す。

また、好ましくは、図３に示すように、データ要請部３１は、 グラフィカル・ユーザー・インターフェース（ＧＵＩ：Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）とドラッグ・アンド・ドロップ(drag&drop)方式により、データセットを要請するインタフェースを提供する。すなわち、データ要請部３１は、ＧＵＩとドラッグ・アンド・ドロップ方式により、データベース内のデータテーブルを問い合わせ、問い合わせようとするデータテーブルのフィールドを選択し、問い合わせ条件を入力することにより、自分が希望するデータセットを構成するように支援する。

図３ｂに示すように、データ要請部３１は、データベース４０に要請して、目的データベースのテーブル一覧を問い合わせ、問い合わせられたテーブル一覧を画面に表示する。また、図３ｃに示すように、ユーザは、画面に表示されたテーブル一覧のうち、自分が希望するテーブルのフィールドをドラッグ・アンド・ドロップ方式により選択する。また、問い合わせ条件を入力する。

一方、データ要請部３１は、データ問い合わせ画面において選択されたテーブルのフィールドと、入力された問い合わせ条件を解析して、相当するクエリ文を自動的に生成する。また、クエリ文をデータベース４０に要請してデータセットを取り出す。

例えば、選択されたデータテーブルのフィールドは、クエリ文の参照項目（ＳＥＬＥＣＴ節の参照項目）となり、選択されたテーブルは、クエリ文で参照されるテーブル（ＦＲＯＭ節のテーブル名）となり、問い合わせ条件は、クエリ文の条件文（ＷＨＥＲＥ節の条件）となる。データ要請部３１は、上記した規則により、テーブル問い合わせ画面の結果によるクエリ文を生成する。

データ要請部３１は、生成されたクエリ文によりデータベース４０に要請してデータセットを取り出す。このとき、データセットの各フィールドに関するスキーマ情報（またはメタ情報）、すなわち、各データフィールドの名前、キーの有無、表示名、データのタイプ（種類）、条件等を一緒に取り出す。このように要請して取り出すデータセットは、図３ｄの通りである。図４は、取り出されたデータセットの構造を示す。取り出されたデータは、保存部３８に保存される。

他の例として、データ要請部３１は、目的データベースのテーブルデータを、直接作成されたクエリ文を用いて取り出す。

一方、データ要請部３１は、２つ以上のテーブルをジョイン（ｊｏｉｎ）して取り出す場合、ジョインするためのキーフィールドの情報も一緒に受信する。図３ａに示すように、３つのテーブルをジョインしてテーブルを参照するとき、「本部」と「年月」をジョインのためのキーとして用いる。キーとして用いられたフィールドは、ジョインした各テーブルに共通して含まれたフィールドである。

また、データ要請部３１は、既に作成されたクエリ文を用いる。すなわち、図３ａに示すように、既に作成されたクエリ文を選択してデータを問い合わせる。このとき、ジョンイに用いられたキーフィールドは、参照されたテーブルに共通して用いるフィールドであり、これらを他のフィールドと別途に区分して用いる。

次いで、グリッド表示部３２は、画面上（またはウェブブラウザ上）にグリッドインターフェースを提供するが、データセットを画面上のグリッド内に表示する。

図５に示すように、グリッドは、ウェブブラウザ上でテーブルまたは格子の形態で表示される。グリッドの上端には、フィールドの名前が表示され、フィールド名の下からレコードが表示される。上述したように、データセットは、同一のフィールドで構成された多数のレコードである。レコードの各セルには、当該レコードのフィールド値が入力されて表示される。

また、図５に示すように、グリッドには、多数のテーブルから取り出されたデータが一緒に表示される。図５では、資産現況（ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＡＳＴ）、ファンド現況（ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＦＵＮＤ）、営業現況（ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＳＡＬＥＳ）等が、それぞれ異なるテーブルから取り出されたデータであり、これらを一つのグリッドに表示する。

具体的に、グリッド上のデータは、行及び列により各セルにデータが表示され、このとき、上段行内における各列にはフィールド名（フィールドの名前）等が記載され、その下にレコードを各フィールドに合わせて配列する。データセットの各レコードは、グリッド上で一つの行に表示される。レコードの各列に相当するセルには、当該レコードフィールドのフィールド値が表示される。

また、参照したデータにおいて、各テーブルをジョインするために用いられたキーフィールドは、各テーブルに共通したフィールドであるので、グリッド上には重複して表示しない。すなわち、キーフィールドは、グリッド上に一つずつのみが表示される。例えば、図５において、「年月」と「本部」はいずれも３つのテーブルに共通して含まれるが、それぞれ一つずつのみがグリッド上に表示される。

好ましくは、図５に示すように、フィールド名は、複数（またはマルチ）で指定される。図５では、２種のフィールド名で構成され、特に、１番目のフィールドは、２番目のフィールドをまとめてフィールド名を表示する。

また、好ましくは、グリッド表示部３２は、グリッドを一般テーブルの形態のほか、ピボットテーブルの形態で表示する。ピボットテーブルは、横軸（行）と縦軸（カラム）がそれぞれフィールド名で構成され、横軸（行）と縦軸（カラム）が交差するセルがデータ領域で構成されるテーブルの形態である。データ領域のセルには、行とカラムに相当するフィールドの組み合わせによる統計値（例えば、個数、合計、平均等）が入力されて表示される。

また、好ましくは、グリッド表示部３２は、データセットのメタ情報を分析し、各フィールドの属性に合わせてグリッドの各セルの内容を表示する。すなわち、各フィールド（またはグリッドの列）に相当するデータのタイプを解析し、各列の表示属性（特に、数字に対する表示形式）をデータのタイプ（形式）に合わせて補正する。例えば、列（フィールド）の名前が「誕生日」であるが、当該フィールドの形式が日付け形式であれば、当該列を全て日付け形式に設定する。なお、通話表示であれば、これによるデータ形式で表示する。

次いで、グリッド更新部３３は、グリッド上に表示されたデータに対して更新作業を行う。特に、グリッド更新部３３は、前記グリッド表示部３２が提供するグリッドインタフェース画面を介して、ユーザの命令に応じてデータ更新作業を行う。

すなわち、グリッド更新部３３は、初期データセットをグリッド上に表示し、ユーザにより処理されるグリッド上の作業を処理する。例えば、ユーザがグリッド上で特定のセルのデータを修正したり、特定の行を挿入したり、削除したりする。

図６は、図５のレコードデータのうちの一部が更新された状態を示す。すなわち、図６ａは、「本部」フィールドが「西部地域１」であるレコードを削除することを示す。また、図６ｂは、「本部」フィールドが「南部地域」と「江北地域」であるレコードにおいて、「総資産」フィールドをそれぞれ「３０００」、「１０００」に修正（アップデート）し、「江南地域」であるレコードにおいて「委託資産」フィールドを「５２００」に修正した。また、新規で「城南地域」のレコードが挿入された。このとき、総資産、委託資産、金融資産、ファンド目標、ファンド残高、国内ファンド、海外ファンド、営業目標、営業実績は、それぞれ５１００、２０００、３０００、１２００、１５５２４、２０５５１、１６３５２、１５４４２、１５１４８であることが分かる。

一方、グリッド更新部３３は、グリッドにおいて更新されたレコードと、その種類(更新種類)を書き込む。更新種類は、当該レコードまたは当該行の更新状態、すなわち修正、挿入、削除等を示す。すなわち、データの更新情報は、更新されたレコードとその更新種類に関する情報である。

また、グリッド更新部３３は、修正の場合は、各行(各レコード)においてどのセルが修正されたかを書き込む。すなわち、修正されたセル単位で修正の有無を書き込む。

また、グリッド更新部３３は、グリッド上においてキーフィールドを修正できないように制限する。

次いで、反映計画設定部３４は、グリッドにおいて更新されたレコードの内容をデータテーブルに反映するための計画(または反映計画)を設定する。

反映計画は、データを保存すべきデータテーブル(または目的テーブル)、当該データテーブル(目的テーブル)に保存すべきフィールド、また目的テーブルの各フィールドにグリッドのフィールドのマッピングを設定することである。また、フィールドを設定するとき、必ずキーフィールドを指定する。

上記した反映計画は、多数個が設定されてもよい。また、各反映計画における目的テーブルは、１つに設定される。また、グリッドのフィールドマッピングは、直ちにフィールド値をマッピングさせてもよく、グリッドのフィールド値に関数や数式を適用した後、その結果値をマッピングさせてもよい。

図７は、反映計画を設定する画面を示す。特に、図７は、「資産現況」、「ファンド現況」、「営業現況」の３つの反映計画(または実行計画)を設定したことを示している。

先ず、反映計画設定部３４は、ユーザの入力または選択により、データを保存すべきデータテーブルを設定する。このとき、データテーブルは、データベース４０に既に存在し、または新たに作成されたテーブルである。

図７の例において、２番目の反映計画である「ファンド現況」の計画には、保存すべきデータテーブル(または目的テーブル)は、「ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＦＵ」の名前を有するテーブルに設定されることが分かる。また、目的テーブルにおいて更新すべきフィールドは、「年月」、「本部」、「目標」、…、「海外ファンド」の６つのフィールドであることが分かる。また、目的テーブルの各フィールドとマッピングされるグリッドのフィールドは、「年月」、「本部」、「ファンド目標」、…、「海外ファンド」等である。

図７の例において、目的テーブルは、既にデータベースに存在するテーブルであり、グリッドのデータセットを抽出するときに参照したテーブルである。すなわち、図７の反映計画は、グリッドのデータセットを形成するときに参照したテーブルであり、グリッドの更新内容を参照テーブルに反映するためのものである。

一方、目的テーブルの各フィールドに対するマッピング設定において、グリッドのフィールドをマッピングせず、パラメーターを設定してマッピングしてもよい。当該フィールドには、パラメーターの値が入力されて保存される。反映計画設定画面において、テキストボックスやコンボボックス(combo-box)等の形態でパラメーター値のリストを示す。ユーザの選択により、当該値のリストから一つのパラメーター値が選択される。

反映計画が実行されると、パラメーターとマッピングされるフィールドには、選択されたパラメーター値が入力される。このとき、全てのレコードの当該フィールドに選択されたパラメーター値が入力される。

次いで、反映計画実行部３５は、ユーザの命令により反映計画を実行させる。すなわち、更新情報により、各反映計画に相当するクエリ文を作成し、各クエリ文をデータベース４０に実行させる。このとき、クエリ文は、反映計画のデータテーブル、テーブルのフィールド、及びマッピング情報を用いて、グリッドの更新レコードを反映するクエリ文を生成する。

先ず、反映計画実行部３５は、データの更新情報により、更新データに対するクエリ文を生成する。すなわち、反映計画実行部３５は、反映計画を解析して、更新すべきデータベースとテーブル、カラム情報を抽出する。すなわち、反映計画で設定されたデータテーブルが反映すべき目的テーブルであり、データテーブルのフィールドが、つまり入力されまたは更新されるフィールドである。また、クエリ文の条件式は、キーフィールドにより定義される。また、更新される値は、グリッドのマッピングフィールドの値である。

また、反映計画実行部３５は、更新レコードの更新種類により、入力クエリ、アップデートクエリ（修正クエリ）、または削除クエリを生成する。また、更新される値(またはフィールド値、カラム値)は、更新レコードのマッピングフィールドのフィールド値である。

図８は、更新データ(またはレコード)に対して作成された実際クエリを示す。図８ａは、反映計画の「資産現況」に対するクエリであり、図８ｂは、反映計画の「ファンド現況」に対するクエリであり、図８ｃは、反映計画の「営業現況」に対するクエリである。

先ず、図８ａの（ａ１）に示すように、削除クエリは、「ＤＥＬＥＴＥ ＦＲＯＭ」から始まるクエリ文のフォーマット通りに記載し、「ＦＲＯＭ」の後ろには、目的テーブルの名前を記載し、ＷＨＥＲＥ節には、キーフィールド名と当該キー値を挿入する。目的テーブルの名前は、反映計画で設定されたデータテーブルである。また、キーフィールド名は、反映計画でキーフィールドに設定されたフィールドである。キー値は、グリッドから削除されたレコード(更新されたレコード)のフィールドの値であるが、反映計画において目的テーブルのキーフィールドとマッピングされるグリッドのフィールドのフィールド値である。このとき、キーフィールドが数個である場合、ＡＮＤにより数個のキーフィールド及びその当該キー値を全て挿入する。

すなわち、図８ａの（ａ１）において、ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＡＳＴは、反映計画の「資産現況」で設定された目的テーブルであり、「年月」と「本部」は、目的テーブルのキーフィールドである。また、「２０１７０１」、「西部地域１」は、削除されたグリッドのレコードのフィールドの値であるが、当該グリッドのフィールドは、目的テーブルのキーフィールドの「年月」、「本部」とマッピングされるフィールドである。

次いで、修正（アップデート）クエリの場合、反映計画実行部３５は、反映計画における目的テーブルのフィールドのフィールド名と、これにマッピングするグリッドのフィールドの値を更新するように作成する。すなわち、テーブル名には、反映計画の目的テーブルの名前が記載され、条件式は、目的テーブルのキーフィールドと、これにマッピングされるグリッドフィールドのフィールド値が記載される。このとき、フィールド値は、アップデートされたグリッドレコードのマッピングされたフィールドのフィールド値である。修正すべきフィールド名とフィールド値は、修正されたセルに相当する目的テーブルのフィールドとその値が記載される。前記グリッドを修正するとき、各修正されたレコードを書き込み、修正されたセルを書き込む。したがって、当該レコードにおいてどのセルが修正されたかが分かる。修正されたセルに対してのみフィールドとフィールド値を記載する。

図８ａの（ａ２）に示すように、ＵＰＤＡＴＥの参照テーブルは、目的テーブルの名前であるＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＡＳＴであり、条件節（ＷＨＥＲＥ節）の条件式の変数は、キーフィールドである「年月」と「本部」が記載される。条件式の変数値は、キーフィールドの「年月」、「本部」とマッピングされるグリッドフィールドのフィールド値である「２０１７０１」、「南部地域」が記載される。また、アップデートされるフィールドは、目的テーブルのフィールドのうち、修正されたセルのフィールドとその値が記載される。

また、図８ａの（ａ３）に示すように、入力クエリは、全てのフィールド名が全て記載され、当該フィールド値が全て記載される。

また、図８ｂと図８ｃに示すように、反映計画の「ファンド現況」、「営業現況」もそれぞれのクエリを生成する。反映計画の「ファンド現況」、「営業現況」は、修正されたセルがなくて、修正クエリは、生成されない。

すなわち、(「年月」、「本部」)が、それぞれ (「２０１７０１」、「南部地域」)、(「２０１７０１」、「江北地域」)、(「２０１７０１」、「江南地域」)であるレコードが修正されたが、それぞれ修正されたセルは、総資産が修正された。修正されたセルは、ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＡＳＴのフィールドのみであり、ＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＦＵＮＤやＭＡＴＲＩＸ．ＴＢ＿ＩＮＶ＿Ｔ２＿ＳＡＬＥＳは該当されない。すなわち、残りの２つのテーブルは、修正されたセルがない。したがって、修正クエリは、生成されない。

次いで、反映計画実行部３５は、生成（作成）されたクエリ文をデータベース４０に要請し、目的テーブルのデータを更新するように要請する。

反映計画実行部３５は、前記生成された実際のクエリ文を各レコード別にデータベース４０に送信して更新を要請する。しかしながら、個別的に各レコード別にクエリ文をデータベース４０に要請すると、全体の更新時間が長引き、しかも、コストが嵩む。これは、データベースは一回のトランザクションにより一つの要請を処理するが、トランザクションを行うための作業が多いためである。

このため、好ましくは、反映計画実行部３５は、多数のレコード別の実際のクエリをバッチにまとめて一括処理する。すなわち、クエリ文は一回のみ生成し、送信データの処理は、当該クエリの変数に当該カラム値のみをマッピングしてバッチに追加した後、最後にもう一回データベースに実行（Ｅｘｅｃｕｔｉｏｎ）を要請するので、速やかに大量のデータを処理することができる。

以上、本発明者により行われた発明について実施例により具体的に説明したが、本発明はこれらの実施例に何ら限定されるものではなく、その要旨を逸脱しない範囲内において様々に変更可能であるということはいうまでもない。

１０ ユーザ端末
２０ クライアント
３０ マトリクスサーバ
３１ データ要請部
３２ グリッド表示部
３３ グリッド更新部
３４ 反映計画設定部
３５ 反映計画実行部
４０ データベース

Claims (7)

1. グリッドインターフェースに基づくデータ入出力システムにおいて、
   データベースからデータセットを要請するデータ要請部と、
   要請したデータセットをグリッドインターフェースに表示するが、グリッドのカラムに前記データセットのフィールドを表示し、グリッドの各行に前記データセットのレコードを表示するグリッド表示部と、
   グリッド上において、レコードのうちの一部のデータを更新し、更新されたレコード及び更新種類を更新内容として書き込むグリッド更新部と、
   グリッドの更新内容をデータテーブルに反映するための計画（以下、反映計画という。）を設定するが、反映すべきデータテーブル(以下、目的テーブルという。)、前記目的テーブルのフィールド(以下、目的フィールドという。)、目的フィールドにおけるキーフィールド、及び各目的フィールドに対するグリッド上のフィールドとのマッピングを設定することにより、反映計画を設定する反映計画設定部と、
   前記反映計画により、グリッドの更新内容をデータテーブルに反映するためのクエリ文を作成し、作成されたクエリ文を前記データベースに実行するように要請する反映計画実行部と、を備えることを特徴とするグリッドインターフェースに基づくデータ入出力システム。
2. 前記反映計画実行部は、更新レコードの更新種類により、入力（ｉｎｓｅｒｔ）クエリ、アップデートクエリ（修正クエリ）、または削除（ｄｅｌｅｔｅ）クエリを生成することを特徴とする請求項１に記載のグリッドインターフェースに基づくデータ入出力システム。
3. 前記反映計画実行部は、クエリ文を生成するとき、前記反映計画の目的テーブルを、参照するテーブルと記載し、前記反映計画の目的テーブルのフィールドを、参照するフィールドと記載し、参照フィールドにマッピングされるグリッドのレコードフィールドの値を参照フィールドの値と記載し、前記反映計画のキーフィールドを条件式の変数と記載し、当該キーフィールドにマッピングされるグリッドのレコードフィールドの値を変数値と記載することを特徴とする請求項２に記載のグリッドインターフェースに基づくデータ入出力システム。
4. 前記反映計画実行部は、アップデートクエリの場合、テーブル名には、反映計画の目的テーブルの名前が記載され、条件式には、目的テーブルのキーフィールドと、これにマッピングされるグリッドフィールドのフィールド値が記載され、アップデートされるフィールド名とフィールド値は、反映計画に設定された目的テーブルのフィールドと、マッピングされるグリッドフィールドのフィールド値を全て記載するが、キーフィールドを除いて記載することを特徴とする請求項２に記載のグリッドインターフェースに基づくデータ入出力システム。
5. 前記反映計画は、多数個が設定されてもよく、
   前記反映計画実行部は、多数個の反映計画を全て実行することを特徴とする請求項１に記載のグリッドインターフェースに基づくデータ入出力システム。
6. 前記反映計画設定部は、一つの反映計画には、一つの目的テーブルのみを設定することを特徴とする請求項１に記載のグリッドインターフェースに基づくデータ入出力システム。
7. 前記グリッド表示部は、ウェブブラウザ上において前記グリッドを表示するが、ウェブ標準のスクリプトで具体化されたプログラムシステムによりグリッドが表示されることを特徴とする請求項１に記載のグリッドインターフェースに基づくデータ入出力システム。