特許 6432893 データベース処理装置、グループマップファイル生産方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6432893

(24)【登録日】2018年11月16日

(45)【発行日】2018年12月5日

(54)【発明の名称】データベース処理装置、グループマップファイル生産方法及びプログラム

(51)【国際特許分類】

   G06F 17/30 20060101AFI20181126BHJP

【ＦＩ】

   G06F17/30 220Z

   G06F17/30 414Z

【請求項の数】6

【全頁数】13

(21)【出願番号】特願2017-194559(P2017-194559)

(22)【出願日】2017年10月4日

【審査請求日】2018年5月21日

【早期審査対象出願】

(73)【特許権者】

【識別番号】516132563

【氏名又は名称】株式会社シマント

(74)【代理人】

【識別番号】100136180

【弁理士】

【氏名又は名称】羽立 章二

(72)【発明者】

【氏名】渡邉 繁樹

【審査官】 早川 学

(56)【参考文献】

【文献】 特開２０１０−１２２８８０（ＪＰ，Ａ）

【文献】 特開２００８−２６２３２４（ＪＰ，Ａ）

【文献】 特開２０１２−１０８６３５（ＪＰ，Ａ）

【文献】 鵜木昌行，Ｓｙｂａｓｅ ＩＱ「独自データ構造による、データウエアハウスへのアプローチ」，電子情報通信学会技術研究報告，社団法人電子情報通信学会 The Institute of Electronics,Information and Communication Engineers，１９９７年１２月 ２日，Ｖｏｌ．９７，Ｎｏ．４１５，ｐｐ．５１〜５６

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

データベースに対して処理を行うデータベース処理装置であって、
前記データベースに対して集計処理を行うときに、前記データベースにおける名寄せ対象となった複数の値のそれぞれの位置に対応させて、前記名寄せ対象となった値を数値化した数値を格納したグループマップファイルを作成するグループマップ作成手段を備えるデータベース処理装置。

【請求項2】

前記データベースの各データは、ＣＳＶファイルに格納されており、
前記集計処理を行うときに又は前記集計処理を行う前に、前記ＣＳＶファイルの各データにアクセスするためのアドレスマップファイルを作成するアドレスマップ作成手段を備える請求項１記載のデータベース処理装置。

【請求項3】

前記集計処理による集計結果の内訳を抽出する集計結果内訳抽出手段と、第１記憶部と、第２記憶部を備え、
前記第１記憶部は、前記第２記憶部よりも高速にアクセスすることが可能であり、
前記第２記憶部は、前記ＣＳＶファイルを記憶し、
前記アドレスマップファイルは、前記第２記憶部に記憶された前記ＣＳＶファイルの各データにアクセスするためのものであり、
前記集計結果内訳抽出手段は、前記第２記憶部とは異なる前記第１記憶部に読み出された前記グループマップファイル及び前記アドレスマップファイルを用いて、
前記グループマップファイルにおける一つ又は複数の数値をサーチして、当該一つ又は複数の数値に対応する前記データベースの位置を特定し、
前記アドレスマップファイルを使用して、当該位置に対応する前記ＣＳＶファイルの各データを抽出する、請求項２記載のデータベース処理装置。

【請求項4】

前記データベースを管理するためのデータ構造を記憶する記憶手段を備え、
前記データ構造は、フィールド定義情報を格納するフィールド定義格納部と、データを格納するデータ格納部を含み、
前記データ格納部は、前記データベースを特定するデータを格納するデータベース格納部と、前記グループマップファイルを記憶するマップ格納部を備え、
前記フィールド定義情報により前記データベースにおいて仮想フィールド定義を実現する、請求項１から３のいずれかに記載のデータベース処理装置。

【請求項5】

データベースを用いてグループマップファイルを生産するグループマップファイル生産方法であって、
データベース処理装置が備えるグループマップ作成手段が、前記データベースに対して集計処理を行うときに、前記データベースにおける名寄せ対象となった複数の値のそれぞれの位置に対応させて、前記名寄せ対象となった値を数値化した数値を格納したグループマップファイルを生産するグループマップ作成ステップを含むグループマップファイル生産方法。

【請求項6】

コンピュータを、データベースに対して集計処理を行うときに、前記データベースにおける名寄せ対象となった複数の値のそれぞれの位置に対応させて、前記名寄せ対象となった値を数値化した数値を格納したグループマップファイルを作成するグループマップ作成手段として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本願発明は、データベース処理装置、グループマップファイル生産方法及びプログラムに関し、特に、データベースに対して処理を行うデータベース処理装置等に関する。

【背景技術】

【0002】

ビル・インモン（William H. Inmon）により、データウェアハウス（Data WareHouse）等の概念が提唱されている（非特許文献１参照）。従来、データローディングは、具体的には、例えば以下のように行われていた。

【0003】

まず、ＥＴＬツールにより、ＣＳＶファイルからＣＳＶ源データをシーケンシャルに読み出し、フィールド選択、行選択、データ浄化、正規化、ローダー用書式化などを行い、抽出されたＣＳＶ源部分データをファイルにシーケンシャルに書き込む。ここで、ＣＳＶ源データを保存するファイルと、ＣＳＶ源部分データを管理するファイルとは、等しくない。

【0004】

そして、ＲＤＢＭＳローダーにより、ＣＳＶ源データから特定ＲＤＢＭＳローダー用ＣＳＶデータを作成し、特定ＲＤＢＭＳローダー用ＣＳＶデータをシーケンシャルに読み出して、フィールド選択、データ浄化、正規化、データ型変換、キーの整合性チェックなどを行い、ＲＤＢＭＳテーブルレコードデータをファイルにシーケンシャルに書き込む。

【先行技術文献】

【非特許文献】

【0005】

【非特許文献1】Ｗ．Ｈ．インモン，コーポレート・インフォメーション・ファクトリー−企業情報生態系の構築と管理，海文堂出版，１９９９年

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、従来のデータローディングは、ＣＳＶ源データから、設計時に必要とされた部分のみを抽出して行われる。抽出されていないものは、検索等の処理ができない。そのため、抽出されていないＣＳＶ源データに対して検索等の処理を行うためには、全体を見直し、一部又は全部を作り直し、ローディングをやり直してテーブル構成の再設計等を行う必要があった。そのため、容易に変更することはできず、最初から完璧な設計をする必要があった。また、検索結果をデータウェアハウス化して蓄積することは、検索結果が正規形である保障がないために、基本的には指定することが許されていなかった。

【0007】

さらに、これらの処理はバッチ処理により実現されるが、ＣＳＶ源データが例えば何十ＧＢもある場合には、ＲＤＢＭＳテーブルレコードデータにアクセスできるまでに長時間を要していた。また、ＲＤＢＭＳテーブルレコードデータは、一般にデータ量が極めて大きく、例えば汎用のノートパソコンのような性能の低いコンピュータでは、数ＧＢ程度のメモリに記憶させて処理を行うことができず、ハードディスクなどに格納されて必要に応じて部分的にメモリに読み出して処理を行っていた。そのため、検索等の処理に、長い時間が必要となった。

【0008】

そこで、本願発明は、ＣＳＶ源データなどの生データのデータベースに対して、事前に抽出等の処理を行わずに集計検索処理等を行うことに適したデータベース処理装置等を提案することを目的とする。

【課題を解決するための手段】

【0009】

本願発明の第１の観点は、データベースに対して処理を行うデータベース処理装置であって、前記データベースに対して集計処理を行うときに、名寄せ対象となった値を数値化したグループマップファイルを作成するグループマップ作成手段を備える。

【0010】

本願発明の第２の観点は、第１の観点のデータベース処理装置であって、前記データベースの各データは、ＣＳＶファイルに格納されており、前記集計処理を行うときに又は前記集計処理を行う前に、前記ＣＳＶファイルの各データにアクセスするためのアドレスマップファイルを作成するアドレスマップ作成手段を備える。

【0011】

本願発明の第３の観点は、第２の観点のデータベース処理装置であって、前記集計処理による集計結果の内訳を抽出する集計結果内訳抽出手段と、第１記憶部と、第２記憶部を備え、前記第１記憶部は、前記第２記憶部よりも高速にアクセスすることが可能であり、前記第２記憶部は、前記ＣＳＶファイルを記憶し、前記アドレスマップファイルは、前記第２記憶部に記憶された前記ＣＳＶファイルの各データにアクセスするためのものであり、前記集計結果内訳抽出手段は、前記第２記憶部とは異なる前記第１記憶部が記憶する前記グループマップファイル及び前記アドレスマップファイルを用いて、前記グループマップファイルにおける一つ又は複数の数値をサーチして、当該一つ又は複数の数値に対応する前記データベースの位置を特定し、前記アドレスマップファイルを使用して、当該位置に対応する前記ＣＳＶファイルの各データを抽出する。

【0012】

本願発明の第４の観点は、第１から第３のいずれかの観点のデータベース処理装置であって、前記データベースを管理するためのデータ構造を記憶する記憶手段を備え、前記データ構造は、フィールド定義情報を格納するフィールド定義格納部と、データを格納するデータ格納部を含み、前記データ格納部は、前記データベースを特定するデータを格納するデータベース格納部と、前記グループマップファイルを記憶するマップ格納部を備え、前記フィールド定義情報により前記データベースにおいて仮想フィールド定義を実現する。

【0013】

本願発明の第５の観点は、データベースを用いてグループマップファイルを生産するグループマップファイル生産方法であって、データベース処理装置が備えるグループマップ作成手段が、前記データベースに対して集計処理を行うときに、名寄せ対象となった値を数値化したグループマップファイルを生産するグループマップ作成ステップを含む。

【0014】

本願発明の第６の観点は、コンピュータを、データベースに対して集計処理を行うときに、名寄せ対象となった値を数値化したグループマップファイルを作成するグループマップ作成手段として機能させるためのプログラムである。

【0015】

なお、本願発明を、第６の観点のプログラムを記録するコンピュータ読み取り可能な記録媒体として捉えてもよい。

【0016】

また、本願発明において、集計処理において、ハッシュ関数を用いて、ソートを行わないで動的にマージするものとして捉えてもよい。集計処理においては一般にデータ読込みの後に名寄せのためにソート・マージ処理を行う必要がある。本願発明によれば、ハッシュ関数を利用することにより、ソートを行わないで動的にマージすることを採用して、さらなる性能の向上を成し遂げることができる。

【0017】

また、本願発明を、第４の観点に記載のデータ構造、及び、このデータ構造を記録するコンピュータ読み取り可能な記録媒体としてとらえてもよい。さらに、第４の観点に記載のデータ構造において、前記データ格納部は、前記データベースの行に対応したレコードを保持するテーブルを記録するテーブル格納部を備え、前記レコードに対して実フィールドを追加及び更新することにより、前記データベースの実フィールドの値の追加及び更新を行うものとして捉えてもよい。例えば、ＣＳＶファイルの５行目に対応するＤＢレコードのＩＤ（ＲＤＢＭＳにおけるプライマリーキー）＝５とするテーブルにより実現することができる。これにより、データベースの各データを特定するＣＳＶファイル等を変更せずに、実フィールドの追加及び更新をすることができる。

【発明の効果】

【0018】

本願発明の各観点によれば、オリジナルのデータベースに対して集計処理等を行い、このとき、グループマップファイルを作成することにより、集計結果を容易に特定することができる。

【0019】

さらに、本願発明の第２の観点によれば、アドレスマップファイルを利用して、データベースを特定するＣＳＶファイルの各データにアクセスすることが可能になる。

【0020】

さらに、グループマップファイル及びアドレスマップファイルは、固定長バイナリファイルで実現することができる。そのため、本願発明の第３の観点にあるように、ＣＳＶファイルよりもきわめて小さなサイズとなり、オンメモリで高速処理することができる。さらに、グループマップファイルにより集計結果を得、アドレスマップファイルによりデータベースの各データにアクセスすることにより、集計結果の内訳（データベースにおけるデータ）を高速に得ることができる。

【0021】

さらに、本願発明の第４の観点にあるように、マルチバリューシステムなどにおいて実現可能なデータ構造を利用することができる。

【図面の簡単な説明】

【0022】

【図1】（ａ）本願発明の実施の形態に係るデータベース処理装置１の構成の一例を示すブロック図と、（ｂ）第２記憶部１５が記憶するＣＦＩＬＥ２３のデータ構造の一例を示すブロック図である。

【図2】図１のデータベース処理装置１の動作の一例を示すフロー図である。

【図3】ＣＳＶファイル４３と、これにより生成されるグループマップファイル４９の一例を示す。

【図4】ＣＳＶファイルとマスターファイルを利用してグループマップファイルを生成する処理の一例を示す。

【図5】図１のデータベース処理装置１におけるデータアクセスの一例を示す図である。

【発明を実施するための形態】

【0023】

以下では、図面を参照して、本願発明の実施例について説明する。なお、本願発明は、この実施例に限定されるものではない。

【実施例】

【0024】

図１は、（ａ）本願発明の実施の形態に係るデータベース処理装置１の構成の一例を示すブロック図と、（ｂ）第２記憶部１５が記憶するＣＦＩＬＥ２３のデータ構造の一例を示すブロック図である。図２は、図１のデータベース処理装置１の動作の一例を示すフロー図である。

【0025】

図１（ａ）を参照して、データベース処理装置１は、グループマップ作成部３（本願請求項の「グループマップ作成手段」の一例）と、アドレスマップ作成部５（本願請求項の「アドレスマップ作成手段」の一例）と、集計結果内訳抽出部７（本願請求項の「集計結果内訳抽出手段」の一例）と、制御部９と、テーブル管理部１１と、第１記憶部１３（本願請求項の「第１記憶部」の一例）と、第２記憶部１５（本願請求項の「第２記憶部」の一例）と、入力部１９と、表示部２１を備える。

【0026】

第３記憶部２４は、ＣＳＶ源データファイル２５を記憶する。第３記憶部２４が記憶するＣＳＶ源データファイル２５は、生データを管理するＣＳＶファイルである。簡単のために、ＣＳＶ源データファイル２５が一つの場合について説明する。ＣＳＶ源データファイル２５が複数あっても、同様に実現することができる。

【0027】

従来、ＣＳＶ源データファイルから必要な部分のみを抽出して、ＲＤＢＭＳテーブルレコードデータを作成していた。従来のＲＤＢＭＳテーブルレコードデータは、ＣＳＶ源データファイルに比較して大幅にデータ量が増加し、かつ、新たに必要な部分が発生した場合には再設計が必要となっていた。

【0028】

第１記憶部１３は、第２記憶部１５と比較して高速にアクセスすることができる。例えば、第１記憶部１３はメモリであり、第２記憶部１５はハードディスク等であり、一般的なノートパソコンであれば、第２記憶部１５には数百ＧＢの情報を、第１記憶部１３に数ＧＢの情報を記憶させることができる。第１記憶部１３に記憶された情報には、第２記憶部１５に記憶された情報と比較して、高速にアクセスすることができる。

【0029】

マルチバリューシステムにおける１テーブルは、ＯＳ上において２種のディレクトリ（フィールド定義を格納するＤＩＣＴ部とデータを格納するＤＡＴＡ部）によって構成され、一般にＤＩＣＴ部ひとつに対しＤＡＴＡ部ひとつが対応する構成であるが、必要であれば一つのＤＩＣＴ部に複数のＤＡＴＡ部ディレクトリを対応させることができる。

【0030】

第２記憶部１５は、ＣＦＩＬＥ２３を記憶する。図１（ｂ）を参照して、ＣＦＩＬＥ２３は、フィールド定義情報を格納するフィールド定義格納部３３（マルチバリューシステムにおけるＤＩＣＴ部を参照）と、データを格納するデータ格納部３５（マルチバリューシステムにおけるＤＡＴＡ部を参照）を備える。データ格納部３５は、テーブル格納部３７と、データベース格納部３９と、マップ格納部４１を備える。フィールド定義格納部３３、データ格納部３５、テーブル格納部３７、データベース格納部３９及びマップ格納部４１は、ディレクトリ（フォルダ）である。この構造は、管理テーブルＶＯＣに記録される。ここで、管理テーブルＶＯＣは、マルチバリューシステムにおいて全テーブルの構成情報を管理しているシステムテーブルであり（ＭＤと称するものもある。）、ＣＦＩＬＥ同様にフィールド定義格納部とデータ格納部からなり、データ格納部において全テーブルの構成情報が保持される。なお、必要であれば、ＣＦＩＬＥにおいてデータ格納部を追加し、一つのＣＦＩＬＥ内に複数のデータ格納部があってもよい。

【0031】

データベース格納部３９は、ＣＳＶファイル４３と、部分ＣＳＶファイル４５を格納する。

【0032】

利用者が入力部１９を操作してＣＦＩＬＥ２３を生成するときに、ＣＳＶ源データファイル２５をコピー又は移動させてＣＳＶファイル４３とする。なお、必要であれば、行スキップ、ＦＴＦ８へコード変換、半角全角変換などを行ったり、複合キー用ＣＳＶを生成したりしてもよい。ＣＳＶファイル４３は、ＣＳＶ源データファイル２５と完全に（又は実質的に）等しい。そのため、従来は必要とされていなかったが事後的に必要とされたデータも、ＣＦＩＬＥ２３内に存在しており、再設計をする必要はない。

【0033】

部分ＣＳＶファイル４５は、例えばＣＳＶファイル４３の１行が多くのフィールドを有する場合などに、特定フィールドにおいて高速検索を可能にするため、ＣＳＶファイル４３から、特定フィールド（特定フィールドの複数結合指定をすることもできる。つまり、部分ＣＳＶファイル４３の行を任意指定の複数種のフィールドにて構成させることもできる。）のみを抜き取ったものである。これにより、ＲＤＢＭＳにおけるカラム型ＤＢＭＳのような効果を発揮する。利用者が入力部１９を操作してマップ生成命令を実行することにより、事後的に一つ又は複数を生成することができる。例えば、ＣＳＶファイル４３のファイル名を「Ｃ」とすると、ＣＳＶファイル４３の１７番フィールドと５番フィールドで構成される部分ＣＳＶファイル４５のファイル名は「Ｃ１７＿５」とする。

【0034】

マップ格納部４１は、アドレスマップファイル４７と、グループマップファイル４９と、部分アドレスマップファイル５１を格納する。

【0035】

アドレスマップファイル４７は、第２記憶部１５に記憶されたＣＳＶファイル４３にアクセスするためのアドレスを管理する。アドレスマップファイル４７は、ＣＳＶファイル４３に対応する固定長バイナリファイルであり。アドレスマップファイル４７は、例えば、全件数、２行目始りアドレス、３行目始りアドレス、…、最終行始りアドレス、及び、最終行終りアドレス＋１、を記憶する。なお、アドレスマップファイル４７は、ＣＦＩＬＥ２３の生成時に生成してもよく、また、ＣＦＩＬＥ２３の生成時には生成せずに集計検索処理を行うときに生成してもよい。事後的に生成しても、アドレスマップファイル４７を生成するために余計にかかる時間は、それをやらなかった場合の検索時間と比較して測定可能な程度の差が生じない。

【0036】

グループマップファイル４９は、利用者が入力部１９を操作してＣＳＶファイル４３に対する集計検索命令を実行するときに、必要に応じて登録される。構造は、全行において集計処理における名寄せで決定された「名」を１から始まる検索時発見順の整数値に置き換えたバイナリ固定長ファイルである。

【0037】

データ量を比較すると、グループマップファイル４９のそれぞれのサイズは、アドレスマップファイル４７のサイズよりも小さい。例えば、ＣＳＶファイル４３が２０００万件（約３３ＧＢ）の場合、アドレスマップファイル４７のサイズは９６．５ＭＢ、グループマップファイル４９のサイズが５８ＭＢ弱であった。そのため、常時オンメモリにおける高速アクセスが可能となる（すなわち、第１記憶部１３に格納した状態で高速にアクセスして処理をすることができる。）。そのため、非力なＰＣであっても、超高速な処理が可能になる。

【0038】

部分アドレスマップファイル５１は、部分ＣＳＶファイル４５のそれぞれに対応して、第２記憶部１５に記憶された部分ＣＳＶファイル４５にアクセスするためのアドレスを管理する。部分ＣＳＶファイル４５と部分アドレスマップファイル５１の関係は、ＣＳＶファイル４３とアドレスマップファイル４７の関係と同様である。部分ＣＳＶファイル４５に対応した部分アドレスマップファイル５１は、検索結果（表示用）として部分ＣＳＶファイル４５内フィールドが相当した場合に、そのデータを高速に抽出できるようにするためのものである。（部分アドレスマップファイル５１がなくとも、大元のアドレスマップファイル４７を用いて大本のＣＳＶファイル４３から抽出は可能である。）なお、部分ＣＳＶファイル４５に対応するグループマップファイルは、仮に作成しても、ＣＳＶファイル４３のグループマップファイル４９と同等同サイズのものとなるために、大元のＣＳＶファイル４３のグループマップファイル４９で対応可能である。

【0039】

テーブル格納部３７は、ＣＳＶファイル４３の行に対応したレコード（ＲＤＢＭＳにおいてプライマリーキーに相当する＠ＩＤのみを持つ空レコード）を、ＣＳＶファイル４３の行数分保持する。テーブル管理部１１は、テーブル格納部３７に対する処理を行う。例えば、ＣＳＶファイル４３が７行で構成されていた場合、＠ＩＤ＝１から７までの７レコードが生成格納される。この空レコードへは、任意に実フィールドをいくらでも追加及び更新することができる。そのため、ＣＳＶファイル４３を変化させることなく、見かけ上（しかし実用的に）ＣＳＶファイル４３の更新が可能となる。具体的には、データベース格納部３９とマップ格納部４１は、共に、ＣＳＶファイル４３のデータ及び行番号に関連して生成されている。テーブル格納部３７は、ＣＳＶファイル４３の行番号をＩＤとしてもったレコードを保持し、ＣＳＶファイル４３の行番号にのみ関連する。レコードの追加及び更新は、ＣＳＶファイル４３の行に対応したテーブル格納部３７内レコードに、新規フィールドを追加したり更新したりする（「行」の追加は基本的にしない）。そのため、テーブル格納部３７の中でのみ起こり、データベース格納部３９及びマップ格納部４１には影響しない。グループマップファイル４９は、そのときの検索結果として保持されており更新されるべきものではない。新規検索には、新規のグループマップファイルが対応するため、新規グループマップファイルが「追加」されることはあっても、以前のグループマップファイルは変更されない。

【0040】

フィールド定義格納部３３は、フィールド定義情報を格納する。フィールド定義情報により、データベースにおける仮想フィールド定義をすることができる。例えば、ＣＳＶファイル４３及びテーブル格納部３７のテーブルは実フィールドの値を定義するが、仮想フィールド定義に従って例えば集計値などの値を計算することにより、仮想フィールドの各値を得ることができる。

【0041】

図２を参照して、図１のデータベース処理装置１において、ＣＳＶファイル４３に対する集計検索処理により、アドレスマップファイル４７及びグループマップファイル４９を生成する処理の一例を説明する。なお、アドレスマップファイル４７がＣＦＩＬＥ生成時や以前の集計検索処理により生成されているのであれば、アドレスマップファイル４７を生成せずに、グループマップファイル４９を生成する処理を行えばよい。

【0042】

制御部９は、前処理として、変数kを０とし、メモリ上に空の参照リストを設定する（ステップＳＴ１）。

【0043】

制御部９は、ＣＳＶファイル４３からフィールドを読み出し（ステップＳＴ２）、ＣＳＶファイル４３に一意に対応するアドレスマップファイル４７が未だ生成されていない場合に限り、空のアドレスマップファイル４７を生成し、次に示すようなアドレス書込み処理を行う。アドレスマップ作成部５は、ｎ行（ｎは２以上の整数）の始まりのフィールドであるならば、アドレスマップファイル４７に対してｎ行始りアドレスを追加する。また、最終行の終わりであるならば、最終行終りアドレス＋１を格納する（ステップＳＴ３）。なお、最初から完成されたアドレスマップファイル４７が存在している場合は、フィールドの読み出し（ステップＳＴ２）を行うのみであり、ステップＳＴ３は実行されない。

【0044】

グループマップ作成部３は、読み出されたフィールドが名寄せ対象フィールドか否かを判断する（ステップＳＴ４）。名寄せ対象フィールドであれば、ステップＳＴ５に進む。名寄せ対象フィールドでないならば、ステップＳＴ９に進む。

【0045】

ステップＳＴ５及びＳＴ６において、フィールドが新たな値であるか否かを判断する。新たな値であるならば、kを1増加したうえで新たな値に対応するＩＤをｋとし（ステップＳＴ７）、グループマップファイル４９（存在しない場合には生成する。）にＩＤを追加し（ステップＳＴ８）、ステップＳＴ９に進む。フィールドが新たな値でないならば、グループマップファイル４９に対応するＩＤを追加する。

【0046】

ステップＳＴ９において、制御部９は、全てのフィールドに対して処理が行われたか否かを判断する。行われていないフィールドがあるのであれば、ハッシュ化された参照リストへIDを書込み(ステップＳＴ１０)、ステップＳＴ２に戻って処理が行われていないフィールドに対して処理を行う。全てのフィールドに対して処理が行われたのであれば、制御部９は、テーブル格納部３７が空である場合に限り、行番号をIDとした空のレコード（ダミーレコード）を行数分追加して終了する。

【0047】

図３は、ＣＳＶファイル４３と、これにより生成されるグループマップファイル４９の一例を示す図である。ＣＳＶファイル４３の２列目が名寄せ対象フィールドである場合、ＣＳＶファイル４３の２列目は、ｂ、ａ、ａ、ｃ、ｂ、ｅ、ｄである。これに対応するグループマップファイル４９は、出現順に番号化してＩＤを生成したものであり、１、２、２、３、１、４、５である。また、４列目が名寄せ対象フィールドである場合には、ＣＳＶファイル４３の４列目は、Ｚ、Ｂ、Ｙ、Ａ、Ａ、Ｚ、Ｙであり、これに対応するグループマップファイル４９は、１、２、３、４、４、１、３である。異なる集計処理では、異なるグループマップファイル４９が生成される。

【0048】

グループマップファイル４９は、単純に単フィールドの値だけでなく、複数フィールドの合成値や、それらをキーとしてマスターテーブルとのＪＯＩＮ等によって得られる値とすることも可能である。図４を参照して、マスターテーブルを使用したグループマップファイルの生成処理の一例を説明する。検索対象となるＣＳＶファイルは、流通業におけるトランザクションデータであり、どの商品がどれだけ売れたかが記録されている。検索は、部門別に集計処理を行い、そのグループマップファイルを生成することである。ただし、ＣＳＶファイル４３内にデータとして部門コードが入っておらず、商品コードしかない。マスターテーブルは、マルチバリューシステムにおけるテーブルであり、基本機能は、ＲＤＢＭＳにおける正規化されたレコード構造を持つテーブルと同等である。システム上に、商品マスターテーブルがあり、商品コードと部門コードが対応付けられている。図４の例では、ＣＳＶファイルの第２列が商品コードであり、ｂ、ａ、ａ、ｃ、ｂ、ｅ、ｄである。商品マスターテーブルでは、商品コードａ、ｂ、ｃ、ｄ、ｅは、それぞれ、Ｚ、Ｙ、Ｙ、Ｘ、Ｚと対応付けられている。検索処理では、商品コードをキーとして商品マスターテーブルとＪＯＩＮし、部門コードを検索時に動的に生成して、あたかもＣＳＶファイルに部門コードが存在しているかのごとくに名寄せ集計を行う。これにより、ＣＳＶファイルにはない、部門コードによりグループマップファイルを生成することができる。ここで実現されるＪＯＩＮは、ＳＱＬ等のＪＯＩＮ（ＳＱＬ上にてキーとフィールド間の関係手続きとしてその都度記述され実行される。）とは異なる仕組みであり、例えば「部門コード」という「仮想フィールド」をフィールド定義格納部３３に定義しておけば、それを実体（エンティティー）として扱うことができるため、簡素かつ汎用的なものである。

【0049】

集計結果内訳抽出部７は、第２記憶部１５からＣＦＩＬＥ２３のグループマップファイル４９及びアドレスマップファイル４７を読み出して第１記憶部１３に記憶させ、第１記憶部１３が記憶するグループマップファイル４９及びアドレスマップファイル４７を利用して、集計結果の内訳（ＣＳＶファイル４３のデータ＝ＲＡＷデータ）を高速に読み込み、表示部２１に表示する。例えば、図３の例で、利用者が入力部１９を操作して２列目の「ａ」と「ｅ」に相当する集計結果の内訳を表示するように指示した場合、グループマップファイル４９における２及び４をシーケンシャルサーチすることによりＣＳＶファイル４３における相当行番号（図３の場合２、３、６）を獲得し、これを、アドレスマップファイル４７を使用してＣＳＶファイル４３からＲＡＷデータをダイレクトレコードアクセスして、表示部２１に表示する。

【0050】

例えば、ＣＳＶファイル４３が約３３ＧＢ、２０００万件であった場合に、３種のフィールドへ検索条件及び３種のフィールドにソート指定をした場合、本願発明によれば、非力なノートパソコンを使用しても、ＣＳＶ源ファイルを用意してから検索完了するまで平均３分であった。背景技術は、ＤＢＭＳテーブルとしてのレコードデータ生成にかかるコスト等がかかり、さらに、本願発明と比較して検索性能が劣る。そのため、「日」レベル、さらには「週」レベルの時間が必要である。検索性能の違いは、ＲＤＢＭＳテーブルを検索する場合には実体としてのレコード又はインデックス（この場合、物理構造としてはB-TREE）を読むが、内部処理として、ポインターを辿りレコード単位で読み込む必要がある。これらは、例えインデックス化されていたとしても媒体（ハードディスク）上では特にデータ量が多い場合には物理的に大きく分散されて書込まれている。よって、大量データ時には読込み時のディスク側キャッシュが利き辛くなり、一般にキャッシュが利いているときと比較し全体として100倍以上遅くなる。本願発明では、集計結果を求める等の検索において物理的に大きく分散配置されていない単一ファイルであるＣＳＶファイル４３そのものを頭から順に連続読込みを行うことにより、キャッシュ効率を最大にまで上げている（これによりノートパソコンに標準搭載されている2.5インチハードディスク（＝一般サーバー上の3.5インチハードディスクに比較しアクセス性能は落ちる）のような遅い媒体においても高速性能を発揮できる）。加えて、一般にデータ読込みの後に名寄せのためにソート・マージ処理を行う必要があるが、本実験では、集計処理において、ハッシュ関数を用いてソートを行わないで動的にマージしている（図２のステップＳＴ５参照）。

【0051】

図５は、図１のデータベース処理装置１におけるデータアクセスの一例を示す図である。

【0052】

図５（ａ）を参照して、利用者Ａは、ＣＦＩＬＥに対してdirect read/writeにより、検索で可能なことを行うことができる。例えば、一般の３ＧＬであるＪＡＶＡ（登録商標）やＣ＋＋や．ＮＥＴに対応したプログラム言語用に用意された関数群、４ＧＬに相当する検索言語ＩＱＬ、ＯＬＡＰであるＩＱＬＬなどにより処理を行うことができる。また、ＣＦＩＬＥを用いることにより、ＲＡＷデータに、テーブル格納部３７のダミーレコードを利用して任意の行に実フィールドを関連付けて追加等したり、フィールド定義格納部３３により仮想フィールド定義をしたりすることができる。

【0053】

ＣＦＩＬＥに対して、ＪＯＩＮ、ＤＲＩＬＬ ＴＨＲＯＵＧＨ等を行うことにより、ＤＢＭＳテーブルレコードデータを得ることができる。また、ＣＦＩＬＥに対して、名寄せ、統計・集計処理、フィールド選択、データ浄化、正規化／マルチバリュー化、データ型定義、キーの動的整合性チェックを行い、direct writeにより、ＤＢＭＳテーブルレコードデータを得ることができる。このＤＢＭＳテーブルレコードデータは、集計データのように扱うことができる。利用者Ｂは、ＤＢＭＳテーブルレコードデータを利用して処理を行うことができる。

【0054】

図５（ｂ）を参照して、自由度の高いデータローディングが実現できることについて説明する。ＣＳＶ源データに対して、名寄せ等を行うことにより、direct writeによりＤＢＭＳテーブルレコードデータを得ることができる。例えば、約２０００万行のデータ（約３３ＧＢ）から、最短７分〜２０分で同時３種の集計処理（結果行だけで数千行〜数百万行）をノートＰＣ上にて完了することができた。また、結果をＣＳＶデータとして書き出すこともできる。

【符号の説明】

【0055】

１ データベース処理装置、３ グループマップ作成部、５ アドレスマップ作成部、７ 集計結果内訳抽出部、９ 制御部、１１ テーブル管理部、１３ 第１記憶部、１５ 第２記憶部、１９ 入力部、２１ 表示部、２３ ＣＦＩＬＥ、２４ 第３記憶部、２５ ＣＳＶ源データファイル、３３ フィールド定義格納部、３５ データ格納部、３７ テーブル格納部、３９ データベース格納部、４１ マップ格納部、４３ ＣＳＶファイル、４５ 部分ＣＳＶファイル、４７ アドレスマップファイル、４９ グループマップファイル、５１ 部分アドレスマップファイル

【要約】

【課題】 ＣＳＶ源データなどの生データのデータベースに対して、事前に抽出等の処理を行わずに、集計検索処理等を行うことに適したデータベース処理装置等を提案する。
【解決手段】 データベース処理装置１において、データベースに対して集計処理を行うときに名寄せ対象となった値を数値化したグループマップファイル４７と、第２記憶部１５のＣＳＶファイル４３の各データにアクセスするためのアドレスマップファイル４７を管理する。集計結果内訳抽出部７は、グループマップファイル４９を利用して集計結果に対応するＣＳＶファイル４３のデータを特定し、アドレスマップファイル４７を利用してＣＳＶファイル４３のデータにアクセスして、表示部２１に集計結果の内訳を表示する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】