JP2017167843A - 取引明細管理システムおよび取引明細管理方法 - Google Patents

取引明細管理システムおよび取引明細管理方法 Download PDF

Info

Publication number
JP2017167843A
JP2017167843A JP2016052868A JP2016052868A JP2017167843A JP 2017167843 A JP2017167843 A JP 2017167843A JP 2016052868 A JP2016052868 A JP 2016052868A JP 2016052868 A JP2016052868 A JP 2016052868A JP 2017167843 A JP2017167843 A JP 2017167843A
Authority
JP
Japan
Prior art keywords
transaction details
transaction
account
accumulation
details
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2016052868A
Other languages
English (en)
Inventor
林 真一
Shinichi Hayashi
真一 林
幸雄 小河
Yukio Ogawa
幸雄 小河
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2016052868A priority Critical patent/JP2017167843A/ja
Publication of JP2017167843A publication Critical patent/JP2017167843A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】金融システムにおいて取引明細を管理するデータベースの運用を効率化する。【解決手段】取引明細管理システム100において、他装置とネットワークを介して通信する通信装置105と、勘定系から取引明細を得て記憶装置に蓄積するに際し、当該蓄積時期および取引対象の口座ごとに取引明細をカウントしたレコード数を第1テーブルに格納し、蓄積時期が同じ取引明細に当該蓄積時期および当該口座を対応付けて第2テーブルに格納する処理と、所定端末から取引明細の照会要求を受信した場合、当該照会要求が示す蓄積期間に蓄積時期が含まれ、当該照会要求の示す口座を取引対象の口座とするレコード数を第1テーブルで判定し、当該判定によりレコードが存在する場合に、第2テーブルから当該蓄積期間に蓄積時期が含まれ、当該照会要求の示す口座を取引対象の口座とする取引明細のデータを抽出して所定端末に返信する処理を実行する演算装置104を含む構成とする。【選択図】図2

Description

本発明は、取引明細管理システムおよび取引明細管理方法に関するものであり、具体的には、金融システムにおいて取引明細を管理するデータベースの運用を効率化する技術に関する。
勘定系で処理された情報を蓄積・管理し、所定端末等からの要求に応じて、対応する情報の抽出や応答、或いは勘定系に対する処理依頼等を仲介する、いわゆる外部センタと呼ばれるシステムが存在する。
こうした外部センタが取り扱う金融機関の各種業務は、ミッションクリティカルかつ膨大であり、対応システムでのデータ処理も高速で高い信頼性を備える必要がある。そこで、データ規模が大きなデータベースであっても高速な処理が可能で、応答時間の推測精度も高い階層型データベースが従来から採用されてきた。
上述のような階層型データベースに関係する技術としては、例えば、金融商品に関するデータを各データの種類に対応したアイテムコード及び金融商品の銘柄コードに関連付けて記録する複数のテーブルを、商品種別及びデータのサイクル毎に格納しておく記憶手段と、特定のテーブルから特定のアイテムコード及び指定の銘柄コードに係るデータを指定の期間分抽出することを規定するストアドプロシージャを、固有のストアドプロシージャ名に関連付けて複数格納しておくストアドプロシージャ記憶手段と、各ストアドプロシージャ名と、アイテムコード、データのサイクル及び商品種別との対応関係を予め定義しておくストアドプロシージャ情報記憶手段と、検索条件として銘柄コード、商品種別、サイクル、抽出期間及びアイテムコードが入力された場合に、商品種別、サイクル及びアイテムコードに基づき、適用すべきストアドプロシージャ名を特定する手段と、このストアドプロシージャ名に基づき、上記ストアドプロシージャ記憶手段から該当のストアドプロシージャを呼び出す手段と、このストアドプロシージャに上記銘柄コード及び抽出期間を充填し、特定のテーブルから特定のアイテムコード及び指定の銘柄コードに係るデータを指定の期間分抽出する手段と、この検索結果データを出力する手段と、を備えたことを特徴とするデータ検索システム(特許文献1参照)などが提案されている。
また、統合販売処理支援システムであって、中央データベースを有し、データを複数のソースから中央データベースに入力する手段を有し、構造化照会に応じて前記データベースをサーチし、かつ前記照会に一致するレコードを識別する手段を有し、複数のユーザワークステーションを含む少なくとも1つのマイクロマーケティングセンターを有し、ユーザワークステーションのグラフィックユーザインタフェースからのユーザの基準の選択に応じて前記データベースの前記構造化照会を形成する手段を有し、複数の地理的に分離された支店システムを有し、各支店システムが少なくとも1つの支店ワークステーションを含み、中央顧客情報システムを有し、前記中央顧客情報システムが、地理的に分離されているが、電子通信により支店システムのワークステーションにリンクされる、統合販売処理支援システム(特許文献2参照)なども提案されている。
特開2007−4222号公報 特表平11−513826号公報
ところが、こうした階層型データベースを上述の外部センタの如き金融システムに採用した場合、以下の問題が残されている。すなわち、当該データベースのオンライン中の使用状況監視や容量見積自体が困難で、容量逼迫の状況が生じてもオンライン中の容量拡張が出来ない、という問題がある。また、データベースの格納データにパッチを充てるのが困難という問題もある。
そこで本発明の目的は、金融システムにおいて取引明細を管理するデータベースの運用を効率化する技術を提供することにある。
上記課題を解決する本発明の取引明細管理システムは、他装置とネットワークを介して通信する通信装置と、勘定系から取引明細を得て記憶装置に蓄積するに際し、当該蓄積時期および取引対象の口座ごとに取引明細をカウントしたレコード数を第1テーブルに格納し、前記蓄積時期が同じ取引明細に当該蓄積時期および当該口座を対応付けて第2テーブルに格納する処理と、所定端末から取引明細の照会要求を受信した場合、当該照会要求が示す蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とするレコード数を前記第1テーブルで判定し、当該判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出して前記所定端末に返信する処理を実行する演算装置と、を含むことを特徴とする
また、本発明の取引明細管理方法は、他装置とネットワークを介して通信する通信装置を備えた情報処理システムが、勘定系から取引明細を得て記憶装置に蓄積するに際し、当該蓄積時期および取引対象の口座ごとに取引明細をカウントしたレコード数を第1テーブルに格納し、前記蓄積時期が同じ取引明細に当該蓄積時期および当該口座を対応付けて第2テーブルに格納する処理と、所定端末から取引明細の照会要求を受信した場合、当該照会要求が示す蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とするレコード数を前記第1テーブルで判定し、当該判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出して前記所定端末に返信する処理と、を実行することを特徴とする。
本発明によれば、金融システムにおいて取引明細を管理するデータベースの運用を効率化できる。
本実施形態の取引明細管理システムを含むネットワーク構成図である。 本実施形態における取引明細管理システムのハードウェア構成例を示す図である。 本実施形態の取引明細データの構成例を示す図である。 本実施形態の日別口座蓄積テーブルのデータ構成例を示す図である。 本実施形態の取引明細蓄積テーブルのデータ構成例を示す図である。 本実施形態における取引明細管理方法のフロー例1を示す図である。 本実施形態の階層型データベースの構成例を示す図である。 本実施形態における取引明細管理方法のフロー例2を示す図である。 本実施形態の照会要求パケットの構成例を示す図である。 本実施形態の取引明細データ(返信分)の構成例を示す図である。
−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図1は、本実施形態の取引明細管理システム100を含むネットワーク構成図である。図1に示す取引明細管理システム100は、金融システムにおいて取引明細を管理するデータベースの運用を効率化するコンピュータシステムである。
当該取引明細管理システム100は、セキュアなネットワーク10を介して、勘定系システム200および端末300とデータ通信可能に結ばれている。このうち勘定系システム200は、金融機関において運用されている基幹システムであり、金融取引に応じた適宜な処理を実行し、その結果を取引明細として取引明細管理システム100に返す機能を備える。
一方、端末300は、当該金融機関の顧客が利用する端末である。端末300を操作する顧客は、いわゆるインターネットバンキング等の遠隔処理にって、自身の金融取引の結果や口座残高確認等の、照会や取引の要求を行う。
他方、当該取引明細管理システム100は、上述の勘定系システム200から得た取引明細のデータを自身の記憶装置に格納すると共に、端末300からの照会要求に応じて、対応する取引明細データを読み出し、適宜形態に編集等して返信する。従って、取引明細管理システム100は、金融機関システムにおける、いわゆるANSERシステムの機能の全部または一部を備えるものを想定出来る。
−−−ハードウェア構成−−−
また、取引明細管理システム100のハードウェア構成は以下の如くとなる。図2に本実施形態の取引明細管理システム100のハードウェア構成例を示す。
当該取引明細管理システム100は、SSD(Solid State Drive)やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置101、RAMなど揮発性記憶素子で構成されるメモリ103、記憶装置101に保持されるプログラム102をメモリ103に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうCPUなどの演算装置104、ネットワーク10と接続し他装置との通信処理を担う通信装置105、を備える。
なお、記憶装置101内には、本実施形態の取引明細管理システム100として必要な機能を実装する為のプログラム102の他に、取引明細データ125、日別口座蓄積テーブル126、取引明細蓄積テーブル127、および階層型データベース130を保持している。これらテーブル等の具体的な構成については後述する。
但し、階層型データベース130は必須ではない。当該取引明細管理システム100における取引明細の管理が、日別口座蓄積テーブル126および取引明細蓄積テーブル127の構成によるものに置き換わった後は当該取引明細管理システム100が管理・運用せずともよい。
−−−データ構造例−−−
続いて、本実施形態の取引明細管理システム100が用いるデータについて説明する。図3に、本実施形態における取引明細データ125の一例を示す。この取引明細データ125は、取引明細管理システム100が勘定系システム200から受信し、記憶装置10
1に格納した各取引明細の集合体である。
そのデータ構造は、取引明細の発生業務の対象口座を一意に特定する、店番、科目、および口座番号をキーとして、当該取引明細を勘定系システム200から得た蓄積日付、勘定系システム200で付与されていた明細通番、対象取引を示す明細属性、明細状態、取引金の入出金を示す入払区分、取引金額、データ種別、取扱日付、金額、摘要名、振込人名、銀行名、支店名、取引後残高、といったデータから成るレコードの集合体である。
こうした取引明細の各値の構成自体は、既存の取引明細のものと同様である。
また図4に、本実施形態における日別口座蓄積テーブル126の一例を示す。この日別口座蓄積テーブル126は、勘定系システム200から上述の取引明細を得るごとに更新される、取引明細群のメタ情報を蓄積したテーブルである。
そのデータ構造は、取引明細データ125の各レコード、すなわち取引明細のうち、店番、科目、および口座番号と、蓄積日付とをキーとして、当該キーに対応する取引明細の蓄積数たる最終蓄積番号(取引明細データ125で保持する数)の値を対応付けたレコードの集合体である。
また図5に、本実施形態の取引明細蓄積テーブル127のデータ構成例を示す。この取引明細蓄積テーブル127は、上述の取引明細データ125の各レコード、すなわち取引明細データに対し、その蓄積順に蓄積番号を付与したレコードを格納したテーブルである。 そのデータ構造は、各取引明細を一意に特定する、当該取引明細の発生業務の対象口座を一意に特定する、店番、科目、口座番号、蓄積日付、および蓄積番号をキーとして、当該取引明細に関して勘定系システム200で付与されていた明細通番、対象取引を示す明細属性、明細状態、取引金の入出金を示す入払区分、取引金額、および、当該取引明細データ(の実体)、といったデータから成るレコードの集合体である。
−−−フロー例1−−−
以下、本実施形態における取引明細管理方法の実際手順について図に基づき説明する。以下で説明する取引明細管理方法に対応する各種動作は、取引明細管理システム100がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
図6は、本実施形態における取引明細管理方法のフロー例1を示す図である。ここではまず、取引明細管理システム100が、既存の階層型データベース130を保持しており、これを当該取引明細管理方法に適合させるべく、リレーショナルデータベース形式に変換する処理から実行するものとする。
なお、この階層型データベース130は、図7にて例示するように、取引明細データの蓄積ファイルとして、1つの論理キー1311に複数のデータブロック1312を格納する階層型ファイル1313を用いている。この階層型ファイル1313には、取引明細データ1314へのチェーン情報を格納する取引明細蓄積インデックスファイル133と、取引明細データ1314を格納する取引明細蓄積ファイル134がある。また、それらの上位には蓄積された取引明細データ数等のメタ情報を管理する日別蓄積口座表131がある。いずれにしても、こうした階層型データベース130における各構成は従来通りの既存のものである。
従来における、こうした階層型ファイル1313の入出力は、該当取引明細データが紐付いた、論理キー1311と、格納先のデータブロック1312を示す蓄積ブロック番号
を用いて、ブロック単位で行うこととなる。
参考のため、従来から行われてきた、階層型データベース130におけるデータの入出力手順を概説する。
この場合、当該階層型データベース130にアクセスする所定の情報処理装置(従来型の外部センタ)が、勘定系システム200からの取引明細データの受信に伴い、日別口座蓄積表131を読み込み、この日別口座蓄積表の「取引明細インデックス末尾蓄積ブロック番号」、「取引明細インデックス末尾蓄積エントリ番号」を用いて、取引明細蓄積インデックスファイル133を読み込む(取引明細蓄積ファイル最終ブロック番号の取得)。また、この情報処理装置は、取引明細蓄積ファイル134の最終ブロックを読み込む。
次に、情報処理装置は、取引明細データ1314を、取引明細蓄積ファイル134におけるブロックの最終エントリに設定(ブロックが満杯の場合は新規ブロックの作成)し、取引明細蓄積ファイル134を更新する。
また、情報処理装置は、取引明細インデックス132を、取引明細蓄積インデックスファイル133におけるブロックの最終エントリに設定(ブロックが満杯の場合は新規ブロックの作成)し、取引明細蓄積インデックスファイル133を更新する。また、情報処理装置は、日別口座蓄積表131の取引明細データ数等を更新する。
また、こうした情報処理装置は、端末からの照会要求を受信した場合、日別口座蓄積表131を読み込む。また情報処理装置は、以下の処理を要求元指定範囲の取引明細データを取得するまで繰り返す。すなわち、1.取引明細インデックスの取得(日別口座蓄積表の先頭→取引明細蓄積インデックスファイルの先頭ブロック→次ブロックの順)、2.取引明細インデックスが取得対象の取引明細データであるかを判定(「明細属性」が要求元指定サービスの対象、かつ「明細状態」が「通常」)、3.取引明細インデックスの「蓄積ブロック番号」、「蓄積エントリ番号」から取引明細蓄積ファイルを読み込み、取引明細データを取得、の各処理である。
一方、本実施形態の取引明細管理方法を実行する取引明細管理システム100は、こうした既存の階層型データベース130を、リレーショナルデータベース形式に変換することが可能である。
この場合、取引明細管理システム100は、階層型データベース130における、日別口座蓄積表131から、例えば1日ごと勘定系システム200から得た各取引明細に関する、蓄積日付と、当該取引明細が示す取引対象の口座情報(店番、科目、口座番号)と、当該蓄積日付および当該口座ごとに取引明細をカウントしたレコード数たる、取引明細インデックス末尾蓄積エントリ番号、の各情報を抽出し、店番、科目、口座番号、および蓄積日付ごとにレコードを生成し、その蓄積レコード数欄に、取引明細インデックス末尾蓄積エントリ番号を設定することで、日別口座蓄積テーブル126を構成する(s100)。
次に取引明細管理システム100は、上述の階層型データベース130における、日別口座蓄積表131にて規定した格納位置(蓄積ブロック番号が示すデータブロックのうち、蓄積エントリ番号が示す位置)に格納された各取引明細を、取引対象の口座および蓄積日付に対応付けてレコードを生成し、当該レコードを蓄積することで取引明細蓄積テーブル127を構成する(s101)。
つまり、本実施形態の取引明細管理システム100は、階層型データベース130に格
納している取引明細データを、上述のように1レコード1明細とする形態ことで、リレーショナルデータベース形式に変更する。このことで、階層型ファイルでの取引明細データとブロックの間の変換処理は不要となる。
続いて、当該取引明細管理システム100が、勘定系システム200から取引明細データを受信したとする(s102)。ここで受信した取引明細データは、図3で例示した取引明細データ125におけるレコードの各欄の値を含んでいる。
続いて取引明細管理システム100は、日別口座蓄積テーブル126の各レコードのうち、s102で受信した取引明細データと店番、科目、口座番号、および蓄積日付、の各値が一致するものが存在するか判定する(s103)。
この判定の結果、s102で得た取引明細データと一致するレコードが、日別口座蓄積テーブル126で特定出来なかった場合(s104:n)、取引明細管理システム100は、s102で得た取引明細データの示す各値を含むレコードを生成し、これを日別口座蓄積テーブル126に格納する(s105)。この格納に際し、取引明細管理システム100は、当該レコードの最終蓄積番号欄の値に、s102で得た該当レコード数の値を設定するものとする。
一方、上述の判定の結果、s102で得た取引明細データと一致するレコードが、日別口座蓄積テーブル126で特定出来た場合(s104:y)、取引明細管理システム100は、当該レコードの最終蓄積番号欄の値に、s102で得た該当レコード数の値を加算し更新する(s106)。
また、取引明細管理システム100は、s102で得た取引明細データを、取引明細蓄積テーブル127に格納する(s107)。また取引明細管理システム100は、この格納に際し、格納対象のレコードの蓄積番号欄に上述の最終蓄積番号の値を設定する(s108)。ここで設定する最終蓄積番号の値は、s103にて日別口座蓄積テーブル126で既存レコードが特定できず、s105で蓄積番号欄に設定した値か、或いは、s103にて日別口座蓄積テーブル126で既存レコードが特定でき、s106で更新した最終蓄積番号の値となる。
取引明細管理システム100は、以上の各処理を、勘定系システム200から取引明細データを受信するごとに、或いは、一定期間ごとに実行し、日別口座蓄積テーブル126および取引明細蓄積テーブル127を更新していく。
−−−フロー例2−−−
次に、端末300から照会要求パケットを受信した場合の処理について図に基づき説明する。図8は、本実施形態における取引明細管理方法のフロー例2を示す図である。
この場合、取引明細管理システム100は、端末300から、図9で示す照会要求パケット128を受信したとする(s200)。図9で例示するように、照会要求パケット128は、照会対象とする取引明細のメタ情報(店番、科目、口座番号)、取引種類を示す明細属性、蓄積期間の開始日および終了日、といったデータを含んでいる。
続いて取引明細管理システム100は、s200で得た照会要求パケット128の示す蓄積期間(すなわち蓄積期間の開始日から終了日の間)に蓄積日付が含まれ、当該照会要求パケット128の示す口座を、取引対象の口座とするレコードを、日別口座蓄積テーブル126で検索する(s201)。
この検索の結果、該当レコードが日別口座蓄積テーブル126で特定出来なかった場合(s202:n)、取引明細管理システム100は、該当取引明細データが存在しない旨の所定メッセージを、上述の端末300に返信し(s203)、処理を終了する。
他方、上述の検索の結果、該当レコードが日別口座蓄積テーブル126で特定できた場合(s202:y)、取引明細管理システム100は、取引明細蓄積テーブル127に対し、以下のSQLを発行して、照会要求パケット128が示す取引明細データを一括で取得する(s204)。
この場合のSQLは、例えば、SELECT:「取引明細データ」 FROM:「取引明細蓄積テーブル」 WHERE:「明細属性」=照会要求パケット128の明細属性 AND:「明細状態」=「通常」、の各値を含むものとなる。
図9で述べた照会要求パケット128は、店番「100」、科目「1」、口座番号「1234567」、明細属性「振込」、蓄積期間「20150901〜20150903」であったため、該当するメタ情報等が紐付いた取引明細データ129として図10に示すものが取得出来る。
なお、こうしたSQL発行による取引明細データの取得に際し、取引明細管理システム100は、予め、取引明細蓄積テーブル127の各レコードを、「蓄積番号」で昇順にソートしておくものとする。
ここで取引明細管理システム100は、ソートにより値の小さい順に整列した各取引明細データの蓄積番号と、その明細通番の順序とが整合しているか判定するものとする。例えば、あるメタ情報に関する3つのレコード「A」、「B」、「C」は、それぞれ蓄積番号が「2」、「1」、「3」、であって、上述のソートによって、「B」、「A」、「C」の順に整列したとする。また、この3つのレコード、「B」、「A」、「C」の明細通番が、「3」、「1」、「2」であった場合、取引明細管理システム100は、当該レコード群に関して、蓄積番号と明細通番の順序とが整合していない、と判定する。この場合、取引明細管理システム100は、明細通番の昇順で該当レコードをあらためてソートする。上述の場合であれば、最終的には、3つのレコード、「B」、「A」、「C」が、「A」、「C」、「B」と並ぶことになる。
上述のように取引明細データを得た取引明細管理システム100は、取得した取引明細データ129を、上述の端末300に返信し(s205)、処理を終了する。
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、金融システムにおいて取引明細を管理するデータベースの運用を効率化できる。この場合、従来から存在する階層型データベースにおける取引明細蓄積インデックスファイル、取引明細蓄積ファイルの正規化を行って、これら2つの階層型ファイルを1つの取引明細蓄積テーブル(RDB)に変換し、取引明細データを1レコード1明細として格納する。こうした階層型データベースのRDB化により、階層型ファイルのデータ格納位置を管理する蓄積ブロック番号、蓄積エントリ番号の管理は不要となる。よって、取引明細の照会要求に対し、従来において実行していた取引明細データとブロックの変換処理、および取引明細インデックスの検索処理が不要となり、処理の効率化が図られる。また、RDB化により、当該データベースの運用、保守の効率も向上する。
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の取引明細管理システムにおいて、前記演算装置は、前記第2テーブルへの取引明細の格納に際し、前記蓄積時期が同じ取引明細の取得順に当該取引明細に蓄積番号を付与し、前記蓄積時期および前記蓄積番号と当該取引明細の明細通番とを当該取引明細に対応付けて前記第2テーブルに格納するものであり、前記取引明細のデータを前記所定端末に返信する処理に際し、前記判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出し、当該抽出した各取引明細の蓄積番号と明細通番の順序が整合していない場合、明細通番の順に当該取引明細のデータをソートして前記所定端末に返信するものである、としてもよい。
これによれば、取引明細の蓄積順序と取引明細の明細通番とが、各取引明細の配信環境等に影響を受けて錯綜してしまった状況にも対処し、取引明細の要求側で認識や処理がしやすい形態で取引明細のデータを返信することが出来る。
また、本実施形態の取引明細管理システムにおいて、取引明細を保持する階層型データベースを格納した記憶装置を備え、前記演算装置は、前記階層型データベースにおける、所定期間に勘定系から得た取引明細群のメタ情報を保持する蓄積テーブルから、勘定系から取引明細を得て記憶装置に蓄積した時期である蓄積時期と、当該取引明細が示す取引対象の口座と、当該蓄積時期および当該口座ごとに取引明細をカウントしたレコード数の各情報を抽出して前記第1テーブルを構成し、前記階層型データベースにおける、前記蓄積テーブルにて規定した格納位置に格納された各取引明細を、取引対象の口座および蓄積時期に対応付けたレコードを生成および蓄積して前記第2テーブルを構成する処理を更に実行するものであるとしてもよい。
これによれば、既存の階層型データベースをリレーショナルデータベースに変換し、当該取引明細管理システムにて運用、管理を行うことが出来る。ひいては、金融システムにおいて取引明細を管理するデータベースの運用を更に効率化できる。
また、本実施形態の取引明細管理方法において、前記情報処理システムが、前記第2テーブルへの取引明細の格納に際し、前記蓄積時期が同じ取引明細の取得順に当該取引明細に蓄積番号を付与し、前記蓄積時期および前記蓄積番号と当該取引明細の明細通番とを当該取引明細に対応付けて前記第2テーブルに格納し、前記取引明細のデータを前記所定端末に返信する処理に際し、前記判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出し、当該抽出した各取引明細の蓄積番号と明細通番の順序が整合していない場合、明細通番の順に当該取引明細のデータをソートして前記所定端末に返信する、としてもよい。
また、本実施形態の取引明細管理方法において、取引明細を保持する階層型データベースを格納した記憶装置を備える情報処理システムが、前記階層型データベースにおける、所定期間に勘定系から得た取引明細群のメタ情報を保持する蓄積テーブルから、勘定系から取引明細を得て記憶装置に蓄積した時期である蓄積時期と、当該取引明細が示す取引対象の口座と、当該蓄積時期および当該口座ごとに取引明細をカウントしたレコード数の各情報を抽出して前記第1テーブルを構成し、前記階層型データベースにおける、前記蓄積テーブルにて規定した格納位置に格納された各取引明細を、取引対象の口座および蓄積時期に対応付けたレコードを生成および蓄積して前記第2テーブルを構成する処理を更に実行する、としてもよい。
10 ネットワーク
100 取引明細管理システム
101 記憶装置
102 プログラム
103 メモリ
104 演算装置
105 通信装置
125 取引明細データ
126 日別口座蓄積テーブル(第1テーブル)
127 取引明細蓄積テーブル(第2テーブル)
128 照会要求パケット
129 取引明細データ(返信分)
130 階層型データベース
131 日別口座蓄積表(蓄積テーブル)
132 取引明細インデックス
133 取引明細蓄積インデックスファイル
134 取引明細蓄積ファイル
200 勘定系システム
300 端末

Claims (6)

  1. 他装置とネットワークを介して通信する通信装置と、
    勘定系から取引明細を得て記憶装置に蓄積するに際し、当該蓄積時期および取引対象の口座ごとに取引明細をカウントしたレコード数を第1テーブルに格納し、前記蓄積時期が同じ取引明細に当該蓄積時期および当該口座を対応付けて第2テーブルに格納する処理と、
    所定端末から取引明細の照会要求を受信した場合、当該照会要求が示す蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とするレコード数を前記第1テーブルで判定し、当該判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出して前記所定端末に返信する処理を実行する演算装置と、
    を含むことを特徴とする取引明細管理システム。
  2. 前記演算装置は、
    前記第2テーブルへの取引明細の格納に際し、前記蓄積時期が同じ取引明細の取得順に当該取引明細に蓄積番号を付与し、前記蓄積時期および前記蓄積番号と当該取引明細の明細通番とを当該取引明細に対応付けて前記第2テーブルに格納するものであり、
    前記取引明細のデータを前記所定端末に返信する処理に際し、前記判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出し、当該抽出した各取引明細の蓄積番号と明細通番の順序が整合していない場合、明細通番の順に当該取引明細のデータをソートして前記所定端末に返信するものである、
    ことを特徴とする請求項1に記載の取引明細管理システム。
  3. 取引明細を保持する階層型データベースを格納した記憶装置を備え、
    前記演算装置は、
    前記階層型データベースにおける、所定期間に勘定系から得た取引明細群のメタ情報を保持する蓄積テーブルから、勘定系から取引明細を得て記憶装置に蓄積した時期である蓄積時期と、当該取引明細が示す取引対象の口座と、当該蓄積時期および当該口座ごとに取引明細をカウントしたレコード数の各情報を抽出して前記第1テーブルを構成し、
    前記階層型データベースにおける、前記蓄積テーブルにて規定した格納位置に格納された各取引明細を、取引対象の口座および蓄積時期に対応付けたレコードを生成および蓄積して前記第2テーブルを構成する処理を更に実行するものである、
    ことを特徴とする請求項1に記載の取引明細管理システム。
  4. 他装置とネットワークを介して通信する通信装置を備えた情報処理システムが、
    勘定系から取引明細を得て記憶装置に蓄積するに際し、当該蓄積時期および取引対象の口座ごとに取引明細をカウントしたレコード数を第1テーブルに格納し、前記蓄積時期が同じ取引明細に当該蓄積時期および当該口座を対応付けて第2テーブルに格納する処理と、
    所定端末から取引明細の照会要求を受信した場合、当該照会要求が示す蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とするレコード数を前記第1テーブルで判定し、当該判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出して前記所定端末に返信する処理と、
    を実行することを特徴とする取引明細管理方法。
  5. 前記情報処理システムが、
    前記第2テーブルへの取引明細の格納に際し、前記蓄積時期が同じ取引明細の取得順に当該取引明細に蓄積番号を付与し、前記蓄積時期および前記蓄積番号と当該取引明細の明細通番とを当該取引明細に対応付けて前記第2テーブルに格納し、
    前記取引明細のデータを前記所定端末に返信する処理に際し、前記判定によりレコードが存在する場合に、前記第2テーブルから当該蓄積期間に前記蓄積時期が含まれ、当該照会要求の示す口座を前記取引対象の口座とする取引明細のデータを抽出し、当該抽出した各取引明細の蓄積番号と明細通番の順序が整合していない場合、明細通番の順に当該取引明細のデータをソートして前記所定端末に返信する、
    ことを特徴とする請求項4に記載の取引明細管理方法。
  6. 取引明細を保持する階層型データベースを格納した記憶装置を備える情報処理システムが、
    前記階層型データベースにおける、所定期間に勘定系から得た取引明細群のメタ情報を保持する蓄積テーブルから、勘定系から取引明細を得て記憶装置に蓄積した時期である蓄積時期と、当該取引明細が示す取引対象の口座と、当該蓄積時期および当該口座ごとに取引明細をカウントしたレコード数の各情報を抽出して前記第1テーブルを構成し、
    前記階層型データベースにおける、前記蓄積テーブルにて規定した格納位置に格納された各取引明細を、取引対象の口座および蓄積時期に対応付けたレコードを生成および蓄積して前記第2テーブルを構成する処理を更に実行する、
    ことを特徴とする請求項4に記載の取引明細管理方法。
JP2016052868A 2016-03-16 2016-03-16 取引明細管理システムおよび取引明細管理方法 Pending JP2017167843A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016052868A JP2017167843A (ja) 2016-03-16 2016-03-16 取引明細管理システムおよび取引明細管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016052868A JP2017167843A (ja) 2016-03-16 2016-03-16 取引明細管理システムおよび取引明細管理方法

Publications (1)

Publication Number Publication Date
JP2017167843A true JP2017167843A (ja) 2017-09-21

Family

ID=59913479

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016052868A Pending JP2017167843A (ja) 2016-03-16 2016-03-16 取引明細管理システムおよび取引明細管理方法

Country Status (1)

Country Link
JP (1) JP2017167843A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109241067A (zh) * 2018-08-21 2019-01-18 中国平安人寿保险股份有限公司 交易数据管理方法及装置
CN110442572A (zh) * 2019-06-28 2019-11-12 阿里巴巴集团控股有限公司 用户特征值的确定方法及装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109241067A (zh) * 2018-08-21 2019-01-18 中国平安人寿保险股份有限公司 交易数据管理方法及装置
CN109241067B (zh) * 2018-08-21 2023-08-22 中国平安人寿保险股份有限公司 交易数据管理方法及装置
CN110442572A (zh) * 2019-06-28 2019-11-12 阿里巴巴集团控股有限公司 用户特征值的确定方法及装置
CN110442572B (zh) * 2019-06-28 2024-02-02 创新先进技术有限公司 用户特征值的确定方法及装置

Similar Documents

Publication Publication Date Title
JP6744854B2 (ja) データ記憶方法、データ照会方法、およびそれらの装置
CN103748579B (zh) 在映射化简框架中处理数据
CN103733195B (zh) 管理用于基于范围的搜索的数据的存储
CN108292315B (zh) 储存和检索数据立方体中的数据
CN101553813B (zh) 管理可单独访问的数据单元的存储器
CN103177061B (zh) 分区表中的唯一值估计
US10540375B2 (en) Systems and methods for self-pairing databases
EP2608074A2 (en) Systems and methods for merging source records in accordance with survivorship rules
CN111767303A (zh) 一种数据查询方法、装置、服务器及可读存储介质
CN105144080A (zh) 用于元数据管理的系统
CN108647357B (zh) 数据查询的方法及装置
CN101405728A (zh) 具有动态加载能力的关系数据库架构
US20120124110A1 (en) Database, management server, and management program
JP6242540B1 (ja) データ変換システム及びデータ変換方法
CN102208061A (zh) 数据核销处理装置和数据核销处理方法
CN105824892A (zh) 一种数据池对数据同步和处理的方法
CN105359172A (zh) 计算企业存在拖欠的概率
JP2017167843A (ja) 取引明細管理システムおよび取引明細管理方法
EP1196867A1 (en) A method and an apparatus for the processing of queries to a database
CN114021005A (zh) 网点信息查询方法、装置、设备及存储介质
CN111125045B (zh) 一种轻量级etl处理平台
CN100465946C (zh) 数据编译方法
CN114860819A (zh) 商业智能系统的构建方法、装置、设备和存储介质
CN106776704A (zh) 统计信息收集方法和装置
CN112258151A (zh) 一种基于pandas的对账方法、装置、计算机设备和存储介质