プログラム開発支援システム及びデータ利用システム
【課題】正規化を極めたテーブルを操作するアプリケーションプログラムの、開発負担を軽減する。
【解決手段】キー項目が一つに限定される制約、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約、データの更新が禁止される制約が設けられたテーブルを複数備えたDBサーバ16に対し、各テーブルに格納されたデータを操作するSQLを発行すると共に、取得したデータを加工するプログラムの開発支援システム60であって、テーブルの設定情報に基づいて、テーブル名、データ項目及び各データ項目のデータ型を定義したクラスを生成し、型格納部66に格納する型生成部64と、クラスを指定したコードが記述されたソースプログラムが入力された際に、型格納部66内のクラスを参照して矛盾の存否を判定し、矛盾がある場合にはエラーメッセージを出力するコンパイラ68を備えた。
【解決手段】キー項目が一つに限定される制約、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約、データの更新が禁止される制約が設けられたテーブルを複数備えたDBサーバ16に対し、各テーブルに格納されたデータを操作するSQLを発行すると共に、取得したデータを加工するプログラムの開発支援システム60であって、テーブルの設定情報に基づいて、テーブル名、データ項目及び各データ項目のデータ型を定義したクラスを生成し、型格納部66に格納する型生成部64と、クラスを指定したコードが記述されたソースプログラムが入力された際に、型格納部66内のクラスを参照して矛盾の存否を判定し、矛盾がある場合にはエラーメッセージを出力するコンパイラ68を備えた。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はプログラム開発支援システム及びデータ利用システムに係り、特に、データベースサーバが管理するテーブルの正規化を追求した結果として、テーブル数の増大やテーブル間の関係の複雑化が生じる場合に備えて、テーブルを操作するアプリケーションプログラムの開発負担を軽減する技術、及び多数のテーブルを管理しているデータベースサーバ側の処理負担を軽減する技術に関する。
【背景技術】
【０００２】
巨大流通チェーンのように、大規模な業務システムを構築し、日々運用している企業においては、データベースサーバ（以下「DBサーバ」）が多数のテーブルを管理しており、複数のアプリケーションサーバ（以下「APサーバ」）によって構成されるサブシステム（受発注システム、仕入れシステム、経理システム等）が、上記のテーブルを共同利用する形式をとっている。
【非特許文献１】Webシステム入門／第１回 Webサイトの構成とJ2EEサーバ インターネットURL：http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html 検索日：２０１０年１０月６日
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ここで、DBサーバはデータの一元管理が最大の責務であり、このためには重複データの排除、すなわち「正規化」の維持が大原則となる。
しかしながら、正規化を追求するとテーブルの数が増大すると共に、テーブル間の関係も複雑化する結果、これを操作するアプリケーションプログラムの開発に際してプログラマの負担が増大し、バグ発生の危険性が高まるという問題が生じる。
【０００４】
また、テーブルの数が増大したり、テーブル間の関係が複雑化したりすると、その分、テーブルを操作するためのSQLの発行数の増大や処理内容の複雑化といった問題が生じ、この結果、DBサーバ側の演算処理の負担が拡大し、応答時間の遅れが生じていた。
これを回避するため、サブシステム毎に必要性の高いデータ項目を組み合わせると共に、独自のビジネスルールを反映させた中間テーブルを生成し、DBサーバに管理させる方法が採られる場合もある。この結果、当該サブシステムから発行されるSQLは確かに簡素化され、DBサーバの演算処理量を低減することはできるが、システム全体としてのデータ一元性を担保するため、DBサーバにはバッチ処理によってデータの変換・更新処理を行う必要性が生じ、今度はデータの不一致やデータ鮮度の低下（タイムラグの発生）という問題が生じてしまう。
【０００５】
この発明は、従来のこのような問題を解決するために案出されたものであり、アプリケーションプログラムの開発に際して、バグを事前に排除する仕組みを用意することにより、プログラマの負担を軽減できる技術の実現を第１の目的としている。
また、DBサーバ側の演算処理をAPサーバ側で肩代わりすることにより、テーブルの正規化を最大限に追求しつつも、システム全体の処理速度の低下を有効に回避できる技術の実現を第２の目的としている。
【課題を解決するための手段】
【０００６】
上記の目的を達成するため、請求項１に記載したプログラム開発支援システムは、キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられたテーブルを複数備えたデータベースサーバに対し、各テーブルに格納されたデータを操作するためのSQLを発行すると共に、取得したデータを加工する機能を果たすプログラムの開発支援システムであって、上記テーブルの設定情報に基づいて、少なくともテーブル名、データ項目及び各データ項目のデータ型を定義したクラス（型）をテーブル毎に生成し、記憶手段に格納する型生成手段と、上記のクラス（型）を指定した上で各テーブルへの操作を指令するコードが記述されたソースプログラムが入力された場合に、これをコンパイルするに際し、上記記憶手段内のクラス（型）を参照して記述内容に矛盾が存在するか否かを判定し、矛盾が存在する場合にはコンパイルエラーのメッセージを出力する手段とを備えたことを特徴としている。
【０００７】
また、請求項２に記載したデータ利用システムは、複数のテーブルが格納された記憶手段を備えたデータベースサーバと、このデータベースサーバにネットワークを介して接続され、各テーブルに格納されたデータを操作するためのSQLを発行する機能と、取得したデータを加工する機能を備えたアプリケーションサーバからなるデータ利用システムであって、上記の各テーブルには、キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられており、上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、データベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。
【発明の効果】
【０００８】
請求項１に記載のプログラム開発支援システムの場合、データベースサーバに格納される各テーブルに対応したクラス（型）が自動生成されると共に、コンパイル時にはこれを利用した型チェックが実行されるため、アプリケーションサーバに搭載されるプログラムの開発に際し、バグを事前に排除することが可能となる。
【０００９】
請求項２に記載のデータ利用システムの場合、データベースサーバが管理する各テーブルの正規化が極限まで追求され、構造の単純化が実現される一方で、テーブルから抽出したデータの加工処理（ソートやマッチング、コントロールブレイク等）はアプリケーションサーバ側で実行され、データベースサーバはデータの出し入れに専念できるため、テーブル数の増大やテーブル間の関係の複雑化に伴いSQLの発行数が増大しても、データベースサーバ側の負担増を抑制することが可能となる。
【００１０】
しかも、アプリケーションサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにデータベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。
【００１１】
これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISK/IOがボトルネックとなるため、アプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。
これに対し、上記のような仕組みをアプリケーションサーバに設けることにより、テーブルの正規化の追求に伴うデータベースサーバ側の負担増を、アプリケーションサーバ側の処理の効率化によってカバーすることが可能となった。
【００１２】
フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テスト・データの作成効率が向上するという効果も期待できる。
【発明を実施するための最良の形態】
【００１３】
図１及び図２は、この発明に係るデータ利用システム10の全体構成を示すブロック図であり、Webサーバ12と、APサーバ14と、DBサーバ16とを備えている。
DBサーバ16は、DB管理システム17と、複数のテーブル18を備えている。
【００１４】
図１は、クライアント端末19から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部20と、複数の検索処理部22を備えている。
【００１５】
また、図２はDBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部22単位で複数割り当てられたデータ加工処理部24と、検索結果統合処理部26を備えている。
【００１６】
APサーバ14内に設けられた上記の検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26は、APサーバ14に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実行される。
【００１７】
図３は、各CPUコア30とスレッド32との対応関係を表しており、各スレッド32にはスレッドプール34が設けられ、そこに配置された複数のタスク36をスレッド32が順次処理していくイメージが描かれている。
この図におけるスレッド32が、図１及び図２に表された検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26として機能し、これらの機能構成部が実行する具体的な処理がタスク36に相当する。
【００１８】
各スレッド32は、スレッドプール34に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール34が空になった場合には、他のスレッド32のスレッドプール34に蓄積されたタスク36を、新しい順に実行していく。
【００１９】
つぎに、図４〜図６のフローチャートに従い、このシステム10における処理手順を説明する。
まず、図４に従い、検索条件分割処理部20による処理手順を説明する。
すなわち、クライアント端末19から送信された検索条件をWebサーバ12経由でAPサーバ14が受信すると（Ｓ10）、検索条件分割処理部20は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ12）。
【００２０】
ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
例えば、「2010年における全チェーン店の売上を集計する」という検索条件が示された場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。
【００２１】
これらの分割基準は、クライアント端末19から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部20を実現するためのプログラム中にコーディングされている。
【００２２】
ここでは、都道府県単位で４７分割されたものとして話を進める。
すなわち、検索条件分割処理部20は、４７個の検索処理部22に対して、上記都道府県単位の検索処理を割り当てる（Ｓ14）。
【００２３】
つぎに図５に従い、各検索処理部22における処理手順を説明する。
まず検索処理部22は、自己に割り当てられた検索処理に必要な都道府県を指定したSQLを自動生成し、DBサーバ16に対して発行する（Ｓ20）。
【００２４】
ここで検索処理部22は、DBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量（例えばレコード1,000件分）のデータが送信された時点で（Ｓ22／Ｙ）、必要な演算処理を複数のデータ加工処理部24に割り当てる（Ｓ24）。
この結果、一部のデータ加工処理部24は、受信データをキー項目でソートすると共に、キー項目の値に基づいて複数のデータに分割する処理を実行する。また、他のデータ加工処理部24は、分割されたデータに基づく値の集計処理や、当該値を指定したデータの抽出をDBサーバ16に依頼する処理などを実行する。
受信データの分割手法については後に例示するが、検索条件の内容に応じて論理的に分割する検索条件分割処理部20による分割と異なり、受信データの値や分量に応じた分割手法となる。データ加工処理部24による具体的な処理についても、後に例示する。
【００２５】
検索処理部22は、データ加工処理部24から処理結果データが返信された時点で（Ｓ26／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する（Ｓ28）。
各検索処理部22は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にＳ24〜Ｓ28の処理を繰り返す（Ｓ30／Ｎ、Ｓ22／Ｙ）。
そして、DBサーバ16からのデータ送信が完了し、Ｓ24〜Ｓ28の最後の処理が完了した時点で（Ｓ30／Ｙ）、検索処理部22はこれまでの部分的な処理結果の集計値を集計し（Ｓ32）、検索結果統合処理部26に集計結果を出力する（Ｓ34）。
【００２６】
つぎに図６に従い、検索結果統合処理部26による処理手順を説明する。
まず検索結果統合処理部26は、各検索処理部22から集計結果が送信される度に、全ての検索処理部22からの集計結果が揃ったか否かをチェックし（Ｓ40、Ｓ42）、全てが揃った段階で全検索処理部の集計結果を集計する（Ｓ44）。
そして、その最終的な集計結果をWebサーバ12に送信する（Ｓ46）。
Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末19に送信することになる。
【００２７】
つぎに、図７を参照しながら、このシステム10のより具体的な処理内容を説明する。
図７は、DBサーバ16に格納された各テーブル18を示しており、「顧客ID（主キー）」及び「地域」のデータ項目を備えた顧客管理テーブル40と、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えた予約管理テーブル42と、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えた売上管理テーブル44と、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えた予約取消管理テーブル46と、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えた請求管理テーブル48とによって、各店舗の売り上げが管理されている。
【００２８】
上記の各テーブル18には、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。
【００２９】
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新は禁止される。
したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる。
【００３０】
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。
【００３１】
これらの制約ルールは、新規テーブルの設計時やSQL発行時に、DB管理システム17によって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。
【００３２】
図７より明らかなように、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
また、「予約取消」に関するデータも、通常であれば予約管理テーブル42において「予約取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル46を予約管理テーブル42とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル46に登録された予約IDが「予約取消」状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。
【００３３】
各テーブルには上記(2)の制約（値の更新禁止）が課せられているため、例えばある顧客の「地域」に変動が生じた場合でも、顧客管理テーブル40における該当レコードの「地域」の値が書き換えられることはない。
図示は省略したが、このような場合には例えば「顧客ID」、「変更地域」、「変更年月日」等のデータ項目を備えた「顧客地域変更管理テーブル」が新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。
【００３４】
この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ12側では顧客管理テーブル40を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。
【００３５】
このようなテーブル群がDBサーバ16において管理されている場合に、クライアント端末19から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信された場合、検索条件分割処理部20は、まず「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。
【００３６】
つぎに検索処理部22は、これらの分割された検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）を３１個の検索処理部22に割り当てる。
【００３７】
これを受けた各検索処理部22は、自己に割り当てられた請求日を指定した、請求管理テーブルから請求データを取得するためのSQLを生成し、DBサーバ16に発行する。
そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信されると、検索処理部22は一定量のデータ（例えば1,000件のレコード相当分）単位で受信データを分割し、複数のデータ加工処理部24に以下の処理を割り当てる。
(1)各請求データの「予約ID」を指定したSQLを生成してDBサーバ16に発行し、「予約管理テーブル」から対応の予約データを取得する。
(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
(3)各予約データの「顧客ID」を指定したSQLを生成してDBサーバ16に発行し、顧客管理テーブル40から対応の顧客データを取得する。
(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
これら(1)〜(4)の処理は、具体的にはタスク36として各データ加工処理部24のスレッドプール34に配置される。
【００３８】
検索処理部22は、データ加工処理部24から上がってきた1,OOO件単位の処理結果データをメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する。そして、１日分の処理結果データが揃った時点で、全処理結果データを集計する。この集計結果は、検索結果統合処理部26に出力される。
検索結果統合処理部26は、全検索処理部22から８月１日〜８月３１日までの全集計結果が集まった時点でこれらを集計し、Webサーバ12に出力する。
【００３９】
このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部24による処理が開始される仕組みであるため、DBサーバ16のDISK/IOによるボトルネックを解消することができる。
また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。
【００４０】
ここで、図８を参照して、DBサーバ16から送信された一定量単位のデータに対する分割手順について説明する。
まず一のデータ加工処理部24は、DBサーバ16から送信されたデータを２等分する位置を探索し、そこから前方不一致検索によってキー項目の変わり目を探しだし、データを２分割させる。
例えば、(a)のデータ列はキー項目の値として１〜６があるが、データ加工処理部24は「３」と「４」との間を境にこれを２分割させ、(b)及び(c)のデータ列を生成する。
【００４１】
つぎに、他のデータ加工処理部24は、(b)のデータ列を「２」と「３」との間で２分割させ、(d)及び(e)のデータ列を生成する。
この時点で、(e)のデータ列のキー項目の値は「３」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(e)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４２】
これに対し、(d)のデータ列の場合には「１」と「２」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(h)及び(i)のデータ列を生成する。
この時点で、(h)のデータ列のキー項目の値は「１」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(h)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(i)のデータ列のキー項目の値は「２」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(i)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４３】
一方、(c)のデータ列については、他のデータ加工処理部24が「５」と「６」との間で２分割させ、(f)及び(g)のデータ列を生成する。
この時点で、(g)のデータ列のキー項目の値は「６」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(g)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４４】
これに対し、(f)のデータ列の場合には「４」と「５」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(j)及び(k)のデータ列を生成する。
この時点で、(j)のデータ列のキー項目の値は「４」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(j)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(k)のデータ列のキー項目の値は「５」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(k)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４５】
図８の例では、説明の便宜上簡略化されたデータ列を例示したが、各データ加工処理部24は、実際にはDBサーバ16から送信された一定量（例えばレコード1,000件分）のデータ列に対して、ソートやマッチング、コントロールブレイクの都度、上記の分割処理を実行する。
この結果、大量のデータに対して複数のデータ加工処理部24による並列処理が可能となり、APサーバ14に複数搭載されたCPUコアの有効利用が可能となる。
このデータ加工処理部24による分割処理に際し、分割の回数（階層の深さ）に一定の限度を設けることもできる。
【００４６】
上記のように、データ加工処理部24は検索処理部22から渡されたデータ列の特定のデータ項目の値を指定してDBサーバ16にSQLを発行し、検索処理を依頼する場合があるため、必然的にDBサーバ16からの応答待ち（I/O Wait）が発生することになる。
【００４７】
そこで図９に示すように、各スレッド32にI/O Waitを伴う処理用の第１のスレッドプール50と、I/O Waitを伴わない処理用の第２のスレッドプール52を設けることが望ましい。
この結果、第１のスレッドプール50に配置されたタスク36の実行によってI/O Waitが発生した場合、スレッド32は第２のスレッドプール52に配置されたタスク36を待ち時間の間に処理することが可能となり、処理の効率化を図ることが可能となる。
【００４８】
この発明にあっては、以上のようにDBサーバ16が管理する各テーブル18の構造が単純化される分、テーブルの数が増え、SQLの発行数自体は増大するが、演算処理は多数のCPUコアを用いた並列処理によって高速化されたAPサーバ側で行われ、DBサーバ16はデータの管理（格納と取り出し）に専念でき、データの更新処理からも解放されるため、DBサーバ14の負担は大幅に軽減される。この結果、テーブルの正規化の追求に伴いDBサーバ16側の処理速度が低下することを、有効に回避できる。
【００４９】
また、テーブルの数が増大する分、これを操作するAPサーバ14側のアプリケーションプログラムの開発負担が増大し、バグ発生の危険性が高まるという懸念が生じる。
これに対しては、各テーブル18毎に固有の型（クラス）を予め専用のツールを用いて自動生成しておき、APサーバ14側のアプリケーションプログラムをコーディングする際に各テーブル固有の型を指定するようにすることで、コンパイル時に型チェック（静的チェック）が機能するようになり、バグを事前に排除することが可能となる。
【００５０】
図１０は、この発明に係るプログラム開発支援システム60の全体構成を示すものであり、テーブル設定部62と、型生成部64と、型格納部66と、コンパイラ68とを備えている。これらの中、テーブル設定部62、型生成部64、コンパイラ68は、コンピュータのCPUが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現される。また、型格納部66は、同コンピュータのハードディスク内に設けられている。
【００５１】
このプログラム開発支援システム60には、ネットワークを介してDBサーバ16及び開発端末70が接続されている。
DBサーバ16は、上記と同様、DB管理システム17と、複数のテーブル18(a)〜18(c)を備えている。
また、開発端末70はPC等のコンピュータよりなり、OSやWebブラウザ、テキストエディタ等のプログラムを搭載している。
【００５２】
まず開発者は、開発端末70からテーブル設定部62にアクセスし、新規テーブルの作成をリクエストする。この結果、テーブル設定画面が開発端末70に送信され、Webブラウザ上に表示される（図示省略）。
開発者は、このテーブル設定画面上で、テーブルの名称、データ項目名、データ型、桁数を指定し、テーブル設定部62に送信する。
【００５３】
テーブル設定部62は、送信された設定データをDBサーバ16に送信し、新規テーブルの生成を依頼する。
これを受けたDB管理システム17は、この設定データに従って新規のテーブルをDBサーバ16の記憶装置内に生成する。
【００５４】
図１１は、DBサーバ16の記憶装置内に格納されているテーブルを例示するものであり、商品テーブル18(a)と、承認済み商品テーブル18(b)と、停止商品テーブル18(c)とが挙げられている。
【００５５】
これらのテーブルは、図１１の(α)に示すように、従来であれば商品ID、商品名、適用開始日、適用終了日を備えた単一のテーブルとして構成されていたものを、商品ID及び商品名のデータ項目を備えた商品テーブル18(a)と、商品ID及び適用開始日のデータ項目を備えた承認済み商品テーブル18(b)と、商品ID及び適用終了日のデータ項目を備えた停止商品テーブル18(c)とに分割したものである。
【００５６】
すなわち、商品テーブル18(a)には申請がなされたすべての商品の商品ID及び商品名が格納されているのに対し、承認済み商品テーブル18(b)には申請された商品中で承認が下りた商品の商品ID及び適用開始日のみが格納されている。この承認済み商品テーブル18(b)への商品IDの登録の有無によって、当該商品の承認の事実が表現されている。
同様に、停止商品テーブル18(c)には承認された商品中で承認が停止された商品のID及び適用終了日のみが格納されている。この停止商品テーブル18(c)への商品IDの登録の有無によって、当該商品の承認停止の事実が表現されている。
【００５７】
もちろん、商品テーブル18(a)、承認済み商品テーブル18(b)、停止商品テーブル18(c)のそれぞれには、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新は禁止される。
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
【００５８】
つぎに、型生成部64が起動し、テーブル設定部62から各テーブルの設定データを受け取り、DBサーバ16内に生成された各テーブルに対応したクラス（型）を生成する。
図１０においては、商品テーブル18(a)に対応した「Itemクラス（型）」と、承認済み商品テーブル18(b)に対応した「ItemApprovedクラス（型）」と、停止商品テーブル18(c)に対応した「ItemStoppedクラス（型）」とが生成され、開発支援システム10の型格納部66内に登録されている様子が描かれている。
これらクラスの実体は、対応テーブルの名称、データ項目、データ型、桁数等が記述されたプログラムである。
【００５９】
つぎに開発者は、開発端末70上でAPサーバ14に搭載するためのアプリケーションプログラムをコーディングすることになるが、テーブル操作に係るコードを記述する際、開発者は各テーブルの型を指定した上で具体的な処理を記述する。
【００６０】
図１２はその一例を示すものであり、(1)の行においては「Itemクラスに対応したテーブル（商品テーブル18(a)）から商品名（items）を抽出し、商品ID（ItemId）順にソートする」ことが規定されている。
また、(2)の行においては「ItemApprovedクラスに対応したテーブル（承認済み商品テーブル18(b)）から適用開始日（approveds）を抽出し、商品ID（ItemId）順にソートする」ことが規定されている。
(3)の行においては「ItemStoppedクラスに対応したテーブル（停止商品テーブル18(c)）から適用終了日（stopped）を抽出し、商品ID（ItemId）順にソートする」ことが規定されている。
(4)の行においては、「承認済み商品（approvedItems）は、適用開始日（approveds）が付与された商品であり、これはItemクラスに属する」ことが規定されている。
(5)の行においては、「有効商品（validItems）は、承認済み商品（approvedItems）の中で適用終了日（stopped）が付与されていない商品であり、これはItemクラスに属する」ことが規定されている。
【００６１】
開発者は、完成したソースファイルを開発端末70からプログラム開発支援システム60に送信し、そのコンパイルを要求する。
図１２に示したように、ソースコードの各行にはクラスが指定されているため、コンパイラ68がソースコードをコンパイルするに際し、その記述内容と対応クラスの定義内容とを比較し、矛盾の有無を判定することができる。
例えば(2)の行において、仮に「ItemApproved[] stopped = select & sort by ItemId」と記述されていた場合、コンパイラ68は「ItemApprovedクラス」中には「stopped」のデータ項目が含まれていないことから、「コンパイルエラー」のメッセージを開発端末70に送信する。
この結果、開発者はコーディングの段階でバグを潰すことが可能となる。
【００６２】
元々SQLには型チェックの機能が実装されていないため、SQLを用いてDBサーバ16側に演算処理させた場合にはSQL文にミスがあっても事前に取り除くことはできないが、APサーバ16上のアプリケーションプログラムの開発時には上記のような型チェックを利用することができるため、テーブル18から抽出したデータの加工処理は、可能な限りAPサーバ16側で実行するように運用することが望ましいといえる。
【図面の簡単な説明】
【００６３】
【図１】この発明に係るデータ利用システムの、検索リクエストがDBサーバに送信される場面での機能構成を示すブロック図である。
【図２】この発明に係るデータ利用システムの、DBサーバから検索結果が送信される場面での機能構成を示すブロック図である。
【図３】CPUコアとスレッドとの対応関係を示す模式図である。
【図４】検索条件分割処理部による処理手順を示すフローチャートである。
【図５】検索処理部による処理手順を示すフローチャートである。
【図６】検索結果統合処理部による処理手順を示すフローチャートである。
【図７】DBサーバに格納されたテーブル群を示す図である。
【図８】データ加工処理部によるデータ分割の手順を示す模式図である。
【図９】スレッド毎に複数のスレッドプールを設けた例を示す模式図である。
【図１０】この発明に係るプログラム開発支援システムの機能構成を示すブロック図である。
【図１１】DBサーバに格納されたテーブルの具体例を示す図である。
【図１２】ソースコードの一例を示す図である。
【符号の説明】
【００６４】
10 データ利用システム
12 Webサーバ
14 APサーバ
16 DBサーバ
17 DB管理システム
18 テーブル
19 クライアント端末
20 検索条件分割処理部
22 検索処理部
24 データ加工処理部
26 検索結果統合処理部
30 CPUコア
32 スレッド
34 スレッドプール
36 タスク
40 顧客管理テーブル
42 予約管理テーブル
44 売上管理テーブル
46 予約取消管理テーブル
48 請求管理テーブル
50 第１のスレッドプール
52 第２のスレッドプール
60 プログラム開発支援システム
62 テーブル設定部
64 型生成部
66 型格納部
68 コンパイラ
70 開発端末
【技術分野】
【０００１】
この発明はプログラム開発支援システム及びデータ利用システムに係り、特に、データベースサーバが管理するテーブルの正規化を追求した結果として、テーブル数の増大やテーブル間の関係の複雑化が生じる場合に備えて、テーブルを操作するアプリケーションプログラムの開発負担を軽減する技術、及び多数のテーブルを管理しているデータベースサーバ側の処理負担を軽減する技術に関する。
【背景技術】
【０００２】
巨大流通チェーンのように、大規模な業務システムを構築し、日々運用している企業においては、データベースサーバ（以下「DBサーバ」）が多数のテーブルを管理しており、複数のアプリケーションサーバ（以下「APサーバ」）によって構成されるサブシステム（受発注システム、仕入れシステム、経理システム等）が、上記のテーブルを共同利用する形式をとっている。
【非特許文献１】Webシステム入門／第１回 Webサイトの構成とJ2EEサーバ インターネットURL：http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html 検索日：２０１０年１０月６日
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ここで、DBサーバはデータの一元管理が最大の責務であり、このためには重複データの排除、すなわち「正規化」の維持が大原則となる。
しかしながら、正規化を追求するとテーブルの数が増大すると共に、テーブル間の関係も複雑化する結果、これを操作するアプリケーションプログラムの開発に際してプログラマの負担が増大し、バグ発生の危険性が高まるという問題が生じる。
【０００４】
また、テーブルの数が増大したり、テーブル間の関係が複雑化したりすると、その分、テーブルを操作するためのSQLの発行数の増大や処理内容の複雑化といった問題が生じ、この結果、DBサーバ側の演算処理の負担が拡大し、応答時間の遅れが生じていた。
これを回避するため、サブシステム毎に必要性の高いデータ項目を組み合わせると共に、独自のビジネスルールを反映させた中間テーブルを生成し、DBサーバに管理させる方法が採られる場合もある。この結果、当該サブシステムから発行されるSQLは確かに簡素化され、DBサーバの演算処理量を低減することはできるが、システム全体としてのデータ一元性を担保するため、DBサーバにはバッチ処理によってデータの変換・更新処理を行う必要性が生じ、今度はデータの不一致やデータ鮮度の低下（タイムラグの発生）という問題が生じてしまう。
【０００５】
この発明は、従来のこのような問題を解決するために案出されたものであり、アプリケーションプログラムの開発に際して、バグを事前に排除する仕組みを用意することにより、プログラマの負担を軽減できる技術の実現を第１の目的としている。
また、DBサーバ側の演算処理をAPサーバ側で肩代わりすることにより、テーブルの正規化を最大限に追求しつつも、システム全体の処理速度の低下を有効に回避できる技術の実現を第２の目的としている。
【課題を解決するための手段】
【０００６】
上記の目的を達成するため、請求項１に記載したプログラム開発支援システムは、キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられたテーブルを複数備えたデータベースサーバに対し、各テーブルに格納されたデータを操作するためのSQLを発行すると共に、取得したデータを加工する機能を果たすプログラムの開発支援システムであって、上記テーブルの設定情報に基づいて、少なくともテーブル名、データ項目及び各データ項目のデータ型を定義したクラス（型）をテーブル毎に生成し、記憶手段に格納する型生成手段と、上記のクラス（型）を指定した上で各テーブルへの操作を指令するコードが記述されたソースプログラムが入力された場合に、これをコンパイルするに際し、上記記憶手段内のクラス（型）を参照して記述内容に矛盾が存在するか否かを判定し、矛盾が存在する場合にはコンパイルエラーのメッセージを出力する手段とを備えたことを特徴としている。
【０００７】
また、請求項２に記載したデータ利用システムは、複数のテーブルが格納された記憶手段を備えたデータベースサーバと、このデータベースサーバにネットワークを介して接続され、各テーブルに格納されたデータを操作するためのSQLを発行する機能と、取得したデータを加工する機能を備えたアプリケーションサーバからなるデータ利用システムであって、上記の各テーブルには、キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられており、上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、データベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。
【発明の効果】
【０００８】
請求項１に記載のプログラム開発支援システムの場合、データベースサーバに格納される各テーブルに対応したクラス（型）が自動生成されると共に、コンパイル時にはこれを利用した型チェックが実行されるため、アプリケーションサーバに搭載されるプログラムの開発に際し、バグを事前に排除することが可能となる。
【０００９】
請求項２に記載のデータ利用システムの場合、データベースサーバが管理する各テーブルの正規化が極限まで追求され、構造の単純化が実現される一方で、テーブルから抽出したデータの加工処理（ソートやマッチング、コントロールブレイク等）はアプリケーションサーバ側で実行され、データベースサーバはデータの出し入れに専念できるため、テーブル数の増大やテーブル間の関係の複雑化に伴いSQLの発行数が増大しても、データベースサーバ側の負担増を抑制することが可能となる。
【００１０】
しかも、アプリケーションサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにデータベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。
【００１１】
これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISK/IOがボトルネックとなるため、アプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。
これに対し、上記のような仕組みをアプリケーションサーバに設けることにより、テーブルの正規化の追求に伴うデータベースサーバ側の負担増を、アプリケーションサーバ側の処理の効率化によってカバーすることが可能となった。
【００１２】
フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テスト・データの作成効率が向上するという効果も期待できる。
【発明を実施するための最良の形態】
【００１３】
図１及び図２は、この発明に係るデータ利用システム10の全体構成を示すブロック図であり、Webサーバ12と、APサーバ14と、DBサーバ16とを備えている。
DBサーバ16は、DB管理システム17と、複数のテーブル18を備えている。
【００１４】
図１は、クライアント端末19から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部20と、複数の検索処理部22を備えている。
【００１５】
また、図２はDBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部22単位で複数割り当てられたデータ加工処理部24と、検索結果統合処理部26を備えている。
【００１６】
APサーバ14内に設けられた上記の検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26は、APサーバ14に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実行される。
【００１７】
図３は、各CPUコア30とスレッド32との対応関係を表しており、各スレッド32にはスレッドプール34が設けられ、そこに配置された複数のタスク36をスレッド32が順次処理していくイメージが描かれている。
この図におけるスレッド32が、図１及び図２に表された検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26として機能し、これらの機能構成部が実行する具体的な処理がタスク36に相当する。
【００１８】
各スレッド32は、スレッドプール34に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール34が空になった場合には、他のスレッド32のスレッドプール34に蓄積されたタスク36を、新しい順に実行していく。
【００１９】
つぎに、図４〜図６のフローチャートに従い、このシステム10における処理手順を説明する。
まず、図４に従い、検索条件分割処理部20による処理手順を説明する。
すなわち、クライアント端末19から送信された検索条件をWebサーバ12経由でAPサーバ14が受信すると（Ｓ10）、検索条件分割処理部20は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ12）。
【００２０】
ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
例えば、「2010年における全チェーン店の売上を集計する」という検索条件が示された場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。
【００２１】
これらの分割基準は、クライアント端末19から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部20を実現するためのプログラム中にコーディングされている。
【００２２】
ここでは、都道府県単位で４７分割されたものとして話を進める。
すなわち、検索条件分割処理部20は、４７個の検索処理部22に対して、上記都道府県単位の検索処理を割り当てる（Ｓ14）。
【００２３】
つぎに図５に従い、各検索処理部22における処理手順を説明する。
まず検索処理部22は、自己に割り当てられた検索処理に必要な都道府県を指定したSQLを自動生成し、DBサーバ16に対して発行する（Ｓ20）。
【００２４】
ここで検索処理部22は、DBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量（例えばレコード1,000件分）のデータが送信された時点で（Ｓ22／Ｙ）、必要な演算処理を複数のデータ加工処理部24に割り当てる（Ｓ24）。
この結果、一部のデータ加工処理部24は、受信データをキー項目でソートすると共に、キー項目の値に基づいて複数のデータに分割する処理を実行する。また、他のデータ加工処理部24は、分割されたデータに基づく値の集計処理や、当該値を指定したデータの抽出をDBサーバ16に依頼する処理などを実行する。
受信データの分割手法については後に例示するが、検索条件の内容に応じて論理的に分割する検索条件分割処理部20による分割と異なり、受信データの値や分量に応じた分割手法となる。データ加工処理部24による具体的な処理についても、後に例示する。
【００２５】
検索処理部22は、データ加工処理部24から処理結果データが返信された時点で（Ｓ26／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する（Ｓ28）。
各検索処理部22は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にＳ24〜Ｓ28の処理を繰り返す（Ｓ30／Ｎ、Ｓ22／Ｙ）。
そして、DBサーバ16からのデータ送信が完了し、Ｓ24〜Ｓ28の最後の処理が完了した時点で（Ｓ30／Ｙ）、検索処理部22はこれまでの部分的な処理結果の集計値を集計し（Ｓ32）、検索結果統合処理部26に集計結果を出力する（Ｓ34）。
【００２６】
つぎに図６に従い、検索結果統合処理部26による処理手順を説明する。
まず検索結果統合処理部26は、各検索処理部22から集計結果が送信される度に、全ての検索処理部22からの集計結果が揃ったか否かをチェックし（Ｓ40、Ｓ42）、全てが揃った段階で全検索処理部の集計結果を集計する（Ｓ44）。
そして、その最終的な集計結果をWebサーバ12に送信する（Ｓ46）。
Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末19に送信することになる。
【００２７】
つぎに、図７を参照しながら、このシステム10のより具体的な処理内容を説明する。
図７は、DBサーバ16に格納された各テーブル18を示しており、「顧客ID（主キー）」及び「地域」のデータ項目を備えた顧客管理テーブル40と、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えた予約管理テーブル42と、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えた売上管理テーブル44と、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えた予約取消管理テーブル46と、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えた請求管理テーブル48とによって、各店舗の売り上げが管理されている。
【００２８】
上記の各テーブル18には、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。
【００２９】
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新は禁止される。
したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる。
【００３０】
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。
【００３１】
これらの制約ルールは、新規テーブルの設計時やSQL発行時に、DB管理システム17によって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。
【００３２】
図７より明らかなように、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
また、「予約取消」に関するデータも、通常であれば予約管理テーブル42において「予約取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル46を予約管理テーブル42とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル46に登録された予約IDが「予約取消」状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。
【００３３】
各テーブルには上記(2)の制約（値の更新禁止）が課せられているため、例えばある顧客の「地域」に変動が生じた場合でも、顧客管理テーブル40における該当レコードの「地域」の値が書き換えられることはない。
図示は省略したが、このような場合には例えば「顧客ID」、「変更地域」、「変更年月日」等のデータ項目を備えた「顧客地域変更管理テーブル」が新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。
【００３４】
この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ12側では顧客管理テーブル40を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。
【００３５】
このようなテーブル群がDBサーバ16において管理されている場合に、クライアント端末19から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信された場合、検索条件分割処理部20は、まず「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。
【００３６】
つぎに検索処理部22は、これらの分割された検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）を３１個の検索処理部22に割り当てる。
【００３７】
これを受けた各検索処理部22は、自己に割り当てられた請求日を指定した、請求管理テーブルから請求データを取得するためのSQLを生成し、DBサーバ16に発行する。
そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信されると、検索処理部22は一定量のデータ（例えば1,000件のレコード相当分）単位で受信データを分割し、複数のデータ加工処理部24に以下の処理を割り当てる。
(1)各請求データの「予約ID」を指定したSQLを生成してDBサーバ16に発行し、「予約管理テーブル」から対応の予約データを取得する。
(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
(3)各予約データの「顧客ID」を指定したSQLを生成してDBサーバ16に発行し、顧客管理テーブル40から対応の顧客データを取得する。
(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
これら(1)〜(4)の処理は、具体的にはタスク36として各データ加工処理部24のスレッドプール34に配置される。
【００３８】
検索処理部22は、データ加工処理部24から上がってきた1,OOO件単位の処理結果データをメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する。そして、１日分の処理結果データが揃った時点で、全処理結果データを集計する。この集計結果は、検索結果統合処理部26に出力される。
検索結果統合処理部26は、全検索処理部22から８月１日〜８月３１日までの全集計結果が集まった時点でこれらを集計し、Webサーバ12に出力する。
【００３９】
このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部24による処理が開始される仕組みであるため、DBサーバ16のDISK/IOによるボトルネックを解消することができる。
また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。
【００４０】
ここで、図８を参照して、DBサーバ16から送信された一定量単位のデータに対する分割手順について説明する。
まず一のデータ加工処理部24は、DBサーバ16から送信されたデータを２等分する位置を探索し、そこから前方不一致検索によってキー項目の変わり目を探しだし、データを２分割させる。
例えば、(a)のデータ列はキー項目の値として１〜６があるが、データ加工処理部24は「３」と「４」との間を境にこれを２分割させ、(b)及び(c)のデータ列を生成する。
【００４１】
つぎに、他のデータ加工処理部24は、(b)のデータ列を「２」と「３」との間で２分割させ、(d)及び(e)のデータ列を生成する。
この時点で、(e)のデータ列のキー項目の値は「３」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(e)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４２】
これに対し、(d)のデータ列の場合には「１」と「２」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(h)及び(i)のデータ列を生成する。
この時点で、(h)のデータ列のキー項目の値は「１」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(h)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(i)のデータ列のキー項目の値は「２」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(i)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４３】
一方、(c)のデータ列については、他のデータ加工処理部24が「５」と「６」との間で２分割させ、(f)及び(g)のデータ列を生成する。
この時点で、(g)のデータ列のキー項目の値は「６」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(g)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４４】
これに対し、(f)のデータ列の場合には「４」と「５」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(j)及び(k)のデータ列を生成する。
この時点で、(j)のデータ列のキー項目の値は「４」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(j)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(k)のデータ列のキー項目の値は「５」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(k)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００４５】
図８の例では、説明の便宜上簡略化されたデータ列を例示したが、各データ加工処理部24は、実際にはDBサーバ16から送信された一定量（例えばレコード1,000件分）のデータ列に対して、ソートやマッチング、コントロールブレイクの都度、上記の分割処理を実行する。
この結果、大量のデータに対して複数のデータ加工処理部24による並列処理が可能となり、APサーバ14に複数搭載されたCPUコアの有効利用が可能となる。
このデータ加工処理部24による分割処理に際し、分割の回数（階層の深さ）に一定の限度を設けることもできる。
【００４６】
上記のように、データ加工処理部24は検索処理部22から渡されたデータ列の特定のデータ項目の値を指定してDBサーバ16にSQLを発行し、検索処理を依頼する場合があるため、必然的にDBサーバ16からの応答待ち（I/O Wait）が発生することになる。
【００４７】
そこで図９に示すように、各スレッド32にI/O Waitを伴う処理用の第１のスレッドプール50と、I/O Waitを伴わない処理用の第２のスレッドプール52を設けることが望ましい。
この結果、第１のスレッドプール50に配置されたタスク36の実行によってI/O Waitが発生した場合、スレッド32は第２のスレッドプール52に配置されたタスク36を待ち時間の間に処理することが可能となり、処理の効率化を図ることが可能となる。
【００４８】
この発明にあっては、以上のようにDBサーバ16が管理する各テーブル18の構造が単純化される分、テーブルの数が増え、SQLの発行数自体は増大するが、演算処理は多数のCPUコアを用いた並列処理によって高速化されたAPサーバ側で行われ、DBサーバ16はデータの管理（格納と取り出し）に専念でき、データの更新処理からも解放されるため、DBサーバ14の負担は大幅に軽減される。この結果、テーブルの正規化の追求に伴いDBサーバ16側の処理速度が低下することを、有効に回避できる。
【００４９】
また、テーブルの数が増大する分、これを操作するAPサーバ14側のアプリケーションプログラムの開発負担が増大し、バグ発生の危険性が高まるという懸念が生じる。
これに対しては、各テーブル18毎に固有の型（クラス）を予め専用のツールを用いて自動生成しておき、APサーバ14側のアプリケーションプログラムをコーディングする際に各テーブル固有の型を指定するようにすることで、コンパイル時に型チェック（静的チェック）が機能するようになり、バグを事前に排除することが可能となる。
【００５０】
図１０は、この発明に係るプログラム開発支援システム60の全体構成を示すものであり、テーブル設定部62と、型生成部64と、型格納部66と、コンパイラ68とを備えている。これらの中、テーブル設定部62、型生成部64、コンパイラ68は、コンピュータのCPUが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現される。また、型格納部66は、同コンピュータのハードディスク内に設けられている。
【００５１】
このプログラム開発支援システム60には、ネットワークを介してDBサーバ16及び開発端末70が接続されている。
DBサーバ16は、上記と同様、DB管理システム17と、複数のテーブル18(a)〜18(c)を備えている。
また、開発端末70はPC等のコンピュータよりなり、OSやWebブラウザ、テキストエディタ等のプログラムを搭載している。
【００５２】
まず開発者は、開発端末70からテーブル設定部62にアクセスし、新規テーブルの作成をリクエストする。この結果、テーブル設定画面が開発端末70に送信され、Webブラウザ上に表示される（図示省略）。
開発者は、このテーブル設定画面上で、テーブルの名称、データ項目名、データ型、桁数を指定し、テーブル設定部62に送信する。
【００５３】
テーブル設定部62は、送信された設定データをDBサーバ16に送信し、新規テーブルの生成を依頼する。
これを受けたDB管理システム17は、この設定データに従って新規のテーブルをDBサーバ16の記憶装置内に生成する。
【００５４】
図１１は、DBサーバ16の記憶装置内に格納されているテーブルを例示するものであり、商品テーブル18(a)と、承認済み商品テーブル18(b)と、停止商品テーブル18(c)とが挙げられている。
【００５５】
これらのテーブルは、図１１の(α)に示すように、従来であれば商品ID、商品名、適用開始日、適用終了日を備えた単一のテーブルとして構成されていたものを、商品ID及び商品名のデータ項目を備えた商品テーブル18(a)と、商品ID及び適用開始日のデータ項目を備えた承認済み商品テーブル18(b)と、商品ID及び適用終了日のデータ項目を備えた停止商品テーブル18(c)とに分割したものである。
【００５６】
すなわち、商品テーブル18(a)には申請がなされたすべての商品の商品ID及び商品名が格納されているのに対し、承認済み商品テーブル18(b)には申請された商品中で承認が下りた商品の商品ID及び適用開始日のみが格納されている。この承認済み商品テーブル18(b)への商品IDの登録の有無によって、当該商品の承認の事実が表現されている。
同様に、停止商品テーブル18(c)には承認された商品中で承認が停止された商品のID及び適用終了日のみが格納されている。この停止商品テーブル18(c)への商品IDの登録の有無によって、当該商品の承認停止の事実が表現されている。
【００５７】
もちろん、商品テーブル18(a)、承認済み商品テーブル18(b)、停止商品テーブル18(c)のそれぞれには、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新は禁止される。
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
【００５８】
つぎに、型生成部64が起動し、テーブル設定部62から各テーブルの設定データを受け取り、DBサーバ16内に生成された各テーブルに対応したクラス（型）を生成する。
図１０においては、商品テーブル18(a)に対応した「Itemクラス（型）」と、承認済み商品テーブル18(b)に対応した「ItemApprovedクラス（型）」と、停止商品テーブル18(c)に対応した「ItemStoppedクラス（型）」とが生成され、開発支援システム10の型格納部66内に登録されている様子が描かれている。
これらクラスの実体は、対応テーブルの名称、データ項目、データ型、桁数等が記述されたプログラムである。
【００５９】
つぎに開発者は、開発端末70上でAPサーバ14に搭載するためのアプリケーションプログラムをコーディングすることになるが、テーブル操作に係るコードを記述する際、開発者は各テーブルの型を指定した上で具体的な処理を記述する。
【００６０】
図１２はその一例を示すものであり、(1)の行においては「Itemクラスに対応したテーブル（商品テーブル18(a)）から商品名（items）を抽出し、商品ID（ItemId）順にソートする」ことが規定されている。
また、(2)の行においては「ItemApprovedクラスに対応したテーブル（承認済み商品テーブル18(b)）から適用開始日（approveds）を抽出し、商品ID（ItemId）順にソートする」ことが規定されている。
(3)の行においては「ItemStoppedクラスに対応したテーブル（停止商品テーブル18(c)）から適用終了日（stopped）を抽出し、商品ID（ItemId）順にソートする」ことが規定されている。
(4)の行においては、「承認済み商品（approvedItems）は、適用開始日（approveds）が付与された商品であり、これはItemクラスに属する」ことが規定されている。
(5)の行においては、「有効商品（validItems）は、承認済み商品（approvedItems）の中で適用終了日（stopped）が付与されていない商品であり、これはItemクラスに属する」ことが規定されている。
【００６１】
開発者は、完成したソースファイルを開発端末70からプログラム開発支援システム60に送信し、そのコンパイルを要求する。
図１２に示したように、ソースコードの各行にはクラスが指定されているため、コンパイラ68がソースコードをコンパイルするに際し、その記述内容と対応クラスの定義内容とを比較し、矛盾の有無を判定することができる。
例えば(2)の行において、仮に「ItemApproved[] stopped = select & sort by ItemId」と記述されていた場合、コンパイラ68は「ItemApprovedクラス」中には「stopped」のデータ項目が含まれていないことから、「コンパイルエラー」のメッセージを開発端末70に送信する。
この結果、開発者はコーディングの段階でバグを潰すことが可能となる。
【００６２】
元々SQLには型チェックの機能が実装されていないため、SQLを用いてDBサーバ16側に演算処理させた場合にはSQL文にミスがあっても事前に取り除くことはできないが、APサーバ16上のアプリケーションプログラムの開発時には上記のような型チェックを利用することができるため、テーブル18から抽出したデータの加工処理は、可能な限りAPサーバ16側で実行するように運用することが望ましいといえる。
【図面の簡単な説明】
【００６３】
【図１】この発明に係るデータ利用システムの、検索リクエストがDBサーバに送信される場面での機能構成を示すブロック図である。
【図２】この発明に係るデータ利用システムの、DBサーバから検索結果が送信される場面での機能構成を示すブロック図である。
【図３】CPUコアとスレッドとの対応関係を示す模式図である。
【図４】検索条件分割処理部による処理手順を示すフローチャートである。
【図５】検索処理部による処理手順を示すフローチャートである。
【図６】検索結果統合処理部による処理手順を示すフローチャートである。
【図７】DBサーバに格納されたテーブル群を示す図である。
【図８】データ加工処理部によるデータ分割の手順を示す模式図である。
【図９】スレッド毎に複数のスレッドプールを設けた例を示す模式図である。
【図１０】この発明に係るプログラム開発支援システムの機能構成を示すブロック図である。
【図１１】DBサーバに格納されたテーブルの具体例を示す図である。
【図１２】ソースコードの一例を示す図である。
【符号の説明】
【００６４】
10 データ利用システム
12 Webサーバ
14 APサーバ
16 DBサーバ
17 DB管理システム
18 テーブル
19 クライアント端末
20 検索条件分割処理部
22 検索処理部
24 データ加工処理部
26 検索結果統合処理部
30 CPUコア
32 スレッド
34 スレッドプール
36 タスク
40 顧客管理テーブル
42 予約管理テーブル
44 売上管理テーブル
46 予約取消管理テーブル
48 請求管理テーブル
50 第１のスレッドプール
52 第２のスレッドプール
60 プログラム開発支援システム
62 テーブル設定部
64 型生成部
66 型格納部
68 コンパイラ
70 開発端末
【特許請求の範囲】
【請求項１】
キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられたテーブルを複数備えたデータベースサーバに対し、各テーブルに格納されたデータを操作するためのSQLを発行すると共に、取得したデータを加工する機能を果たすプログラムの、開発支援システムであって、
上記テーブルの設定情報に基づいて、少なくともテーブル名、データ項目及び各データ項目のデータ型を定義したクラスをテーブル毎に生成し、記憶手段に格納する型生成手段と、
上記のクラスを指定した上で各テーブルへの操作を指令するコードが記述されたソースプログラムが入力された場合に、これをコンパイルするに際し、上記記憶手段内のクラスを参照して記述内容に矛盾が存在するか否かを判定し、矛盾が存在する場合にはコンパイルエラーのメッセージを出力する手段と、
を備えたことを特徴とするプログラム開発支援システム。
【請求項２】
複数のテーブルが格納された記憶手段を備えたデータベースサーバと、このデータベースサーバにネットワークを介して接続され、各テーブルに格納されたデータを操作するためのSQLを発行する機能と、取得したデータを加工する機能を備えたアプリケーションサーバからなるデータ利用システムであって、
上記の各テーブルには、キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられており、
上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、
上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、
上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、データベースサーバに発行する処理と、
データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、
各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、
データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とするデータ利用システム。
【請求項１】
キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられたテーブルを複数備えたデータベースサーバに対し、各テーブルに格納されたデータを操作するためのSQLを発行すると共に、取得したデータを加工する機能を果たすプログラムの、開発支援システムであって、
上記テーブルの設定情報に基づいて、少なくともテーブル名、データ項目及び各データ項目のデータ型を定義したクラスをテーブル毎に生成し、記憶手段に格納する型生成手段と、
上記のクラスを指定した上で各テーブルへの操作を指令するコードが記述されたソースプログラムが入力された場合に、これをコンパイルするに際し、上記記憶手段内のクラスを参照して記述内容に矛盾が存在するか否かを判定し、矛盾が存在する場合にはコンパイルエラーのメッセージを出力する手段と、
を備えたことを特徴とするプログラム開発支援システム。
【請求項２】
複数のテーブルが格納された記憶手段を備えたデータベースサーバと、このデータベースサーバにネットワークを介して接続され、各テーブルに格納されたデータを操作するためのSQLを発行する機能と、取得したデータを加工する機能を備えたアプリケーションサーバからなるデータ利用システムであって、
上記の各テーブルには、キー項目が一つに限定される制約と、Null値、フラグ値及び区分値を格納するためのデータ項目の設定が禁止される制約と、データの更新が禁止される制約が設けられており、
上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、
上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、
上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、データベースサーバに発行する処理と、
データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、
各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、
データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とするデータ利用システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−１１３３７３（Ｐ２０１２−１１３３７３Ａ）
【公開日】平成２４年６月１４日（２０１２．６．１４）
【国際特許分類】
【出願番号】特願２０１０−２５９６０７（Ｐ２０１０−２５９６０７）
【出願日】平成２２年１１月２０日（２０１０．１１．２０）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年６月１４日（２０１２．６．１４）
【国際特許分類】
【出願日】平成２２年１１月２０日（２０１０．１１．２０）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]