(57)【要約】【課題】DBサーバに複雑なSQL文を発行することなく、業務処理に必要なデータの収集・加工が可能で、APサーバ上のプログラムの再利用性及び保守性を向上できる技術の実現。【解決手段】複数のテーブル22を格納したDBサーバ14と、APサーバ12を備えたデータ処理システム10。APサーバ12は、クライアント端末20からトランザクションが送信された場合に、当該トランザクションの種別を判定する手段と、このトランザクションの処理に必要なテーブル22を特定するテーブル特定手段と、特定された各テーブル22からデータを抽出するためのSQL文をテーブル単位で生成し、各SQL文をDBサーバ14に送信するSQL発行手段と、DBサーバ14から送信されたテーブル単位のデータを、APサーバ12のメモリ32に格納する手段と、メモリ32に格納されたテーブル単位のデータに対し、トランザクションに対応したデータ処理を実行するデータ処理手段を備えた。【選択図】図１
2008250588.tif 000002
【特許請求の範囲】
【請求項１】
複数のテーブルを格納したDBサーバと、APサーバを備えたデータ処理システムであって、
上記APサーバは、クライアント端末からトランザクションが送信された場合に、当該トランザクションの種別を判定する手段と、
このトランザクションの処理に必要なテーブルを特定するテーブル特定手段と、
特定された各テーブルからデータを抽出するためのSQL文をテーブル単位で生成し、各SQL文をDBサーバに送信するSQL発行手段と、
DBサーバから送信されたテーブル単位のデータを、APサーバのメモリに格納するメモリ格納手段と、
メモリに格納されたテーブル単位のデータに対し、上記トランザクションに対応したデータ処理を実行するデータ処理手段と、
を備えたことを特徴とするデータ処理システム。
【請求項２】
上記データ処理手段が、上記メモリに格納されたテーブル単位のデータを抽象的なデータ型として認識し、各データをカラム名に基づいて操作することを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
上記メモリ格納手段が、DBサーバから送信されたデータのデータ型を、Primitive型に変換した上でAPサーバのメモリに格納することを特徴とする請求項１または２に記載のデータ処理システム。
【請求項４】
上記データ処理手段が、汎用的なデータ操作を実行する複数の関数を備えていることを特徴とする請求項１〜３の何れかに記載のデータ処理装置。
【請求項５】
上記SQL発行手段が、特定のテーブルから所定範囲のデータを抽出するに際し、必要なデータ範囲を複数に分割し、各分割範囲単位でSQL文を並列的に発行し、
上記メモリ格納手段が、DBサーバから送信されたデータをメモリ上に順次格納し、最後に各データを整列結合することを特徴とする請求項１〜４の何れかに記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ処理システムに係り、特に、クライアント端末からのリクエストに応じて、APサーバが必要なデータの抽出をDBサーバに依頼し、DBサーバから送信されたデータに対し必要な処理を施し、処理結果をクライアント端末に返信する仕組みを備えたデータ処理システムに関する。
【背景技術】
【０００２】
クライアントサーバ型システムの進展に伴い、より大規模な情報処理の要求に応えるために、データの表示をするクライアント端末の他にデータの加工を行うAPサーバ及びデータの格納を担当するDBサーバを備えた、いわゆる三層構造のクライアントサーバシステムが普及してきている。
また、処理速度の向上を図るため、複数のAPサーバを並列配置させることで負荷を分散させることも行われている。
【特許文献１】特開２００５−１６５６１０
【発明の開示】
【発明が解決しようとする課題】
【０００３】
DBサーバについてはデータの同期を維持する必要性があるため、APサーバのように簡単に分散処理に移行することはできない。もちろん、データベースシステムのベンダ各社は、様々な技術を駆使してソフトウェア及びハードウェアの両面からDBサーバ自体の高速化を図ってきており、その結果一定の成果は上がっているが、その分システムの価格が上昇することは否めない。
これに対し、APサーバは廉価なPCサーバで構成することができるため、設置台数を増加させることで処理速度を向上させることは比較的容易であり、特許文献１の技術を用いることでデータ処理の高速化をある程度達成することはできる。
【０００４】
しかしながら、従来の三層型クライアントサーバシステムの場合、クライアント端末からのリクエストに応えるため、複数のテーブルにアクセスして特定範囲のデータを抽出したり、特定のデータ間での演算処理を指令する複雑なSQL文がAPサーバにおいて生成され、DBサーバに発行される仕組みを備えている。
このように、複雑なSQL文を発行するためにはAPサーバにセットアップされるアプリケーションプログラムの開発が困難化するのは当然であるが、さらに問題となるのは保守性及び再利用性が低下することである。
【０００５】
すなわち、複雑なSQL文を生成するためには、業務ロジックの他にDBサーバに格納された各テーブルの構成を意識したアプリケーションプログラムを開発する必要があり、その結果、当該アプリケーションプログラムは特定の業務ロジック及びテーブル構成に特化されたコード形式となる。
この結果、このアプリケーションプログラムの一部を他の業務処理に応用することが困難となると共に、DBサーバのテーブル構成に変更が生じた場合には大幅な修正が必要となる。
【０００６】
また、複数のテーブルから特定範囲のデータ抽出を命ずる複雑なSQLをDBサーバに発行することにより、DBサーバの負担が増大する可能性もある。
【０００７】
この発明は、従来のデータ処理システムが抱えていた上記の問題を解決するために案出されたものであり、DBサーバに複雑なSQL文を発行することなく、業務処理に必要なデータの収集・加工が可能で、APサーバに用いられるアプリケーションプログラムの再利用性及び保守性を高めることが可能な技術の提供を目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ処理システムは、複数のテーブルを格納したDBサーバと、APサーバを備えたデータ処理システムであって、上記APサーバは、クライアント端末からトランザクションが送信された場合に、当該トランザクションの種別を判定する手段と、このトランザクションの処理に必要なテーブルを特定するテーブル特定手段と、特定された各テーブルからデータを抽出するためのSQL文をテーブル単位で生成し、各SQL文をDBサーバに送信するSQL発行手段と、DBサーバから送信されたテーブル単位のデータを、APサーバのメモリに格納するメモリ格納手段と、メモリに格納されたテーブル単位のデータに対し、上記トランザクションに対応したデータ処理を実行するデータ処理手段とを備えたことを特徴としている。
【０００９】
請求項２に記載したデータ処理システムは、請求項１のシステムであって、さらに上記データ処理手段が、上記メモリに格納されたテーブル単位のデータを抽象的なデータ型として認識し、各データをカラム名に基づいて操作することを特徴としている。
【００１０】
請求項３に記載したデータ処理システムは、請求項１または２のシステムであって、さらに上記メモリ格納手段が、DBサーバから送信されたデータのデータ型を、Primitive型に変換した上でAPサーバのメモリに格納することを特徴としている。
【００１１】
請求項４に記載したデータ処理システムは、請求項１〜３のシステムであって、さらに上記データ処理手段が、汎用的なデータ操作を実行する複数の関数を備えていることを特徴としている。
【００１２】
請求項５に記載したデータ処理システムは、請求項１〜４のシステムであって、さらに上記SQL発行手段が、特定のテーブルから所定範囲のデータを抽出するに際し、必要なデータ範囲を複数に分割し、各分割範囲単位でSQL文を並列的に発行し、上記メモリ格納手段が、DBサーバから送信されたデータをメモリ上に順次格納し、最後に各データを整列結合することを特徴としている。
【発明の効果】
【００１３】
請求項１に記載したデータ処理システムにあっては、APサーバからDBサーバに対して、単一のテーブル単位でSQLが発行され、APサーバのメモリに一旦テーブル単位でデータを格納した後、テーブル間の連結やソート、演算処理等のデータ操作をAPサーバ側で実行する仕組みを備えている。
このように、従来は複雑なSQLを発行することによってDBサーバ側で実行させていた処理をAPサーバ側で代替するようにしたため、DBサーバの負荷を軽減可能となり、システム全体の処理速度を向上させることができる。
また、SQLの発行をテーブル単位と細分化することで、APサーバ側のアプリケーションプログラムも細分化が可能となり、その保守性や再利用性を向上させることが可能となる。
【００１４】
請求項２に記載したデータ処理システムによれば、データ処理手段を実現するためのプログラムは各データ固有のデータ型を意識することなく単純にカラム名に基づいて各データの操作が可能となる。  この結果、プログラムの再利用性を高めることが可能となる。
【００１５】
請求項３に記載したデータ処理システムにあっては、DBサーバからのデータがメモリ効率の良好なPrimitive型に変換されるため、APサーバ上で扱えるデータ件数を大幅に増やすことが可能となる。
【００１６】
請求項４に記載したデータ処理システムにあっては、APサーバのデータ処理手段が汎用的な複数の関数を備えているため、データ処理手段を実現するためのプログラムの開発が容易化される利点を有している。
【００１７】
請求項５に記載したデータ処理システムにあっては、単一テーブルに対してSQL文を分割発行することにより、DBサーバにおける検索の並列化が実現され、DBサーバのリソースを有効活用可能となる。
また、分割取得したデータを整列させ、相互に結合させる処理はAPサーバ側で行われるため、DBサーバに過大な負荷を与えることもない。
【発明を実施するための最良の形態】
【００１８】
図１は、この発明に係るデータ処理システム10の全体構成図であり、このシステム10は、複数のAPサーバ12と、DBサーバ14と、ロードバランサ（負荷分散装置）16とを備えている。
ロードバランサ16と各APサーバ12間、及び各APサーバ12とDBサーバ14間はネットワークによって接続されている。
また、各APサーバ12に対しては、イントラネットやインターネット等のネットワーク及びロードバランサ16を介して多数のクライアント端末20が接続されている。
【００１９】
DBサーバ14は、DB管理システム（DBMS）21と、業務処理用の各種テーブル22を備えている。
DB管理システム21は、各テーブル22に格納されたデータの入出力、更新、および所定の演算などを行う。
【００２０】
各APサーバ12は、業務処理部24と、データ管理部26と、汎用処理部28と、DBアクセス処理部30と、メモリ32を備えている。
上記の業務処理部24、データ管理部26、汎用処理部28、DBアクセス処理部30は、APサーバ12のCPUが対応のアプリケーションプログラムに従って必要な処理を実行することによって実現される。
【００２１】
DBアクセス処理部30は、DBサーバ14の各テーブル22に一対一で対応する複数のテーブル対応部34を備えている。各テーブル対応部34は、それぞれ担当するテーブル22の構成（カラム名、データ型等）を認識しており、DBサーバ14に対して担当テーブル22宛のSQL文を発行すると共に、DBサーバ14から送信されたレコードをメモリ32に格納する機能を備えている。
【００２２】
データ管理部26は、各テーブル22とテーブル対応部34との対応関係を認識している。またデータ管理部26は、業務毎に必要となるテーブルの組合せを把握している。
【００２３】
汎用処理部28は、マッチング処理やソート処理、コントロールブレイク処理など、個別業務に依存しないデータ操作一般に共通する処理を実行するための関数群を備えている。以下、汎用処理部28によって実行されるデータ処理の一例を示す。
【００２４】
(1) innerJoin
これは、図２に示すように、２つのファイルＡ、Ｂを指定キー項目でマッチングし、両ファイルに存在する項目のデータを連結させてファイルに出力する処理である。
【００２５】
(2) leftOuterJoin
これは、図３に示すように、２つのファイルＡ、Ｂを指定キー項目でマッチングし、両ファイルに存在するレコードを連結させてファイルに出力し、何れかのファイルにしか存在しないレコードについては、準ファイル（ファイルＡ）に存在するレコードをファイルに出力する処理である。
【００２６】
(3) sumUp
これは、図４に示すように、指定キー項目に基づき、特定項目の値を集計してファイルに出力する処理である。
【００２７】
(4) avarage
これは、図５に示すように、指定キー項目に基づき、特定項目の値の平均値を算出してファイルに出力する処理である。
【００２８】
(5) match
これは、トランザクションとマスタファイルを指定項目キーでマッチングし、マッチした場合とマッチしなかった場合で異なる出力を実行する処理である。
例えば、図６に示すように、マスタとトランザクションを商品コードをキーとしてマッチングし、マッチした場合にはトランザクションの項目にマスタの商品名をセットしてファイルに出力し、マスタに存在しない商品コード及びトランザクションに存在しない商品コードについてはその旨を画面に表示することが該当する。
【００２９】
(6) controlBreak
これは、トランザクションを読み込み、レコードごとにコンティニュー処理を行うものであり、ブレイクキーが変わるタイミングで指定したブレイク処理を実行するものである。
例えば、図７に示すように、商品分類コード毎に売上合計数量と売上平均数量を計算し、ファイルに出力することが該当する。
【００３０】
(7) mergeBreak
これは、トランザクションとマスタファイルを指定項目キーに基づいてマージし、ブレイク処理を実行するものである。
例えば、図８に示すように、商品コード毎にトランザクションの売上数量を集計し、商品コードがブレイクした際に、マッチした場合にはトランザクションの項目にマスタの商品名をセットすると共に、トランザクションにしか存在しない場合には商品名に*******をセットしてファイルに出力する、またマスタにしか存在しない場合には売上なしとして商品コードを画面に表示することが該当する。
【００３１】
汎用処理部28は、上記した関数群を用いることにより、本来DBサーバ14によって実行されるデータ操作を代替することが可能となる。
【００３２】
ロードバランサ16は、クライアント端末20から送信されたリクエストを、各APサーバ12にかかっている負荷に応じて分散する役割を果たす。
【００３３】
クライアント端末20は、ＰＣ等のコンピュータよりなり、OSの他に、Webブラウザプログラムや専用のアプリケーションプログラムがセットアップされている。
【００３４】
図９〜図１３は、DBサーバ14に格納されたテーブル22の具体例を示すものであり、店テーブル40（図９）、配送グループテーブル42（図１０）、配送スケジュールテーブル44（図１１）、在庫テーブル46（図１２）、発注テーブル48（図１３）を備えている。
【００３５】
店テーブル40は、図９に示すように、店コードと店名のデータ項目を有している。
配送グループテーブル42は、店を配送グループに応じて分類するためのテーブルであり、図１０に示すように、配送グループコードと、店コードのデータ項目を有している。
【００３６】
配送スケジュールテーブル44は、図１１に示すように、配送グループコードと、AMと、PMのデータ項目を有している。午前配送が設定されている配送グループにはAMに「１」がセットされており、午前配送が設定されていない配送グループにはAMに「０」がセットされている。同様に、午後配送が設定されている配送グループにはPMに「１」がセットされており、午後配送が設定されていない配送グループにはPMに「０」がセットされている。
【００３７】
在庫テーブル46は、図１２に示すように、商品コードと在庫数量のデータ項目を有しており、商品別の在庫数量が記録される。
発注テーブル48は、図１３に示すように、店コード、商品コード、発注数量のデータ項目を有しており、受け付けた発注に関する情報が記録される。
【００３８】
つぎに、図１４のフローチャートに従い、このシステム10におけるデータ処理の手順を説明する。
まず、何れかのクライアント端末20から商品発注トランザクションが出力されると、何れかのAPサーバ12が、ロードバランサ16経由でこのトランザクションを受信する（Ｓ10）。
【００３９】
ここで、トランザクションのフォーマットの一例を図１５に示す。
トランザクション50は、トランザクションの種別を示す領域52と、データ領域54とを有する。
発注トランザクションの場合には、種別領域52に「発注」を示すデータがセットされている。また、データ領域54には、商品コードと、店コードと、発注数量とが含まれている。ここでは、商品コードに「S0001」が、店コードに「M001」が、発注数量に「25」がそれぞれセットされている。
【００４０】
これに対しAPサーバ12の業務処理部24は、種別領域52にセットされているデータを解析して、トランザクション種別を判定する（Ｓ12）。
ここでは、トランザクション種別は「発注」なので、業務処理部24は発注トランザクションの処理を実行する。
【００４１】
まず業務処理部24は、データ管理部26に対し、発注処理の実行に必要なデータとして、店コードと店名との対応データ、当該店舗が属する配送グループのデータ、各配送グループの配送スケジュールのデータ、対象商品の在庫量データ、発注管理データの取得を依頼する。
【００４２】
これを受けたデータ管理部26は、上記のデータの格納元として店テーブル40、配送グループテーブル42、配送スケジュールテーブル44、在庫テーブル46、発注テーブル48を特定した上で（Ｓ14）、DBアクセス処理部30における対応のテーブル対応部34に対し、必要データの取得を指令する（Ｓ15）。
【００４３】
これに対し各テーブル対応部34は、自身が担当するテーブル22からレコードを取得するためのSQL文をそれぞれ生成し、DBサーバ14に対し発行する（Ｓ16）。
これを受けたDBサーバ14のDB管理システム21は、該当のテーブル22からレコードを抽出し、APサーバ12の各テーブル対応部34に送信する。
これを受信した各テーブル対応部34は（Ｓ18）、送信されたデータをメモリ32に格納する（Ｓ20）。
【００４４】
業務処理部24は、このメモリ32上のデータに基づいて、発注トランザクションに必要な処理を実行する。このとき業務処理部24は、汎用処理部28が備える関数群を利用する。
【００４５】
まず業務処理部24は、発注のあった店舗に関する配送グループを特定する（Ｓ22）。
具体的には、発注トランザクションデータおよび配送グループデータについて、店コードをキーにソートしたのち、同じく店コードをキーとしたマッチングを行ない、発注のあった店に関連付けられた配送グループコードを特定して発注トランザクションデータに付与する。
そして、付与された配送グループコードをキーに、発注トランザクションデータと配送スケジュールデータをソートし、配送グループコードをキーにマッチングすることで、配送グループ（午前のみか、午後のみか、午前および午後か）を特定する。
【００４６】
上記のソート処理やキー部の値のマッチング処理に際し、汎用処理部28が備える関数群が用いられる。
また、この汎用処理部28が動作する際には、メモリ32上のデータが、データ管理部26によって汎用的なレコード型に代入される。
このように、汎用処理部28の動作に先立って汎用的なレコード型に代入されることにより、汎用処理部28はデータ型を意識することなく、各データを単純にカラム名で扱うことが可能となり、汎用的な処理が実現される。
汎用処理部28によるデータ操作が終了した時点で、データ管理部26によって処理結果データは業務処理部24に応じた固有のデータ型に変換される。
【００４７】
ここで、午前配送および午後配送で配送を行うためには、それぞれ発注を受け付ける時間帯があらかじめ定められている。このため、業務処理部24は、発注があった店舗の配送グループと現在時刻とに基づいて、その店の発注要求を受け付け可能な時間帯であるかどうかを判定する（Ｓ24）。
発注可能な時間帯でないときは（Ｓ24：No）、以下の処理をスキップする。
【００４８】
発注可能な時間帯であるときは（Ｓ24：Yes）、業務処理部24は発注のあった商品の在庫の有無を確認する（Ｓ26）。例えば、商品コードをキーにして在庫データを検索し、在庫数量と発注数量とを比較する。
【００４９】
在庫数量が発注数量よりも少ないときは（Ｓ26：No）、以下の処理をスキップする。
在庫数量が発注数量よりも少なくないときは（Ｓ26：Yes）、業務処理部24はメモリ32上の在庫データ及び発注データを更新する（Ｓ28）。
【００５０】
メモリ32上のデータが更新されると、データ管理部26は在庫テーブル46を担当するテーブル対応部34及び発注テーブル48を担当するテーブル対応部34に対してレコードの更新を指令する（Ｓ29）。
これを受けた各テーブル対応部34は、この指令に基づいてメモリ32から必要なデータを取得し、単一のテーブルに対するSQL文を生成した後、それぞれDBサーバ14に発行する（Ｓ30）。
この結果、DBサーバ14上の対応テーブル22が更新される（Ｓ32）。
【００５１】
以上に説明した手順により、発注トランザクションに係る処理が完了する。
この後、業務処理部24は上記のような処理が実行された結果を、トランザクション送信元のクライアント端末20に返信する。
すなわち、発注処理が完了したときはその旨を返信し、発注処理が完了しなかったときは、その理由を返信する。
【００５２】
本実施形態によれば、DBサーバ14上のデータに対する実質的な処理は、DB管理システム21ではなく、APサーバ12が行う。
そして、APサーバ12は複数台あるので、従来はDBサーバ14に集中していた処理を分散させることができる。
したがって、従来に比べてDBサーバ14にかかる負荷は軽減され、システム10全体での処理速度は向上する。
【００５３】
しかも、APサーバから発行されるSQL文は、全てが単一テーブルを対象としたものであり、その構文が単純化される結果、１SQL当たりのDBサーバ14への負荷を軽減し、巨大なSQLの実行に伴う予期せぬシステムのスローダウンを回避可能となる。
【００５４】
なお、各テーブル対応部34から担当のテーブル22に対してSQL文を発行するに際し、必要な範囲のデータを一度に取得する代わりに、所定数に分割して取得するように指令することができる。
例えば、特定のテーブル22から10,000件のデータを抽出する必要がある場合に、1,000件ずつ取得することを命じるSQL文を10回に分けて発行することにより、DBサーバ14側のリソース（通常は複数個のCPUを備える）を有効活用し、巨大な要求に対する高速化を実現可能となる。
この場合、各テーブル対応部24は、分割取得したデータを順次メモリ32上に格納し、全てのデータが揃った時点でデータを整列結合させる。
【００５５】
このような検索の並列処理化によって分割取得した結果を統合するという処理には比較的大きな負荷がかかるが、これをDBサーバ14側ではなく分散処理化が容易なAPサーバ12側で行うことにより、システム全体での効率化を達成できる。
【００５６】
このように、APサーバ12のDBアクセス処理部30からは単一のテーブル単位でSQL文が発行される仕組みであるため、DBアクセス処理部30を実現するためのプログラムも単純化され、その分開発が容易となるのは勿論、プログラムの再利用性や保守性が向上する利点がある。
【００５７】
APサーバ12側の処理の中、従来DBサーバ14で行われていたデータ操作自体は汎用処理部28の関数群を通じて処理されるため、業務処理部24は業務ロジックに特化でき、その分コードを簡素化できる。
【００５８】
上記のように、各テーブル22からもたらされたデータは、データ管理部26によって抽象的なデータ型であるレコード型に代入された後、汎用処理部28によるデータ操作に供される仕組みであるため、汎用処理部28はテーブル22毎の具体的なデータ型を認識する必要がなくなり、その汎用性を担保することができる。
また、汎用処理部28によるデータ操作が終了した時点で、データ管理部26によって処理結果データが業務処理部24に応じた固有のデータ型に変換されるため、業務処理部24においてデータ型の不一致に基づくエラーチェックが可能となる。
【００５９】
上記のように、データ管理部26が業務単位で必要となる具体的なテーブルの組合せを認識しており、またDBアクセス処理部30の各テーブル対応部34が担当するテーブル22の構成（カラム名、データ型等）を認識しているため、業務処理部24はDBサーバ14側のテーブル構造を意識する必要がない。このため、業務処理部24のコーディングが容易化するのはもちろんのこと、テーブル構造に変更が生じてもデータ管理部26及び該当のテーブル対応部34のコードを修正するだけで済み、業務処理部24のコードはそのまま使える利点が生じる。
【００６０】
DBサーバ14からのデータをメモリ32に格納する前に、DBアクセス処理部30の各テーブル対応部34により、それぞれのデータ型がPrimitive型に変換されるように構成してもよい。
例えば、String型の代わりにbyte配列型を、BigDecimal型の代わりにdouble型を用いることにより、数十倍のオーダーでメモリ消費量を削減可能となり、APサーバ12上で扱えるデータ件数を大幅に増やすことが可能となる。
この場合、汎用処理部28によるデータ操作が完了した後、データ管理部26によってもとのデータ型に再変換される。
【図面の簡単な説明】
【００６１】
【図１】この発明に係るデータ処理システムの全体構成図である。
【図２】汎用処理部によって実行される関数「innerJoin」を示す説明図である。
【図３】汎用処理部によって実行される関数「leftOuterJoin」を示す説明図である。
【図４】汎用処理部によって実行される関数「sumUp」を示す説明図である。
【図５】汎用処理部によって実行される関数「avarage」を示す説明図である。
【図６】汎用処理部によって実行される関数「match」を示す説明図である。
【図７】汎用処理部によって実行される関数「controlBreak」を示す説明図である。
【図８】汎用処理部によって実行される関数「mergeBreak」を示す説明図である。
【図９】店テーブルの一例を示す図である。
【図１０】配送グループテーブルの一例を示す図である。
【図１１】配送スケジュールテーブルの一例を示す図である。
【図１２】在庫テーブルの一例を示す図である。
【図１３】発注テーブルの一例を示す図である。
【図１４】このシステムによるデータ処理の手順を示すフローチャートである。
【図１５】トランザクションのフォーマットの一例を示す図である。
【符号の説明】
【００６２】
10  データ処理システム
12  APサーバ
14  DBサーバ
16  ロードバランサ
20  クライアント端末
21  DB管理システム
22  テーブル
24  業務処理部
26  データ管理部
28  汎用処理部
30  アクセス処理部
32  メモリ
34  テーブル対応部
40  店テーブル
42  配送グループテーブル
44  配送スケジュールテーブル
46  在庫テーブル
48  発注テーブル
50  トランザクション
52  種別領域
54  データ領域
【図１】
2008250588.tif 000003
【図２】
2008250588.tif 000004
【図３】
2008250588.tif 000005
【図４】
2008250588.tif 000006
【図５】
2008250588.tif 000007
【図６】
2008250588.tif 000008
【図７】
2008250588.tif 000009
【図８】
2008250588.tif 000010
【図９】
2008250588.tif 000011
【図１０】
2008250588.tif 000012
【図１１】
2008250588.tif 000013
【図１２】
2008250588.tif 000014
【図１３】
2008250588.tif 000015
【図１４】
2008250588.tif 000016
【図１５】
2008250588.tif 000017