JPH11161710A - 時系列データの格納方法及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 少数属性のデータの参照処理を高速化し、必
要記憶容量が削減できる時系列データ格納方法及び記録
媒体を提供すること。 【解決手段】 多くの対称について複数の属性について
定期的に測定することによって選られる大規摸な時系列
データを、索引ファイル１０２と属性別にデータを格納
する属性ファイル１０３に格納する。索引ファイル１０
２は、すべての属性についての測定データが既定値であ
るか否かを示すビットマップ１０７と属性ファイル上で
対応するデータの格納位置を保持する。各属性ファイル
１０３には、対称ごとに測定されたデータを時刻順に所
定長で格納する。ただし、すべての属性についての測定
データが既定値である場合には、属性ファイル１０３へ
のデータの格納は行わない。以上により、少数属性のデ
ータの参照処理を高速化し、必要記憶容量が削減でき
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，時系列データをラ
ンダムアクセス可能な記憶装置に格納する方法及び記録
媒体に関する。

【０００２】

【従来の技術】大規模時系列データの代表的なものとし
ては、小売業におけるＰＯＳ日次データがある。

【０００３】小売業におけるＰＯＳの日次データは、あ
る店舗Ｓで、ある商品Ｐが、ある日に売れた個数，およ
び、その金額、粗利，商品の値下販売による損失、廃棄
による損失、在庫量、仕入れ価格等の記録であり、会計
処理に利用される他、品揃えを見直したり、仕入れ数量
を決定する業務に利用される。この日次データの特徴は
大規模なことである。大規摸スーパーマーケットの場
合、店舗数は１０００、１店舗で取り扱う商品は１０万
種類、データを保存する日数は４００日（１年強）程度
である。ただし、１店舗が取り扱う１０万種類の商品の
うち、１日に売れる商品の種類は２万（全体の２割）程
度である。

【０００４】このように大規模な時系列データをランダ
ムアクセス可能な二次記憶装置に格納する従来の方法
を、図１２に基づいて説明する。ある店舗Ｓで商品Ｐが
ある日に売れたり、廃棄による損失が発生するなどした
場合、図１２に示すようなレコードが関係データベース
内の日次情報リレーションに追加される。ひとつのレコ
ードを構成するのは約２０個程度のフィールドであり、
そのうち、「年月日」、「店舗コード」、「商品コー
ド」の組はリレーションの主キーである。商品コード
は、例えばＪＡＮコードと呼ばれる１０進１３桁のコー
ド、店舗コードはそのスーパーマーケットで適当に定め
た各店舗の識別コードで、１０進３〜４桁程度の数値で
ある。

【０００５】このように、各レコードに、「年月日」、
「店舗コード」、「商品コード」を付すことにより、販
売や廃棄などが全く発生しなかった場合には、レコード
を作成する必要がなく、すべての日についてレコードを
作成する場合と比較して、格納に必要な記憶容量を大幅
に削減できる。その他のフィールドには、販売数量、販
売金額、廃棄数量、粗利などの項目のデータが格納され
る。これらの項目は、値がゼロであることも多いので、
関係データベースに格納する場合、それぞれの項目を可
変長で保持することが多い。その結果、平均のレコード
長は１００バイト程度となる。従って、大規模スーパー
マーケットの場合、日次情報リレーションの大きさは、
１０００店舗×２万種類×４００日×１００バイト＝８
０００億バイト（＝８００ＧＢ）程度となる。なお先進
的なスーパーマーケットでは、日次データに代えて、１
日をさらにいくつかの時間帯に区切つてデータを格納す
ることにより、各店舖での時問帯ごとの作業計画に利用
しようとする動きもあり、格納されるＰＯＳデータは、
今後さらに大規模化すると予想される。

【０００６】このＰＯＳ情報リレーションに対する典型
的な演算は、「年月日」、「店舗コード」、「商品コー
ド」の全部もしくは一部を条件とする制約演算と、図１
３に示すような「商品コード」とその商品に関する種々
の情報を格納する「商品情報リレーション」との結合演
算である。このような演算では、ひとつのレコード内に
含まれるすべてデータを二次記憶装置からメインメモリ
に転送することになる。 一般にＰＯＳの日次データを
使って種々の分析を行う場合、上記レコードに含まれる
すべての項目を参照することは希である。例えば、ＰＯ
Ｓデータを使って各商品の販売数量を予測する場合、そ
の商品の単価や販売数量等のデータを参照するが、損失
に関するデータ等を参照する必要はない。その代わり、
その店舖でその商品の単価や販売数量等のデータを、デ
ータベースに格納されている全期間に渡って参照する必
要がある。

【０００７】しかるに、関係データベースを使用した従
来の日次データの格納方法では、ある対称（この場合、
店舗と商品の組合せ）に関して測定された各属性のデー
タがひとつのレコードとして格納されているため、参照
する必要のない属性のデータもメインメモリ上にロード
せざるを得ず、これが全体の処理時間を増大させてい
る。

【０００８】関係データベースを使うという範囲内でこ
の不具合を解決しようとするものとして、図１４に示す
ように、ひとつのレコードを複数のレコードに分割して
格納する方法がある。しかし、この方法では、「年月
日」、「店舗コード」、「商品コード」を分割したそれ
ぞれのレコードに含める必要がある他、分割したレコー
ドのそれぞれに含まれる項目を参照する場合には、いわ
ゆる結合演算を行う必要があり、性能劣化の危険性があ
る。このような事情で、図１４に示すように複数のレコ
ードに分割して格納するようなことは、実際には行われ
ない。

【０００９】なお、上記のような問題点は、ＰＯＳデー
タに限ったことでなく、例えば、道路網の交通量を幹線
道路から生活道路まで含めて、毎分ごとに調べることに
よって得られる時系列データにも共通することである。
この場合、対称は交通量を測定する地点、項目として
は、子供／成人／老人に区分した歩行者がある方向に通
過した数と車種別に区分した車がある方向に通過した数
である。このような測定を、１分単位で２４時間行うと
時間方向に１４４０個の要素からなる時系列データが得
られる。そして、夜間の生活道路のように交通量が全く
ない場合、ＰＯＳデータの場合のある店舗である商品が
全く売れなかった日に相当する。

【００１０】

【発明が解決しようとする課題】このように、大規模な
時系列データをランダムアクセス可能な二次記憶装置に
格納する従来の方法においては、参照する必要のない項
目のデータもメインメモリ上にロードせざるを得ず、こ
れが全体の処理時間を増大させるという問題点があっ
た。またひとつのレコードを複数のレコードに分割して
格納する方法によっては、分割したレコードのそれぞれ
に含まれる項目を参照する場合には、いわゆる結合演算
を行う必要があり、性能劣化を生じるという問題点があ
った。このような問題点は、大規模な時系列データの複
数項目を同時にメモリ上にロードせざるを得ないデータ
構造が原因であると考えられる。

【００１１】本発明は上記の従来技術の問題を解決する
ためになされたもので、大規模時系列データを関係デー
タベースに格納する従来の方法と比べて、少数の属性の
データを参照する処理を高速化するようなデータ格納方
法を提供することを目的とする。

【００１２】本発明の別の目的は、従来の方法と比較し
て、必要な記憶容量を削減できるデータ格納方法を提供
することにある。

【００１３】本発明のまた別の目的は、少数の属性のデ
ータ参照処理の高速化、必要な記憶容量の削減を可能に
するデータ構造によるデータを記憶した記憶媒体を提供
することにある。

【００１４】

【課題を解決するための手段】かかる課題を解決するた
め、請求項１及び２記載の本発明は、ある時間における
複数の属性ごとのデータを持ち得る複数の対象について
の該属性ごとに経時的に得られるデータを記憶装置上に
格納するため、前記複数の対象の１の属性について経時
的に得られるデータを時間順に所定長で、同一の対象の
同一の時間についてのデータが相互に対応するように格
納する属性ファイルを前記複数の属性ごとに設け、前記
対象を特定する情報と、該対象の前記属性ファイルでの
位置を示す情報と、該対象のある時刻の全ての属性に対
するデータが既定値であるか否かを表す識別情報（例え
ば、１ビットのビットマップ）とを対応させて格納する
索引ファイルを設け、前記識別情報が特定値である場合
にのみ前記属性ファイルにデータを格納することを特徴
とする。

【００１５】請求項１または２記載の本発明では、各対
称に関して期間にわたって測定データを分析する場合、
多数の属性のうち一部の属性に関する測定データを参照
する場合に、属性ごとの測定データをひとつの属性ファ
イルに格納し、しかも、測定データの格納順序は、ひと
つの対称に関する測定時刻順であるため、測定データを
二次記憶装置から主記憶装置にロードする処理が高速化
される。また、識別情報を設けることにより、ある対称
に関して時刻に測定された各属性のデータがすべて既定
値の時、測定データを格納する必要がないため、そのよ
うな状況が頻繁に発生する時系列データについては、そ
の格納に必要な記憶容量を削減できる。また、各属性フ
ァイル内に測定データを所定長で格納することにより、
索引情報はすべての属性ファイルで共通化できるため、
索引情報を記憶するための領域を小さくできる。

【００１６】請求項３及び４記載の本発明は、ある時間
における複数の属性ごとのデータを持ち得る複数の対象
についての該属性ごとに経時的に得られたデータを記憶
装置上に格納するため、前記複数の対象の１の属性につ
いて経時的に得られるデータを時間順に所定長で格納す
るための領域を予め割り当てた属性ファイルを前記複数
の属性ごとに設け、前記対象を特定する情報と、該対象
の前記属性ファイルでの位置を示す情報と、該対象のあ
る時刻の全ての属性に対するデータが既定値であるか否
かを表す識別情報とを対応させて格納する索引ファイル
を設け、ある対象についてある時間に新しいデータが得
られたとき、前記識別情報を更新し、前記識別情報が特
定値である場合にのみ前記割り当てられた領域に該得ら
れたデータを格納することを特徴とする。

【００１７】請求項３または４記載の本発明では、ある
対象についてある時間に新しいデータが得られたとき、
識別情報を更新し、識別情報が特定値である場合にのみ
予め割り当てられた領域に得られたデータを循環的に格
納するので、新しい測定データを追加し、最も古い側定
データを削除する処理を高速化できる。

【００１８】請求項５及び６記載の本発明は、請求項１
乃至４のうち１項に記載の時系列データの格納方法また
は記録媒体であって、前記属性ファイルにデータを所定
長で格納する際のデータ幅の決定方法は、該属性ファイ
ルに格納すべきデータの値範囲を調べ、それらを表現可
能な大きさをデータ幅とすることを特徴とする。

【００１９】請求項５または６記載の本発明では、属性
ファイルにデータを所定長で格納する際のデータ幅は、
属性ファイルに格納すべきデータの値範囲を調べ、それ
らを表現可能な大きさをデータ幅ととするので、属性フ
ァイルの大きさを実際のデータの値範囲に対応した、必
要最小限の大きさとすることができる。

【００２０】請求項７及び８記載の本発明は、請求項１
乃至４のうち１項に記載の時系列データの格納方法また
は記録媒体であって、前記属性ファイルにデータを所定
長で格納する際のデータ幅の決定方法は、該属性ファイ
ルに格納すべきすべてのデータの値の分布を調べ、大多
数のデータを表現できる大きさとし、該データ幅で表現
できないデータについては、前記領域には表現不能デー
タであることを示す値を格納し、該表現不能データを該
格納位置を検索キーとして、別領域に格納することを特
徴とする。

【００２１】請求項７または８記載の本発明では、属性
ファイルにデータを所定長で格納する際のデータ幅は、
属性ファイルに格納すべきすべてのデータの値の分布を
調べ、大多数のデータを表現できる大きさとし、該デー
タ幅で表現できないデータについては、本来のデータ領
域には表現不能データであることを示す値を格納し、表
現不能データを格納位置を検索キーとして、別領域に格
納するので、測定データ中に大きな値のデータが少数存
在する場合に、属性ファイルの大きさを小さくすること
ができる。

【００２２】請求項９及び１０記載の本発明は、請求項
７または８記載の時系列データの格納方法または記録媒
体であって、少なくともひとつの前記属性ファイルにつ
いては、現時刻のデータを格納する代わりに、前時刻の
データとの差を格納し、データを所定長で格納するため
の前記領域にデータが治まらないときは別領域にデータ
を格納することを特徴とする。

【００２３】請求項９または１０記載の本発明では、現
時刻のデータを格納する代わりに、前時刻のデータとの
差を格納し、データを所定長で格納するための前記領域
にデータが治まらないときは別領域にデータを格納す
る。ほとんど値の変化がない属性については、前時刻の
測定データとの差を格納するようにすれば、そのほとん
どは値がゼロとなり、所定長でデータを格納する際に変
化があった時のみ別領域に格納できるため、属性ファイ
ルの大きさを大幅に小さくすることができる。

【００２４】請求項１１及び１２記載の本発明は、請求
項１乃至１０のうちいずれか１項に記載の時系列データ
の格納方法または記録媒体であって、前記属性ファイル
のうち、一定期間参照されていない属性ファイルをデー
タ圧縮しておき、データ圧縮された属性ファイルが参照
されるとき、復元することを特徴とする。

【００２５】請求項１１または１２記載の本発明では、
最近参照されない属性ファイルをデータ圧縮することに
より、性能をあまり低下させることなく、格納に必要な
記憶容量をさらに削減できる。

【００２６】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態を説明する。

【００２７】（第一の実施形態）本発明の第一の実施の
形態について説明する。

【００２８】図１は、図１２に対応するＰＯＳの日次デ
ータをＮ日分格納するためのランダムアクセス可能な二
次記憶装置上でのデータ構造を表わしている。ここで、
日次データが格納されている期問中の日を、第１日〜第
Ｎ日と呼ぶことにする。

【００２９】図１に示すように、日次データ１０１全体
は、ひとつの索引ファイル１０２と複数の属性ファイル
１０３で表現される。索引ファイル１０２は、商品コー
ド１０４、店舗コード１０５、オフセット１０６及びビ
ットマップ１０７の４個の要素からなる所定長のレコー
ドで構成されるファイルである。

【００３０】商品コード１０４と店舗コード１０５は、
図１２に示す従来の格納方法と同じコードを使用する。
オフセット１０６は、属性ファイル１０３中の対応する
（商品コード１０４、店舗コード１０５）に対応するデ
ータの格納位置を保持する。ビットマップ１０７は、Ｎ
ビットで構成されるデータ構造であり、第ｋ番目のビッ
トが０であれば、第ｋ日の販売がないことを示す。

【００３１】ある（商品コード１０４、店舗コード１０
５）の組が与えられた時、あるいは、商品コード１０４
だけを与えられた時、上記索引ファイル１０２上の該当
するレコードを高速に検索する必要がある。そのために
は、索引ファイル１０２を構成する上記レコードは、
（商品コード１０４、店舗コード１０５）の組をキーと
して、昇順になるよう並べておく。あるいは、商品コー
ド１０４に対するハッシュ関数を使用してレコードの格
納位置を決めても良い。これらについては、広く知られ
ているので詳細な説明を省略する。

【００３２】次に属性ファイル１０３について説明す
る。属性ファイル１０３は、図１２のリレーションに含
まれる属性のうち、商品コード１０４、店舗コード１０
５、年月日を除く各属性に対して、ひとつずつ設けられ
る。各属性ファイル１０３には、対応する属性の値を、
（商品コード１０４、店舗コード１０５）が同じものに
ついて、第１日から第Ｎ日まで年月日順に格納する。た
だし、第ｋ日目のデータに関して、ビットマップ１０７
の対応するビット（第ｋビット）が０であれば、属性フ
ァイル１０３にはデータを格納しない。このデータの格
納順は、すべての属性ファイル１０３で共通とする。ま
た、個々のデータは所定長で格納する。

【００３３】この結果、ある（商品コード１０４、店舗
コード１０５、年月日）の組が与えられた時、各属性フ
ァイル１０３内の対応するデータの格納位置は、（各属
性ファイル１０３ごとに設定された所定長×データの要
素位置）で求めることができる。ただし、「データの要
素位置」とは、属性ファイル１０３上で該当するデータ
が最初から数えて何番目かを示す。このデータの要素位
置を求めるには、索引ファイル１０２内の各レコードに
設けたオフセット１０６とビットマップ１０７が使用さ
れる。オフセット１０６は、対応する（商品コード１０
４、店舗コード１０５）に対応する最初のデータの要素
位置を示す。第ｋ日目のデータの要素位置は、上記オフ
セット１０６に対応するビットマップ１０７の第１ビッ
ト〜第（ｋ−１）ビットまでの１の数を加えたもので求
めることができる。

【００３４】データを格納する際のビット長と表現形式
は、数値データの場合には、個々の属性が取り得る最大
の値を表現できるように、例えば、販売金額を３２ビッ
トの固定小数点としても良いが、属性ファイル１０３の
大きさをより削減するため、属性ファイル１０３に格納
する全データの最大値および最小値を調べ、それらを表
現可能な範囲で最小のビット幅（あるいは、バイト幅）
とすることもできる。また、非数値データの場合には、
もっとも大きなバイト数を要するデータのサイズとす
る。

【００３５】次に、ある（商品コード１０４、店舗コー
ド１０５、年月日）が与えられたとき（ステップＳ２０
１）、販売数量を求める手順を図２を用いて説明する。

【００３６】まず、索引ファイル１０２および対応する
属性ファイル（例えば１０３ａ）がオープンされていな
ければオープンする（ステップＳ２０２〜ステップＳ２
０５）。次に、与えられた商品コード１０４および店舗
コード１０５に対応する索引ファイル１０２内のレコー
ドＲを検索する（ステップＳ２０６）。先に説明したよ
うに、（商品コード１０４、店舗コード１０５）をキー
として昇順に並んでいれば、２分探索法を用いることが
できる。また、ハッシュ法を用いることもできる。 こ
の検索の結果、レコードＲが見つからなければ（ステッ
プＳ２０７のＮＯ）、もともとデータベース中にその商
品コード１０４と店舗コード１０５の組合せのレコード
は存在しないことを示すので、「該当するデータは存在
しない」ということで検索が終了する。この原因として
は、商品コード１０４か店舗コード１０５に誤りがある
か、あるいは、その店舗でその商品は取り扱っていない
という結果となる。レコードＲが存在する場合、与えら
れた年月日を第１日目〜第Ｎ日目のいずれに当たるか変
換する。ここでは、第ｋ日目であるとする。

【００３７】次にレコードＲの第ｋビットを参照し、も
し、その値が０であれば、「該当するデータは存在しな
い」ということになる。この場合、「その店舗でその商
品は、与えられた年月日には販売や廃棄が一切なかっ
た」ことを示すので、結果は「販売数量＝０と」なる。

【００３８】第ｋビットが１であれば、レコードＲのオ
フセットとレコードＲの第１ビット〜第（ｋ−１）ビッ
トまでの値を合計したものを加えることにより、属性フ
ァイル１０３ａ上の対応するデータが属性ファイル１０
３ａの何番目に存在するか求めることができる。その値
にその属性ファイル１０３ａでのデータのビット長（バ
イト長）を乗じた位置からデータを読み出すことによ
り、販売数量を求めることが出来る。

【００３９】なお、上記実施例では、図１２のリレーシ
ョンに含まれる属性のうち、商品コード１０４、店舖コ
ード１０５、年月日を除く各属性に対して、ひとつずつ
設けられるとしたが、例えば、販売数量と販売金額のよ
うに同時に参照される頻度の高い複数の属性をまとめて
ひとつの属性ファイル１０３に対応させることもでき
る。その場合、属性ファイル１０３中には、（販売数
量、販売金額）の組を格納すれば良い。

【００４０】（第１の実施形態の変形）第１の実施形態
では、属性ファイル１０３にデータを所定長で格納する
際のビット長（バイト長）は、それが数値データの場合
には、格納しようとするデータの最大値および最小値を
表現可能な最小のビット数（バイト数）とし、非数値デ
ータの場合には、最も大きなバイト数を要するデータの
サイズとするとした。

【００４１】しかし、この方法では、あるデータだけが
例外的に大きな値をとるような場合、ほとんどのデータ
に対しては不必要に大きなビット数（バイト数）を割り
当てることになり、記憶領域に大きな無駄を生ずる危険
性がある。これを回避する方法を示す。

【００４２】第１ステップとして、格納すべき個々のデ
ータが何ビット（何バイト）で表現できるかヒストグラ
ムを作成する。具体的に言えば、最低限Ｗビット（Ｗバ
イト）あれば表現できるデータの個数を数えるためのカ
ウンタを必要数（例えば、３２個）だけ用意する。そし
て、それらの初期値としてゼロを与える。そして、属性
ファイル１０３に格納すべき各データについて、それを
表現可能な最小限のビット数（バイト数）に対応するカ
ウンタをインクリメントする。例えば、データを２の補
数で表現する場合、データが１２７であれば、それを表
現するのに最低限必要なビット数は８（バイト数は１）
であるので、８ビット（１バイト）に対応するカウンタ
をインクリメントする。非数値データについても同様の
方法でデータを表現するのに最低限必要なビット数（バ
イト数）を求めれば良い。

【００４３】第２ステップとして、上記カウンタの値を
参照することにより、例えば、９９％以上のデータを表
現できるビット数（バイト数）を求める。例えば、デー
タの個数が全部で１０億個であり、第１ステップの結
果、各カウンタの値が図３のとおりであったとする。
（ただし、説明に関係のないカウンタの値は、・・・・・・・・
で表わしている。）この場合、大きなビット長に対応す
るカウンタから値の累計をとり、全データの個数１０億
の１％にあたる１０００万を超える直前、図３の場合に
はそれが１６ビット用カウンタであるので、すべてのデ
ータは１６ビットで表現すると決める。

【００４４】第３ステップでは、各属性ファイル１０３
ヘデータを実際に格納する。この際、全体の１％程度の
データは、与えられた所定長の領域では表現できないの
で、それらのデータに対する特別の取扱いが必要にな
る。そのようなデータに対しては、まず、そのデータを
格納するための領域、上記の例では１６ビットの領域
に、オーバーフローしているので本当の値は別領域に格
納されていることを示す特別な値を格納する。例えば、
全ビットが１であるような値をこの用途にのみ使用する
ことにする。そして、例えば属性ファイル１０３の本来
のデータを格納するための領域の後に、オーバーフロー
した値を格納する。このとき、そのデータの本来の格納
位置をキーとして、オーバーフローした値が高速に検索
できるよう、例えば、ハッシュ法を使用するのが良い。

【００４５】図４に、本実施形態における二次記憶装置
上のデータ構造を、図５にデータの参照方法を示す。第
１の実施形態とほぼ同一であるが、データを参照する
時、その値がオーバーフローを示すか否かを検査し（ス
テップＳ５１２）、オーバーフローを示す場合（ステッ
プＳ５１２のＹＥＳ）には、オーバーフロー領域の中か
ら、（レコードＲのオフセット＋第１ビット〜第（ｋ−
１）ビットの合計）をキーに、本当のデータを獲得する
処理（ステップＳ５１３）が追加されている。このオー
バーフローか否かの判定に要する時間は全体の処理時間
と比較して無視できる程度の大きさである。このように
データ分布を調べて、ある大きさ以上のデータを別扱い
とすることにより、基本的にはデータを所定長で保持す
る方式でありながら、データを可変長で保持するのと余
り変わらない程度までデータ格納に必要な記憶容量を減
らすことができる。さらに、日次データを関係データベ
ースに格納する従来の方式では、各レコードごとに商品
コード１０４、店舗コード１０５、年月日が必要であっ
たが、本発明では、各レコードに対して必要なのは、ビ
ットマップ１０７の１ビットであり、商品コード１０４
と店舗コード１０５の組は、索引ファイル１０２に１回
出現するだけである。そのため、従来の方法とファイル
構造全体で必要な記憶容量を比較すると、本実施形態の
方がより少ない記憶容量で済むという結果を得ている。

【００４６】時系列データの中には、例えば仕入先業者
コードのように、ある商品コードとある店舗コードの組
について、値はゼロではないが、時刻によってほとんど
変化しない属性があり得る。その場合、対応する属性フ
ァイル１０３には、値そのものではなく、前時刻の値と
の差分を格納することにし、先に述べた第１の実施形態
の変形を適用すれば、その属性ファイル１０３の大きさ
を大幅に削減できる。例えば、データを所定長で格納す
る際のビット幅を１ビットとすれば、値の変化がほとん
ど無い場合には、その属性ファイル１０３の大きさは全
体の大きさと比較して、ほとんど無視できる。

【００４７】（第２の実施形態）第１の実施形態では、
暗黙のうちにデータの追加や削除はないという前提に基
づいていた。本実施形態では、データの新規追加および
期限切れデータの削除を行う場合について説明する。

【００４８】まず、索引ファイル１０２´および属性フ
ァイル１０３の構造を図６に基づいて説明する。

【００４９】索引ファイル１０２´を構成する各レコー
ドは、第１の実施形態と比較して、最新データ位置６０
０というフィールドが追加されている。また、属性ファ
イル１０３にデータが所定長で格納されるという点でも
第１の実施形態と同じである。 ただし、第１実施形態
では、属性ファイル１０３内には測定されたデータが隙
間なく詰め込む方法を示したが、データの新規追加およ
び期限切れデータの削除を行う場合には、この点を改善
する必要がある。いま、Ｎ日分のデータを格納するデー
タベースにおいて、データを蓄積し始めてから第Ｘ日目
（Ｘ＞Ｎとする）のデータを新規に追加し、第（Ｘ−
Ｎ）日目のデータを削除する場合を考える。 新規に追
加しようとする測定データが、すべての属性について既
定値であれば、属性ファイル１０３に追加する必要はな
い。また、もし第（Ｘ−Ｎ）日目のデータが属性ファイ
ル１０３中に存在すれば、その領域を、追加されるデー
タ格納用に再利用できる。厄介なのは、新規に追加する
データが、少なくともいずれかの属性が既定値でなく、
かつ、第（Ｘ−Ｎ）日目のデータが既定値であったた
め、属性ファイル１０３上に新規にデータを格納する領
域を確保できない場合である。 第２の実施形態では、
商品コード１０４と店舗コード１０５の組に対して属性
ファイル１０３上の領域を割当てる際、実際に格納しな
ければならないデータの個数にある一定の余裕をみて、
領域を割り当てる。例えば、実際に格納しなければなら
ないデータの個数がＮに近い場合には、Ｎ個のデータ格
納用エントリを割り当て、実際に格納しなければならな
いデータの個数が０に近い場合には、（Ｎ／１０）個程
度のデータ格納用エントリを割り当てる。商品コード１
０４と店舗コード１０５の組に対するデータ格納用エン
トリの割り当ては、各属性ファイル１０３で同じになる
ように行う。

【００５０】索引ファイル１０２´内のレコードの「オ
フセット」は、このように割り当てた領域の先頭位置を
指す。また、次のレコードの「オフセット」との差は、
その商品コード１０４と店舗コード１０５の組に割り当
てられたデータ格納用エントリの個数を表わす。

【００５１】最新データ位置６００は、属性ファイル１
０３内で最新のデータが格納されているエントリを示
す。ただし、最新のデータとは、第（Ｘ−１）日目以前
で少なくともある属性の値が既定値でなかった最後の日
のデータである。

【００５２】次に、ある商品コード１０４と店舖コード
１０５の組に対して、データを新規に追加する手順を図
７に基づいて説明する。

【００５３】まず、追加するデータを受け取る（ステッ
プＳ７０１）。次に、索引ファイル１０２´および属性
ファイル１０３が更新モードでオープンされていなけれ
ば、更新モードでオープンする（ステップＳ７０２〜ス
テップＳ７０５）。

【００５４】次に索引ファイル１０２´の中から、与え
られた商品コード１０４と店舗コード１０５に対応する
レコードを検索する（ステップＳ７０６）。もし、対応
するレコードが見つからない場合（ステップＳ７０７の
ＮＯ）、新しい店舖の開店、新商品の登場、ある店舗で
のある商品の取り扱い開始などの可能性があり、いずれ
にしても索引ファイル１０２´上に新たなレコードを追
加し、また、属性ファイル１０３上にデータ格納用の領
域を確保する（ステップＳ７０８）。そして、再度ステ
ップＳ７０６から処理を再開する。

【００５５】対応するレコードＲが見つかった場合（ス
テップＳ７０７のＹＥＳ）、与えられた年月日を第ｋ日
目に変換する。ただし、本実施形態では、Ｎ日分の時系
列データを格納するため、ｋをＮで割り算した余り（ｋ
ｍｏｄ Ｎ）を求める（ステップＳ７０９）。

【００５６】次に、レコードＲのビットマップの第ｋビ
ットを調べる。もし、０であれば（ステップＳ７１０の
ＮＯ）、削除すべきＮ日前のデータは属性ファイル１０
３に格納されていないことを示すので、レコードＲのビ
ットマップ１０７´の全ビットの値を合計した結果Ｌ
と、この領域に割り当てられたエントリ数Ｅを求める
（ステップＳ７１１）。ただし、ＥはレコードＲと次の
レコードＲ＋１のオフセットの差分で求めることができ
る。

【００５７】もし、Ｌ＝Ｅであれば（ステップＳ７１２
のＹＥＳ）、今回のデータ追加をそのまま行うと、Ｎ日
経っていないデータに上書きしてしまうことになるた
め、領域の拡張を行う（ステップＳ７１５）。この領域
の拡張は、隣接する領域に余裕がある場合には、そこか
らエントリを少し奪うことによって実現するのが実行速
度の点で望ましい。

【００５８】そして、レコードＲのビットマップ１０７
´の第ｋ番目のビットを１に変え（ステップＳ７１
４）、レコードＲの最新データ位置を次のエントリを指
すよう更新し、その位置にデータを書き込む（ステップ
Ｓ７１５）。ただし、最新データ位置が、既にその領域
用に割り当てられた最後のエントリを指しているのを更
新する場合、最初のエントリ、すなわちレコードＲのオ
フセット１０６´に戻し、その領域を循環的に使用す
る。

【００５９】また、レコードＲのビットマップの第ｋビ
ットが１である場合には、ステップＳ７１５だけを実行
すれば良い。

【００６０】以上が第２の実施形態におけるデータの追
加・削除方法である。図８は本実施形態におけるデータ
の参照方法を示すフローチャートである。第１の実施形
態の場合とほぼ同一であるが、与えられた年月日を第ｋ
日目に当たるとして変換するとともに、今日を第Ｎ日目
に当たるとして変換し（ステップＳ８０９）、第ｋビッ
トが１であれば、レコードＲのオフセット１０７´とレ
コードＲの第（ｋ＋１）１ビット〜第Ｎビットまでの値
を合計したものを加えることにより、属性ファイル１０
３ａ上の対応するデータが属性ファイル１０３ａの何番
目に存在するか求め（ステップＳ８１０）、その値にそ
の属性ファイル１０３ａでのデータのビット長（バイト
長）を乗じた位置からデータを読み出す（ステップＳ８
１１）点が異なっている。

【００６１】次に具体例に基づいて説明する。図９は、
索引ファイルの一部１０２´とひとつの属性ファイルの
一部１０３ａ´を示している。この例では、格納できる
データを８日分としている。索引ファイル１０２´の最
初のレコードは、商品コード（１０４ａ）Ｘ、店舗コー
ド（１０５ａ）αに対応し、属性ファイル１０３ａ´上
に割り当てられた領域は、ＬからＬ＋４までであること
がわかる。また、ビットマップ１０７の大きさは８日分
に対応して８ビットである。今日は、データを格納して
から第２０日目であるとすると、ビットマップ１０７ａ
の第４（２０ｍｏｄ ８）ビット（ここでは、左端から
数えて５番目とする）が今日に対応する。第４ビットの
値は１であり、また、最新データ位置は０であるので、
属性ファイル１０３ａ´のＬの領域に今日のデータが格
納されていることがわかる。また、昨日に関しては、ビ
ットマップ１０７ａの第３ビット（左端から数えて４番
め）は０であるので、データがなかったことを表してい
る。また、一昨日に関しては、ビットマップ１０７ａの
第２ビット（左端から数えて３番目）は１であるので、
最新データ位置の直前（先に述べたように、Ｌ〜Ｌ＋４
は循環的に使用されるため、Ｌ＋４）にデータがあるこ
とを表している。

【００６２】（第３の実施形態）本実施形態では、第２
実施形態と比較して、商品コード１０４と店舗コード１
０５の組が非常に多い場合に、高い性能を期待できる索
引ファイルの構成法を図１０に示す。本実施形態では、
第２の実施形態で説明した索引ファイル１０２を、第１
索引ファイル１０２ａと第２索引ファイル１０２ｂに分
割して保持する。また、図９には陽に示していないが、
第２実施形態では商品コードとして１３桁のＪＡＮコー
ドをそのまま使用していたが、本実施形態では１３桁の
ＪＡＮコードをハッシングにより、よりコンパクトなコ
ード（例えば、最大Ｎ種類の商品を扱う小売業者であれ
ば、０〜Ｎ＋αの数値）に変換したものを使用する。そ
して、商品の追加が行なわれた場合、上記変換後のコー
ドとして、（これまでに存在する最も大きなコード＋
１）を割当てる。これにより、索引ファイル１０２と属
性ファイル１０３の全面的な再構成を回避できる。

【００６３】第１索引ファイル１０２ａは、（店コード
１０５ａ、商品ビットマップ１０７Ｘ、オフセット１０
６Ｘ）の３つ組からなる所定長のレコードである。ある
店コード１０５ａのレコードを高速に検索するために、
店コード１０５ａで昇順に並べる。商品ビットマップ１
０７Ｘは、その店舖がある商品を扱っているか否かを上
記変換後の商品コードのビット位置の１／０で表現した
ものである。オフセット１０６Ｘは、その店コード１０
５ａに対応する第２索引ファイル１０２ｂ上での開始位
置を保持している。この第１索引ファイル１０２ａは十
分小さく、主記憶装置に常駐させておくことが可能であ
る。

【００６４】第２索引ファイル１０２ｂは、（オフセッ
ト１０６、最新データ位置６００、ビットマップ１０
７）の３個の要素で構成される所定長のレコードの集合
である。それぞれの要素は第２の実施形態と同じ働きを
するので説明を割愛する。この第２索引ファイル１０２
ｂは、相当大きく、データ検索の際は該当部分をファイ
ルから主記憶装置に読み出した後、プロセッサで処理さ
れる。

【００６５】図１１は、第３の実施形態におけるデータ
の参照方法を示したフローチャートである。第１の実施
形態の場合と異なるのは、索引ファイルを２つオープン
している（ステップＳ１１０４〜ステップＳ１１０７）
点、商品コードの通し番号への変換を行っている（ステ
ップＳ１１０８〜ステップＳ１１０９）点、ビットマッ
プのビットの合計・属性ファイル中からの読み込みをそ
れぞれ２つの索引ファイルについて行っている（ステッ
プＳ１１１１〜ステップＳ１１１８）点である。個々の
ステップ中の処理については第１の実施形態の場合と同
様であるので、ここでは説明を省略する。

【００６６】以上説明したように、本発明の時系列デー
タ格納法は、時系列データを関係データベースに格納す
る従来の方法と比較して、データ分析などで行われる典
型的なデータ参照の速度を１桁程度向上できる。これ
は、参照すべき属性のデータのみを保持する属性ファイ
ルを設け、さらに、データを所定長で格納することによ
り実現される。

【００６７】また、データ格納に要する記憶容量につい
ても、本発明は従来の方法より勝っている場合がある。
これは、大部分のデータを表現可能なビット幅に格納
し、それで収まりきらないデータは特別に処理するこ
と、および、従来の格納法では必須であったリレーショ
ンのキー情報に相当する情報をほとんど持つ必要がない
ことにより実現されている。

【００６８】２５０万レコードのデータについて本発明
を実際に適用した結果、データ参照速度は従来技術によ
る場合に比べて約１０倍高速になった。また、必要な記
憶容量は２倍以上有効に利用することができるようにな
った。このように、本発明は、データ検索等の処理の速
度を向上させ、また、データの記憶容量の軽減を可能と
し、利便性の向上、ハード資源の節約に著しく寄与す
る。この効果は、精密データに基づく精密な販売予測な
どのために処理すべきデータ量がますます大量化する現
在にあっては特に大なるものである。

【００６９】

【発明の効果】請求項１または２記載の本発明では、各
対称である期間にわたって測定データを分析する場合、
多数の属性のうち一部の属性に関する測定データを参照
する場合に、属性ごとの測定データをひとつの属性ファ
イルに格納し、しかも、測定データの格納順序は、ひと
つの対称に関する測定時刻順であるため、測定データを
二次記憶装置から主記憶装置にロードする処理が高速化
される。また、識別情報を設けることにより、ある対称
に関して時刻に測定された各属性のデータがすべて既定
値の時、測定データを格納する必要がないため、そのよ
うな状況が頻繁に発生する時系列データについては、そ
の格納に必要な記憶容量を削減できる。また、各属性フ
ァイル内に測定データを所定長で格納することにより、
索引情報はすべての属性ファイルで共通化できるため、
索引情報を記憶するための領域を小さくできる。

【００７０】請求項３または４記載の本発明では、ある
対象についてある時間に新しいデータが得られたとき、
識別商法を更新し、識別情報が既定値でない場合に予め
割り当てられた領域に得られたデータを格納するので、
新しい測定データを追加し、最も古い側定データを削除
する処理を高速化できる。

【００７１】請求項５または６記載の本発明では、属性
ファイルにデータを所定長で格納する際のデータ幅は、
属性ファイルに格納すべきすべてのデータの値範囲を調
べ、それらを表現可能な大きさをデータ幅とするので、
属性ファイルの大きさを実際のデータの値範囲に対応し
た、必要最小限の大きさとすることができる。

【００７２】請求項７及び８記載の本発明では、属性フ
ァイルにデータを所定長で格納する際のデータ幅は、属
性ファイルに格納すべきすべてのデータの値の分布を調
べ、大多数のデータを表現できる大きさとし、その大き
さでは表現できないデータについては、本来のデータ領
域には表現不能データであることを示す値を格納し、表
現不能データを格納位置を検索キーとして、検索可能な
別領域に格納するので、測定データ中に大きな値のデー
タが少数存在する場合に、属性ファイルの大きさを小さ
くすることができる。

【００７３】請求項９または１０記載の本発明では、現
時刻のデータを格納する代わりに、前時刻のデータとの
差を格納し、データを所定長で格納するための前記領域
にデータが治まらないときは別領域にデータを格納す
る。ほとんど値の変化がない属性については、前時刻の
測定データとの差を格納するようにすれば、そのほとん
どは値がゼロとなり、所定長でデータを格納する際に変
化があった時のみそれを検索可能な別領域に格納できる
ため、属性ファイルの大きさを大幅に小さくすることが
できる。

【００７４】請求項１１または１２記載の本発明では、
最近参照されない属性ファイルをデータ圧縮することに
より、性能をあまり低下させることなく、格納に必要な
記憶容量をさらに削減できる。

【００７５】従って本発明によれば、参照すべき属性の
データのみを保持する属性ファイルを設け、さらに、デ
ータを所定長で格納することにより、時系列データを関
係データベースに格納する従来の方法と比較して、デー
タ分析などで行われる典型的なデータ参照の速度を１桁
程度向上できる。

【００７６】また、大部分のデータを表現可能なビット
幅に格納し、それで収まりきらないデータは特別に処理
すること、および、従来の格納法では必須であったリレ
ーションのキー情報に相当する情報をほとんど持つ必要
がないことにより、本発明のデータ格納に要する記憶容
量についても、従来の方法より勝っている場合が生ずる
効果がある。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るＰＯＳの時系列デー
タのデータ構造を示した図、

【図２】本発明の一実施形態に係るデータの参照方法を
示すフローチャート、

【図３】本発明の一実施形態に係るデータの分布を示し
た図、

【図４】本発明の一実施形態に係るＰＯＳの時系列デー
タのデータ構造を示した図、

【図５】本発明の一実施形態に係るデータの参照方法を
示すフローチャート、

【図６】本発明の一実施形態に係るＰＯＳの時系列デー
タのデータ構造を示した図、

【図７】本発明の一実施形態に係るデータの削除・追加
方法を示すフローチャート、

【図８】本発明の一実施形態に係るデータの参照方法を
示すフローチャート、

【図９】本発明の一実施形態に係る索引ファイルと属性
ファイルの図、

【図１０】本発明の一実施形態に係る索引ファイルと属
性ファイルの構成を示す図、

【図１１】本発明の一実施形態に係るデータの参照方法
を示すフローチャート、

【図１２】従来のＰＯＳ日次データの格納方法を示す
図、

【図１３】従来の商品情報リレーションの図、

【図１４】従来のＰＯＳ日次データをリレーション分割
して格納する図である。

【符号の説明】

１０１…ＰＯＳ日次データ １０２…索引ファイル １０３…属性ファイル １０４…商品コード １０５…店舗コード １０６…オフセット １０７…ビットマップ ４０１…オーバーフローしたデータ格納用領域 ６００…最新データ位置格納領域

Claims (12)

【特許請求の範囲】
1. 【請求項１】 ある時間における複数の属性ごとのデー
   タを持ち得る複数の対象についての該属性ごとに経時的
   に得られるデータを記憶装置上に格納するため、 前記複数の対象の１の属性について経時的に得られるデ
   ータを時間順に所定長で、同一の対象の同一の時間につ
   いてのデータが相互に対応するように格納する属性ファ
   イルを前記複数の属性ごとに設け、 前記対象を特定する情報と、該対象の前記属性ファイル
   での位置を示す情報と、該対象のある時刻の全ての属性
   に対するデータが既定値であるか否かを表す識別情報と
   を対応させて格納する索引ファイルを設け、 前記識別情報が既定値でない場合に前記属性ファイルに
   データを格納することを特徴とする時系列データの格納
   方法。
2. 【請求項２】 ある時間における複数の属性ごとのデー
   タを持ち得る複数の対象についての該属性ごとに経時的
   に得られるデータを記録した記録媒体であって、 前記複数の対象の１の属性について経時的に得られるデ
   ータは、前記複数の属性ごとに設けられた属性ファイル
   及び該各属性ファイルに共通の索引ファイルに記録さ
   れ、 前記属性ファイルは、データが同一の対象の同一の時間
   についてのデータが相互に対応するように時間順に所定
   長で記録されるデータ領域を有し、 前記索引ファイルは、前記対象を特定する情報と、該対
   象の前記属性ファイルでの位置を示す情報と、該対象の
   ある時刻の全ての属性に対するデータが既定値であるか
   否かを表す識別情報とが記録されるデータ領域を有し、 前記識別情報が既定値でない場合に前記属性ファイルに
   データを格納することを特徴とする時系列データを記録
   した記録媒体。
3. 【請求項３】 ある時間における複数の属性ごとのデー
   タを持ち得る複数の対象についての該属性ごとに経時的
   に得られたデータを記憶装置上に格納するため、 前記複数の対象の１の属性について経時的に得られるデ
   ータを時間順に所定長で格納するための領域を予め割り
   当てた属性ファイルを前記複数の属性ごとに設け、 前記対象を特定する情報と、該対象の前記属性ファイル
   での位置を示す情報と、該対象のある時刻の全ての属性
   に対するデータが既定値であるか否かを表す識別情報と
   を対応させて格納する索引ファイルを設け、 ある対象についてある時間に新しいデータが得られたと
   き、前記識別情報を更新し、前記識別情報が特定値であ
   る場合にのみ前記割り当てられた領域に該得られたデー
   タを格納することを特徴とする時系列データの格納方
   法。
4. 【請求項４】 ある時間における複数の属性ごとのデー
   タを持ち得る複数の対象についての該属性ごとに経時的
   に得られるデータを記録した記録媒体であって、 前記複数の対象の１の属性について経時的に得られるデ
   ータは、前記複数の属性ごとに設けられた属性ファイル
   及び該各属性ファイルに共通の索引ファイルに記録さ
   れ、 前記属性ファイルは、データを所定長で記録するための
   データ領域を予め割当て、 前記索引ファイルは、前記対象を特定する情報と、該対
   象の前記属性ファイルでの位置を示す情報と、該対象の
   ある時刻の全ての属性に対するデータが既定値であるか
   否かを表す識別情報とが記録されるデータ領域を有し、 ある対象についてある時間に新しいデータが得られたと
   き、前記識別情報を更新し、前記識別情報が特定値であ
   る場合にのみ前記割り当てられた領域に該得られたデー
   タを格納することを特徴とする時系列データを記録した
   記録媒体。
5. 【請求項５】 前記属性ファイルにデータを所定長で格
   納する際のデータ幅の決定方法は、該属性ファイルに格
   納すべきデータの値範囲を調べ、それらを表現可能な大
   きさをデータ幅とすることを特徴とする請求項１または
   ３記載の時系列データの格納方法。
6. 【請求項６】 前記属性ファイルにデータを所定長で格
   納する際のデータ幅の決定方法は、該属性ファイルに格
   納すべきすべてのデータの値範囲を調べ、それらを表現
   可能な大きさをデータ幅とすることを特徴とする請求項
   ２または４記載の時系列データを記録した記録媒体。
7. 【請求項７】 前記属性ファイルにデータを所定長で格
   納する際のデータ幅の決定方法は、該属性ファイルに格
   納すべきすべてのデータの値の分布を調べ、大多数のデ
   ータを表現できる大きさとし、該データ幅で表現できな
   いデータについては、前記領域には表現不能データであ
   ることを示す値を格納し、該表現不能データを該格納位
   置を検索キーとして、別領域に格納することを特徴とす
   る請求項１または３記載の時系列データの格納方法。
8. 【請求項８】 前記属性ファイルにデータを所定長で格
   納する際のデータ幅の決定方法は、該属性ファイルに格
   納すべきすべてのデータの値の分布を調べ、大多数のデ
   ータを表現できる大きさとし、該データ幅で表現できな
   いデータについては、前記領域には表現不能データであ
   ることを示す値を格納し、該表現不能データを該格納位
   置を検索キーとして、検索可能な別領域に格納すること
   を特徴とする請求項２または４記載の時系列データを記
   録した記録媒体。
9. 【請求項９】 少なくともひとつの前記属性ファイルに
   ついては、現時刻のデータを格納する代わりに、前時刻
   のデータとの差を格納し、データを所定長で格納するた
   めの前記領域にデータが治まらないときは別領域にデー
   タを格納することを特徴とする請求項７記載の時系列デ
   ータの格納方法。
10. 【請求項１０】 少なくともひとつの前記属性ファイル
    については、現時刻のデータを格納する代わりに、前時
    刻のデータとの差を格納し、データを所定長で格納する
    ための前記領域にデータが治まらないときは別領域にデ
    ータを格納することを特徴とする請求項８記載の時系列
    データを記録した記録媒体。
11. 【請求項１１】 前記属性ファイルのうち、一定期間参
    照されていない属性ファイルをデータ圧縮しておき、デ
    ータ圧縮された属性ファイルが参照されるとき、復元す
    ることを特徴とする請求項１、３、５、７、９のいずれ
    か１項に記載の時系列データの格納方法。
12. 【請求項１２】 前記属性ファイルのうち、一定期間参
    照されていない属性ファイルをデータ圧縮しておき、デ
    ータ圧縮された属性ファイルが参照されるとき、復元す
    ることを特徴とする請求項２、４、６、８、１０のいず
    れか１項に記載の時系列データを記録した記録媒体。