JPH117402A - データ処理方法 - Google Patents

Abstract

(57)【要約】 【課題】 データをロードする先のＭＤＤＢに最適な順
番でデータをロードすることができ、また、データ構造
に関する付加情報を持たない大量のデータからＭＤＤＢ
のデータ定義に必要な情報を容易に取り出すことができ
るデータ処理方法を得る。 【解決手段】 変換ソフトウェア４は、ＲＤＢ１または
ＭＤＤＢ２またはＭＤＤＢ３を参照し、ＭＤＤＢ３にデ
ータをロードするために必要なデータ定義ファイル６を
生成し、高速ソート装置８は次元の定義に従ってデータ
をソートし、ＭＤＤＢ３にデータをロードする際の効率
を向上させる。この際、データ処理装置７は、変換ソフ
トウェア４または高速ソート装置８の機能の一部により
実現される処理装置自身とＭＤＤＢ３の性能測定装置に
より、データ変換およびＭＤＤＢ３へのデータロードの
性能を測定し、試行錯誤によりデータを最も高速にＭＤ
ＤＢ３へロードする次元の定義順序を探す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、データ処理装置
を備えた計算機システムの利用に関わり、特に関係デー
タベースまたは多次元データベースから、別の多次元デ
ータベースへのデータ形式の転換およびデータ転送の方
法に関するものである。

【０００２】

【従来の技術】一般に、データベースは個別に生成され
ることが多く、それらのデータベースは整理統合して単
一の多次元データベースとすることによりＯＬＡＰ、Ｏ
ＬＴＰにおいて利用することが可能となる。図１は、従
来技術の例である。関係データベース（ＲＤＢ）１また
は多次元データベース（ＭＤＤＢ）２のデータを別のＭ
ＤＤＢ３にロードする場合、専用の変換ソフトウェア４
を用いて、ＭＤＤＢ３にデータをロードするためのデー
タの中間ファイル５およびデータ形式の定義ファイル６
を生成する。

【０００３】多次元データベースにおいては、あらかじ
め集計データを含んだ形でデータが蓄積されているの
で、多次元データベースにいったんデータを蓄積してし
まえば、データの柔軟で多角的な分析を高速に行なうこ
とができる。また、例えば特平８-１３７９６７では、
ＲＤＢのような２次元の表形式で表されたデータから多
次元データベースのような多次元の表を生成する方法が
示されている。

【０００４】図３はある会社で販売している製品の、日
本各地での売上高を示す。縦軸は製品の売れた場所、横
軸は売れた時期を示す。図において、「売上高」のデー
タを表すのは、表の中身の数字である。これに対して、
「Feb96」や「東京」はそれぞれ各売上高データの表に
おける位置を示す情報である。両者を区別するため、本
発明では図３の「売上高」のような表の中身に当たる情
報を「データ値」と呼び、図３の「Feb96」や「東京」
などを「次元の要素」と呼ぶことにする。

【０００５】図４は、図３を地方ごとに売上高を集計し
たものである。これは、図２１に示す次元の構造におい
て、「東京」を直接含む階層から、１つ上のレベルの
「関東」などを含む階層に視点を移動したものと考える
ことができる。このように、次元の要素を階層構造の１
つ上のレベルで集計して表示するような操作は、ＭＤＤ
Ｂにおいては一般に「ロールアップ」と呼ぶ。

【０００６】図６は、図５で関東地方だけを詳しく表示
したものである。このように次元の要素を階層構造の１
つ下のレベルで詳しく表示するような操作は、ＭＤＤＢ
においては「ドリル・ダウン」と呼ぶ。図３〜５は各地
域での各種製品の合計の売上高を示している。これに対
して、図６は、製品毎の売り上げを詳しく分析するため
に、表に表示される製品名を切り替えようとしていると
ころである。表示されている表は洗濯機の売り上げを示
す。この例では、表に対して垂直な方向に、製品の種類
を示す次元の軸があると、仮想的に考えることができ
る。図３〜６の一連の操作は、販売地域、販売時期、製
品の種類、の３次元からなるデータベースを操作してい
ると見なすことができる。図２２に、図３〜６のＭＤＤ
Ｂにおける、「製品の種類」の次元の軸の階層構造を示
す。

【０００７】図７は、図４における、製品が売れた地域
の軸（縦軸）と売れた製品名の軸（図に垂直な方向にあ
る「製品の種類」の次元）を入れ換えたものである。ま
た、ＭＤＤＢではこの他に、必要に応じて、表やグラフ
に表示する次元の数を、もとのデータの許す範囲で増や
したり減らしたりする操作を提供する。これらの操作は
一般的に「次元に対する操作」とみなすことができる。

【０００８】ＭＤＤＢでは、以上述べたような「ロール
アップ」「ドリルダウン」「次元に対する操作」などを
基本操作として、データを多角的かつ柔軟に分析する方
法を提供している。従来の代表的なデータベースである
ＲＤＢで同じような処理を実現しようとすると、一般
に、ＲＤＢがサポートするデータ問い合わせ言語である
ＳＱＬの Group By 文や結合演算（join）など計算量の
多い命令を含む複雑なプログラムを作る必要があった。
これに対し、ＭＤＤＢはデータの内部表現やデータベー
スマネジメントシステムが提供するデータ参照機能が
「ロールアップ」「ドリルダウン」「次元に対する操
作」に適した実現方式になっている。いったんデータを
ＭＤＤＢにロードすると、データ操作の容易さや効率の
点で、ＭＤＤＢはＲＤＢなどの既存のデータベースに対
して優れていると言える。

【０００９】従来技術では、上記のようなＭＤＤＢの特
徴を利用するためＲＤＢのデータをＭＤＤＢにおいて使
用するためにロードする場合、一般には同じデータをＲ
ＤＢにロードするよりも時間がかかる。これはまず、Ｍ
ＤＤＢにおいては、ＲＤＢのデータにはない集計データ
の計算に時間がかかるためである。また、もし仮にＲＤ
Ｂでも同等の集計計算をする場合を想定したとしても、
データベース処理全体（データロードの時間に集計の計
算時間を加えたもの）はＭＤＤＢの方が不利となる場合
がある。

【００１０】これは、ＭＤＤＢのサイズは最悪のケース
でデータの件数を次元の次数だけ乗じたものとなるた
め、元になるＲＤＢに蓄積されているデータの件数が多
いと、ＭＤＤＢにロードすべきデータファイルの大きさ
とＲＤＢのデータファイルの大きさの比がＭＤＤＢの方
が大きくなることがあるからである。一般に、ＭＤＤＢ
の主な用途であるデータの多角的分析の実施において、
分析の精度を上げるために、分析対象のデータ件数を増
やしたり、分析の視点の数を増やしたりするほど、ＭＤ
ＤＢの処理全体はＲＤＢの処理全体に対して性能の点で
は不利となることが多くなる。

【００１１】以上のような事情で、頻繁にデータおよび
集計結果を更新するような用途にＭＤＤＢを適用するの
は難しかった。特開平８-１３７９６７もデータ定義を
変換する際に処理効率を向上させる技術については言及
していない。また、多次元の表の形式になったデータベ
ースへ大量のデータをロードする際の処理を高速化する
技術についても触れていない。また、種類の異なるＭＤ
ＤＢの間でデータを交換したいという要望もあったが、
これも日常頻繁に行なうには従来の技術ではデータロー
ドの性能が十分でなかった。例えば、あるＭＤＤＢでは
ＧＵＩ（グラフィカル・ユーザ・インターフェース）で
データ分析操作を提供するために、次元の階層構造のデ
ータとして、各次元の要素名の他に、自動的にアルファ
ベットや数字からなる索引データを割り当てる。いっぽ
う別のＭＤＤＢでは、データ分析操作のＧＵＩはＭＤＤ
Ｂ本体では提供せず、ＭＤＤＢサーバと連係して動作す
るクライアントソフトウェアまたはミドルウェアとして
提供するため、このような索引データは定義されない。

【００１２】

【発明が解決しようとする課題】従来のデータ処理方法
は以上の様に構成されているので、次元の定義方法が異
なる各ＭＤＤＢの間でデータを交換するには、データ定
義（次元の要素の定義、次元内の階層構造の定義など）
の変換を伴うため、データをロードする先のＭＤＤＢに
最適な順番でデータをロードするのが難しかった。ま
た、企業活動のグローバル化と競争の激化にともない、
ＭＤＤＢの特徴であるデータの分析機能を、企業活動の
記録など、従来は量が多過ぎてデータベース化するのに
適していなかったデータに適用して、より詳しい分析を
行ないたいという要望が高まっているが、従来の技術で
はこの要望に応えるのが難しかった。このようなデータ
は、一般にはデータ構造に関する付加情報を持たないの
で、大量のデータからＭＤＤＢのデータ定義に必要な情
報を取り出すためには、ＭＤＤＢ専用のデータ定義言語
によるプログラムを作成する必要があるが、この作業が
繁雑だったのと、実行のために計算機資源を大量に占有
し、他の計算機業務の妨げとなっていた等の問題点があ
った。

【００１３】この発明は、上記のような問題点を解消す
るためになされたもので、データをロードする先のＭＤ
ＤＢに最適な順番でデータをロードすることができ、ま
た、データ構造に関する付加情報を持たない大量のデー
タからＭＤＤＢのデータ定義に必要な情報を容易に取り
出すことができるデータ処理方法を得ることを目的とす
る。

【００１４】

【課題を解決するための手段】この発明に係るデータ処
理方法は、ロード元である関係データベース又は第１の
多次元データベースからロード先の第２の多次元データ
ベースへデータをロードするシステムにおいて、上記ロ
ード先のデータ定義を参照し上記データを構成する複数
の次元の要素の構成順を組み替えるステップ、上記各次
元の要素順に上記データをソートし上記第２の多次元デ
ータベースへ上記データをロードするものである。

【００１５】また、ロード元である関係データベース又
は第１の多次元データベースからロード先の第２の多次
元データベースへデータをロードするシステムにおい
て、上記ロード元のデータ定義を参照し上記データを構
成する複数の次元の要素の構成順を組み替えるステッ
プ、組み替えた構成順においてサンプルデータによりロ
ード時間を測定するステップ、上記構成順を組み替えて
上記測定を繰り返すことにより上記ロード時間が最小と
なる構成順を上記ロード先のデータ定義として生成する
ステップ、上記ロード先のデータ定義に基づき各次元の
要素順に上記データをソートし上記第２の多次元データ
ベースへ上記データをロードするステップからなるもの
である。

【００１６】さらに、ロード元である関係データベース
又は第１の多次元データベースからロード先の第２の多
次元データベースへデータをロードするシステムにおい
て、上記ロード元のデータ定義を参照し上記ロード先の
データ定義を対話的に設定するステップ、設定したデー
タ定義に基づく要素の構成順のサンプルデータによりロ
ード時間を測定するステップ、上記構成順を組み替えて
上記測定を繰り返すことにより上記ロード時間が最小と
なる構成順を上記ロード先のデータ定義として生成する
ステップ、上記ロード先のデータ定義に基づき各次元の
要素順に上記データをソートし上記第２の多次元データ
ベースへ上記データをロードするステップからなるもの
である。

【００１７】また、ロード元である関係データベース又
は第１の多次元データベースからロード先の第２の多次
元データベースへデータをロードするシステムにおい
て、フラット形式のサンプルデータを上記第２の多次元
データベースへロードする第１の時間を測定するステッ
プ、そのフラット形式のサンプルデータを用いて上記第
２の多次元データベースにおいてキューブ形式のデータ
を生成する第２の時間を測定するステップ、上記フラッ
ト形式のサンプルデータを用いて上記関係データベース
又は第１の多次元データベースにおいてキューブ形式の
データを生成する第３の時間を測定するステップ、その
キューブ形式のデータを上記第２の多次元データベース
へロードする第４の時間を測定するステップ、上記第１
の時間と上記第２の時間の合計時間と上記第３の時間と
上記第４の時間の合計時間とを比較し上記データをフラ
ット形式で上記第２の多次元データベースへロードする
かキューブ形式のデータを生成した後上記第２の多次元
データベースへロードするかを上記合計時間の少ない方
に決定するステップ、この決定結果に基づき上記第２の
多次元データベースへ上記データをロードするステップ
からなるものである。

【００１８】さらにまた、データ構造に関する付加情報
を有しないデータレコード群からユーザが指定する区切
り文字を検出することにより上記データレコードのフィ
ールドの値を抽出するステップ、抽出したフィールドの
値に基づく要素の構成順のサンプルデータによりロード
時間を測定するステップ、上記構成順を組み替えて上記
測定を繰り返すことにより上記ロード時間が最小となる
構成順をロード先のデータ定義として生成するステッ
プ、上記ロード先のデータ定義に基づき各次元の要素順
に上記データをソートし多次元データベースへ上記デー
タをロードするステップからなるものである。

【００１９】また、上記データレコード群は可変レコー
ド長のレコードを単位とするものであってもかまわな
い。

【００２０】さらに、データ構造に関する付加情報を有
しないデータレコード群からユーザが指定する区切り文
字を検出することにより上記データレコードのフィール
ドの値を抽出するステップ、抽出したフィールドの値と
ロード先のデータ定義とを比較し利用可能なデータ定義
を再利用することにより新たにロード先のデータ定義を
生成するステップ、その新たなデータ定義に基づく要素
の構成順に上記データレコード群を組み替えるステッ
プ、上記新たなデータ定義に基づき各次元の要素順に上
記データをソートし多次元データベースへ上記データを
ロードするステップからなるものである。

【００２１】また、ロード元のデータを定期的に監視し
上記データの更新を検出したとき上記データを適正に処
理後ロードするものである。

【００２２】

【発明の実施の形態】

実施の形態１．図１はこの発明の実施の形態１であるデ
ータ処理方法を実施するためのデータベースシステムの
構成を示すもので、図において、１は関係データベース
（ＲＤＢ）、２は多次元データベース（ＭＤＤＢ）であ
り、これらのデータを別の多次元データベース（ＭＤＤ
Ｂ）３にロードする場合、バスにより接続された専用の
付加プロセッサであるデータ処理装置７を経由させるこ
とによりＭＤＤＢ３にロード可能なデータ形式に変換す
るものである。

【００２３】このデータ処理装置７は、専用の変換ソフ
トウェア４を用いることにより、ＭＤＤＢ３にデータを
ロードするためのデータの中間ファイル５およびデータ
形式の定義ファイル６を生成する。通常、変換ソフトウ
ェア４、中間ファイル５、データ形式の定義ファイル６
はいずれもデータ処理装置７の上に実現されるが、シス
テム設計上の都合によっては、ＲＤＢ１、ＭＤＤＢ２、
ＭＤＤＢ３のいずれかを構成する計算機の上に実現して
もよい。また、データ処理装置７と、ＲＤＢ１、ＭＤＤ
Ｂ２、ＭＤＤＢ３のいずれかを構成する計算機とが協調
して動作することにより実現するようにしてもよい。

【００２４】定義ファイル６は、データ定義プログラム
から構成され、例えば、 CREATE TABLE 表１ ｛ 次元１ CHAR（10）， 次元２ CHAR（4）， 次元３ DATE， データ INT（32） ）； CREATE CATEGORY 表１．階層１ （ ／／次元１の階層構造の定義 ／／図21の構造に相当 レベル２ CHAR（10）， レベル１ CHAR（10）， レベル０ CHAR（10） ）； INSERT CATEGORY INTO 表１．階層１（ レベル２ VALUES （ ’全国’ ’’ ）， レベル１ VALUES （ ’関東’ ’全国’， ’中部’ ’全国’， ’近畿’ ’全国’， ’九州’ ’全国’ ）， レベル０ VALUES （ ’東京’ ’関東’， ’鎌倉’ ’関東’， ’静岡’ ’中部’， ’名古屋’ ’中部’， ’神戸’ ’近畿’， ’伊丹’ ’近畿’， ’熊本’ ’九州’， ’長崎’ ’九州’， ） ）； 以上のように表される。

【００２５】また、変換ソフトウェア４は、高速ソート
装置８を含むデータ処理装置７のハードウェアを管理す
るソフトウェアを含む。必要に応じてＭＤＤＢ３および
データ処理装置７自身の性能を測定するソフトウェアを
含んでもよい。あるいは、この性能測定はＲＤＢ１、Ｍ
ＤＤＢ２、ＭＤＤＢ３のいずれかを構成する計算機のハ
ードウェアまたはソフトウェアの一部として実現しても
よい。また、データ処理装置７と、ＲＤＢ１、ＭＤＤＢ
２、ＭＤＤＢ３のいずれかを構成する計算機とが協調し
て動作することにより実現するようにしてもよい。

【００２６】データ処理装置７において、変換ソフトウ
ェア４は、ＲＤＢ１またはＭＤＤＢ２またはＭＤＤＢ３
を参照し、ＭＤＤＢ３にデータをロードするために必要
なデータ定義ファイル６を生成し、高速ソート装置８は
次元の定義に従ってデータをソートし、ＭＤＤＢ３にデ
ータをロードする際の効率を向上させる。この際、デー
タ処理装置７は、必要に応じて、変換ソフトウェア４ま
たは高速なソート装置８の機能の一部により実現される
処理装置自身とＭＤＤＢ３の性能測定装置により、デー
タ変換およびＭＤＤＢ３へのデータロードの性能を測定
し、試行錯誤によりデータを最も高速にＭＤＤＢ３へロ
ードする次元の定義順序を探す。

【００２７】通常、ＭＤＤＢの実現においては、補助記
憶装置（ハードディスク）の内部にデータ値を格納する
ための領域をあらかじめ確保する。この領域は、仮想的
な多次元の箱とみなすことができる。この箱の各次元
は、ＭＤＤＢにおけるデータの見方の変換を容易にする
ために、あらかじめ各次元の要素の値の順に記憶領域を
確保する。このため、データがそれぞれの次元において
この箱の各次元軸上の要素の値の順にソートされている
と、記憶装置への余分なアクセスや空回りなどがなくな
りデータロード時間が短縮される。この際、ＭＤＤＢの
主な用途であるデータの多角的分析の実施において、分
析の精度を上げるために、分析対象のデータ件数を増や
したり、分析の視点の数を増やしたりするためには、大
量のデータを高速に集計してロードする必要がある。実
施の形態１においては、この集計時間およびデータロー
ド時間を短縮することにより、より多くのデータを対象
として分析したり、分析の頻度を上げたりすることが可
能になる。

【００２８】図８は、図３〜７で用いたＭＤＤＢに格納
されたデータの例の、ロード先ＭＤＤＢのデータ表現を
表す。ここで、図の最上段に示されている、販売時期を
表すフィールド10、製品の種類を表すフィールド11、販
売地域を表すフィールド12はそれぞれロード先での「販
売時期」「製品の種類」「販売地域」の各次元に対応し
ている。枠で囲まれた部分はデータレコードを示し、各
次元の下にあるのがそのデータレコードにおける次元の
要素、データを表すフィールド13の数字はデータ値とし
ての売上高を示す。また、この例では、データレコード
の内部のフィールドは「販売時期」「商品の種類」「販
売地域」「売上高（データ値）」の順に並んでいるが、
この順序を次元の定義の順序と呼ぶ。この次元の定義の
順序は、定義ファイル６のデータ定義プログラムにより
設定されている。

【００２９】通常、ＭＤＤＢへのデータロードでは、ロ
ードすべきデータの順序やデータレコードのフィールド
の位置が、かならずしも図８に示すようなロード先ＭＤ
ＤＢのデータ表現どおりに並んでいるとは限らない。こ
の様子を図９に示す。このとき、図３〜７の例のＭＤＤ
Ｂを実現するためには、ロード元のデータ14をロード先
ＭＤＤＢにロードする際に図９の配置から図１０の配置
に並べかえる必要がある。具体的には、ロード元データ
で販売時期を表すフィールド16を販売時期を表すフィー
ルド10に、ロード元データで製品名を表すフィールド15
を製品名を表すフィールド11に、ロード元データで販売
地域を表すフィールド17を販売地域を表すフィールド12
に、ロード元データでデータ（売上高）を表すフィール
ド18をデータ（売上高）を表すフィールド13に、それぞ
れ対応させるよう、それぞれのデータレコードについて
データフィールドの順序を並べ替えてロードする必要が
ある。

【００３０】データ処理装置７は、必要に応じてＲＤＢ
１またはＭＤＤＢ２のデータ定義を参照しながら、専用
のソート装置を用いてロード前のデータを図８の順番に
並べ替える。ＭＤＤＢ３へのデータのロードに当たって
は、あらかじめ図８のイメージで確保されている記憶領
域のアドレスの若い方から順番に、データを配置してい
く。データの並び替えを、専用のソート装置８を用いて
高速に行なうので、従来の方法よりも高速にＭＤＤＢ３
にデータをロードすることができる。従って、ソートや
フィールドの並び替えを含めたデータロードにかかる時
間を短縮することができる効果がある。

【００３１】また、通常、多次元データベースを処理す
る計算機はデータベース処理以外の業務にも使用される
が、本発明による方法はこの計算機の計算時間や計算資
源を節約し、多次元データベース処理以外の業務につい
ても効率を改善する効果がある。ソートやフィールドの
並び替えの処理は一般に大量のメモリを消費し、多次元
データベース処理以外の業務を同一の計算機で実施する
際の効率低下の要因となっていた。また、あるＭＤＤＢ
から別のＭＤＤＢへのデータロードのように、すでに何
らかの順番でソートされているデータについては、別の
ＭＤＤＢへのデータロードに際してデータそのものをあ
らためてソートし直さなくても、ロード先データベース
における次元の定義の順番をデータの並んでいる順番に
合わせるだけでデータロードが高速になる場合がある。
このため、次元の定義の順序によってもデータのロード
速度が異なる場合がある。

【００３２】本実施の形態は、この次元定義の順序を試
行錯誤により変更し、合わせてサンプルデータを用いて
次元の定義の順序とデータロードの性能の関係を測定す
ることにより、ロード先のロード性能が最も速いデータ
定義を自動的に生成することを可能にするものである。

【００３３】例えば、１カ月ごとに、その月の商品ごと
の売上のデータを集計してＭＤＤＢにロードし分析す
る、といったような定型的なデータベース運用を行なう
場合は、ロード先のデータ定義はあらかじめユーザによ
って定義されている。このときの処理の流れを、図２に
示す。まず、ロード元のＭＤＤＢ２から、データ定義を
取り出す（ステップＳ１）。続いて、ロード先のＭＤＤ
Ｂ３から、データ定義を取り出す（ステップＳ２）。そ
して、ロード先のデータ定義にある次元のそれぞれに対
し、ロード元のデータレコードにおいてその次元に対応
するフィールドを探す（ステップＳ３）。ここで、デー
タレコードとは、例えば「個々の商品の売り上げの記
録」のように、データの意味上の最小のまとまりであ
る。また、フィールドとは、データレコードにおける特
定の部位のことである。通常はデータレコードの先頭か
らの相対位置とデータの長さで表される。データレコー
ドとフィールドの関係を図２４に示す。前述の例では、
商品の売り上げにおける「商品名」「売れた場所」「売
れた時刻」「売上高」のような情報が、図２４のフィー
ルド1−1〜4、2−1〜4、3−1〜4、・・・のような個々
のフィールドに保持される。

【００３４】ロード元のデータレコードにおいて、ロー
ド元の次元に対応するフィールドを探す処理は、例え
ば、図２３に示すような処理で実現することができる。
図２３においては、ロード先とロード元のデータ定義に
ある次元のそれぞれを比較し、次元の名前が一致するか
どうか、それぞれの次元の各要素のデータ型・長さが一
致するかどうか、それぞれの次元の各要素の値が一致す
るかどうかを調べ、次元の定義そのものが一致するか確
かめている。もしロード先のデータの次元の定義に一致
するものが、ロード元の次元定義にあったら、そのロー
ド元の次元の定義に対応するフィールドが、求めるべき
フィールドである。なお、データベース実現の方針によ
っては、次元の名前が一致する必要はない。またＭＤＤ
Ｂの実現の方針によっては、例えばロード元とロード先
の次元の定義について一方が他方の部分集合になってい
てもよい。ただしこの場合にはユーザが対話的に対応関
係を確認するか、プログラムなどで明示的に対応関係を
データ処理装置に指示する必要がある。

【００３５】図２において、ロード元のデータを取り出
し、データレコードのフィールドとロード先のデータ定
義との対応関係に従ってデータレコードの形式を変更
し、さらに、ソート装置を用いて各次元の要素の順にレ
コードをソートする。この際、ソートキーは各次元の定
義の順序で優先度を設定する。ソート処理が終わった
ら、データをＭＤＤＢ３へロードする（ステップＳ
４）。

【００３６】ロード先のデータ定義の代わりに、ロード
元のデータ定義をもとに、データ処理装置が自動的に試
行錯誤によりロード先のデータ定義を作成するようにし
た処理のフローを図１０に示す。

【００３７】図１０において、先ず、ロード元のデータ
ベースがＭＤＤＢ２である場合は、次元の定義を取り出
す（ステップＳ１１）。ロード元のデータベースがＲＤ
Ｂである場合は、データの各カラム（データ値のカラム
を除く）を階層構造のない１つの次元であるとみなすこ
とにより、以降の処理をＭＤＤＢと同様に処理を進める
ことができる。ここで「カラム」というのは、各レコー
ド内でレコードの先頭からの順番が同じであるフィール
ドの集合である。図２４においては、例えばフィールド
1-1、2-1、3-1、…は１つのカラムである。また例えば
フィールド1-2、2-2、3-2、…も１つのカラムをなす。

【００３８】このとき、ロード先のＭＤＤＢ３の実現方
針によっては、各次元のとり得る値のリストを次元定義
として生成する必要がある。このために、データ処理装
置７はロード元のデータレコードをいったん全て読み込
み、各カラムの取る値のリストを生成する。以下の説明
では、ロード元のデータベースはＭＤＤＢ２であるもの
とする。

【００３９】次に、取り出した次元のそれぞれについ
て、次元を構成する要素を取り出す（ステップＳ１
２）。このとき、取り出す要素の個数はユーザが明示的
に指定してもよい。あるいは、データ処理装置の設計時
に個数をあらかじめ決めておいてもよい。続いて、次元
の順序の全ての組み合わせに対して、取り出した次元の
要素をもとにロード先の次元の定義（ステップＳ１３）
およびサンプルデータを生成する（ステップＳ１４）。
そして、それぞれのケースについてサンプルデータのＭ
ＤＤＢ３へのロード性能を測定する（ステップＳ１
５）。このサンプルデータの値は例えば乱数で決めてよ
い。そして、測定結果で最速のロード性能を与える次元
の定義の順序を、ロード先のデータにおける次元の定義
の順序にする（ステップＳ１６）。

【００４０】さらに、データ処理装置７は、ロード元の
データを取り出し、データレコードのフィールドとロー
ド先のデータ定義との対応関係に従ってデータレコード
の形式を変更し、さらに、ソートキーを各次元の定義の
順序で優先度を設定（ステップＳ１７）後、ソート装置
を用いて各次元の要素の順にレコードをソートする（ス
テップＳ１８）。ソート処理が終わったら、データをＭ
ＤＤＢ３へロードする（ステップＳ１９）。

【００４１】実施の形態２．データロード時にユーザが
その場でロード先のデータ定義を、ロード元のデータ定
義を参照しながら対話的に生成することを可能にするこ
の発明の実施の形態２としてのデータ処理方法の処理フ
ローを図１１に示す。

【００４２】ロード元データベースのデータ定義を取り
出す（ステップＳ２１）。続いて、取り出した情報をも
とにロード元データの次元の一覧をユーザに表示する
（ステップＳ２２）。ユーザが次元の一覧の表示から、
ロード先ＭＤＤＢ３に転送する次元を指定する（ステッ
プＳ２３）。この表示およびユーザの選択は、例えばＧ
ＵＩ（グラフィカル・ユーザ・インターフェース）およ
びマウス装置によるクリックまたはドラッグなどの方法
を用いて実現することができる。またこのとき、全ての
次元をロード先ＭＤＤＢ３に転送する必要はない。例え
ば、ユーザが転送を指定しなかった次元については、デ
ータレコードのうちその次元に対応するフィールドはデ
ータ処理装置７によって編集し、ロードすべきデータか
ら除外してよい。あるいは、ユーザの都合によっては編
集せず転送できるようにしてもよい。

【００４３】続いて、ユーザは端末装置を操作すること
によりロード先の次元の順序を指定する（ステップＳ２
４）。ユーザの選択した次元について、ロード先ＭＤＤ
Ｂ３のデータ定義方式にのっとり実施の形態１で述べた
方法により次元の定義を生成する（ステップＳ２５）。
ただし、ロード先ＭＤＤＢの設計の方針によっては、次
元の順序を自動的に設定せず、ユーザが設定するように
してもよい。次元の順序をユーザが指定するかデータ処
理装置が自動的に設定するかの設定はデータベース実現
の方針による。例えばユーザがデータ処理装置装着時に
指定できるようにしておいてよい。そして、ソート装置
８を用いてデータレコードの編集および並べ替えを行な
い、ロード先のＭＤＤＢ３にデータをロードする（ステ
ップＳ２６）。

【００４４】実施の形態３．この発明の実施の形態３に
おいては、ロード先のデータ定義をユーザが決めた簡単
な手続きに従って自動生成する。データ構造に関する付
加情報を持たないデータについて、データに簡単な特徴
がある場合に、これを用いてＭＤＤＢの次元定義を自動
的に生成し、複雑なプログラミングを行なうことなしに
ＭＤＤＢにデータをロードすることができる。これによ
り、ＭＤＤＢの特徴であるデータの分析機能を、実行の
ために計算機資源を大量に占有することにより他の計算
機業務の妨げとなることなく、従来は量が多過ぎかつデ
ータ構造に関する付加情報を持たないためにデータベー
ス化するのに適していなかったデータに適用することを
可能にし、ユーザがより詳しい分析を行なうことをでき
るようにするものである。

【００４５】データレコードが固定長で、全てのレコー
ドについてフィールドの配置などのフォーマット（形
式）が同一であるとき、このデータがデータ構造に関す
る付加情報を持たなくても、ユーザが自分でロード先の
ＭＤＤＢ３のデータ定義を生成するなどの手間をかけず
に、ＭＤＤＢを効率的に構築することを可能にする

【００４６】図１２に、実施の形態３の処理のフローを
示す。まず、ユーザがデータレコード中のフィールドの
区切り文字を指定する（ステップＳ３１）。区切り文字
とは、フィールドを区分するための特定の文字のことで
例えば「；」「＿、」「＝」等が該当し、これらを指定
するとは、ユーザがＧＵＩ画面又はコマンドで指定する
ことを意味する。この区切り文字は例えば、データ処理
装置およびデータベース実現上の都合によっては、あら
かじめデータ処理装置に登録しておいてもよく、また例
えばデータ処理装置の実行開始時にユーザが対話的に入
力するような仕組みを提供してもよい。次に、ロード元
のデータから、データレコードの任意の１つを取り出す
（ステップＳ３２）。そして、各区切り文字のレコード
先頭からの相対位置を調べて記録する（ステップＳ３
３）。このとき、レコードの先頭または区切り文字また
はデータレコードの終端記号で囲まれた最短の区間がロ
ード先におけるデータレコードのフィールドとなる。デ
ータ処理装置７は、各フィールドを自動的に１つの次元
に割り当てることにより、ロード先のデータ定義を生成
する（ステップＳ３４）。

【００４７】続いて、データレコードの中でデータ値を
保持するカラムの位置をユーザが対話的に指定する。こ
の指定は、データベース装置の実現方法によっては必ず
しも必要ではなく、例えばデータレコードの先頭のカラ
ムまたは終端のカラムを常にデータ値を保持するカラム
として扱ってもよい。また例えば、データ処理装置の実
行開始前にあらかじめユーザが登録するようにしてもよ
い。また、一般にＭＤＤＢにおいては、１つの次元の要
素の種類よりもデータ値の個数の方が多いので、このこ
とを利用して自動的にデータ値を保持するカラムを検出
するようにしてもよい。データ処理装置７は、全データ
レコードをソートするために読み込む。このとき、各フ
ィールドのとる値を記録しておき、データを読み込んで
ソートをすると、ユーザに各次元の要素の一覧を提示す
る（ステップＳ３５）。

【００４８】このとき例えば、ユーザが各次元について
提示された値一覧をもとに階層構造をその場で対話的に
定義する方法を提供してもよい。また、データロードと
同時に次元を定義する必要がない場合は、各次元の一覧
を提示したり、次元のなかの階層構造を対話的に定義し
たりする機能を提供する必要はない。あるいは例えば、
各次元の要素の一覧および次元の階層構造の対話的定義
機能は、データ処理装置の装着時などにあらかじめユー
ザが起動するかどうかを設定できるようにしておいても
よい。

【００４９】また、このとき、要素があらかじめ定めた
規定の個数を越えたカラムについては、次元の要素でな
くデータ値を保持している可能性があるので、次元とし
て定義することを中止するような方法を備えていてもよ
い。更にこのとき、このカラムを、データ値を保持する
カラムとして扱うような仕組みを備えてもよい。この方
法の実現に当たっては、例えばデータ処理装置７が自動
的にデータ値を保持するカラムとして扱うような設定を
してもよい。

【００５０】あるいは、このようなカラムを検出した場
合、ユーザに対話的にデータ値を保持するカラムとして
扱うような設定をするかどうかの確認をする仕組みを備
えてもよい。また、各次元の要素を記録していく代わり
に、あらかじめ各次元のとり得る要素の組、または条件
を決めておき、これ以外の値をデータレコードの当該カ
ラムで検出したら処理を打ち切る機構を備えてもよい。
このとき各次元のとり得る要素の組または条件は、例え
ばデータレコード群とは別に１つのファイルとしてまと
めて登録しておき、データ処理装置７の起動時などに自
動的に取り込むようにすることにより実現できる。

【００５１】ただし、本実施の形態を実施するに当たっ
ては、上記の方法で得られるロード元のデータレコード
内のフィールド数が一定である必要がある。もし一定で
ない場合でも、例えば全データレコード中フィールド数
が最も少ないデータレコードのフィールド数に合わせ
て、ＭＤＤＢ３にロードするフィールドの個数を決める
ことにより、適用することができる。この場合、例えば
ロードすべきフィールドはデータレコードの先頭から順
に選び、余ったフィールドはロードしないことにより、
ロードすべきデータレコードのフィールドの個数を一定
個にすることができる。

【００５２】また例えば、指定した個数のフィールドを
持つデータレコードだけをＭＤＤＢ３にロードすること
にしてもよい。あるいは、例えばユーザがＭＤＤＢ３に
ロードするフィールドまたはカラムを対話的に指定する
仕組みを備えてもよい。またあるいは、ユーザがＭＤＤ
Ｂ３にロードするフィールドまたはカラムを選択するル
ールを設定できるような仕組みを提供してもよい。

【００５３】実施の形態４．この発明の実施の形態４に
おいては、実施の形態３における固定長のデータとは異
なり、可変長のデータレコードで構成されたデータ構造
に関する付加情報を持たないデータを、ロード元のデー
タ定義をあらかじめユーザが決めた簡単な手続きに従っ
て自動生成する。

【００５４】図１３に処理フローを示す。一般にＭＤＤ
Ｂは内部でのデータ表現の都合上、各次元について一定
のフォーマットに従ったデータレコードのみ入力を受け
付ける。このため、本実施の形態では、可変長のデータ
レコードで構成されたデータを固定長のフィールドで構
成されたデータに編集する必要がある。図１３におい
て、まずユーザが各レコードにおけるフィールドの区切
り文字を指定し（ステップＳ４１）、データ値を持つカ
ラムの位置を指定する（ステップＳ４２）。このあと、
以下に述べる３つの方針をユーザに提示し、ユーザは対
話的に方針を選択する。

【００５５】第１の方針は、データレコードのうち固定
長のフィールドと見なせる部分だけを取り出して、それ
らのフィールド群を包含するカラムをＭＤＤＢ３にロー
ドする方法がある。データ処理装置７でデータを編集す
る際に、可変長のフィールドを検出したらロードするデ
ータから削除する。この処理のフローを、図１４に示
す。

【００５６】図１４ではまず、ロード元のデータをデー
タ処理装置７に入力し、ユーザはデータレコードの区切
り文字を合わせて指定する（ステップＳ４３）。続い
て、各データレコードについて、レコードの先頭または
区切り文字またはレコードの終端記号のいずれかに挟ま
れた部分のうち最短の部分を順次取り出す。このそれぞ
れがデータレコードの個々のフィールドとなる（ステッ
プＳ４４）。

【００５７】全てのデータレコードについて、レコード
の先頭から数えた順番が同じフィールド同士でその長さ
を比較していく。もし、１つでも長さの異なるフィール
ドを含むカラムはＭＤＤＢ３へロードする対象から外
す。このロード対象から外す処理は、は例えば、データ
処理装置７において各データレコードを１バイト毎にデ
ータ処理の単位とし、それぞれの単位に対応した部分に
ロードするかしないかを示す補助データを付加しておく
ことにより実現できる。データ処理装置７は、これらの
処理と合わせて各フィールドの値、およびそれらの値が
どのカラムに属するかを記録していく（ステップＳ４
５）。ここでカラムを記録するのは、次元又はデータベ
ース変数の定義を生成したあとで、データをＭＤＤＢ３
にロードするプログラムを作成するとき、ロード元のデ
ータのどのカラムがどの次元に対応するかを指定する必
要があるからである。

【００５８】そして、全レコードの全フィールドについ
て上記のチェックが終了したら、上記のチェックでロー
ド対象となったフィールドのみをソート装置８に送り、
生成した次元の定義の順序に従ってロード対象となるフ
ィールド群をソートし、データレコードの編集および
並べ替えを行ない、ロード先ＭＤＤＢ３にデータをロー
ドする（ステップＳ４６）。

【００５９】このとき、例えばユーザが各次元について
提示された値の一覧をもとに階層構造をその場で対話的
に定義する方法を提供してもよい。この一覧を提示する
機能を提供しない場合は、各フィールドの値を記録する
のをやめるよう設定できるようにしてもよい。あるい
は、各次元の値を記録していく代わりに、あらかじめ各
次元のとり得る値の組または条件を決めておき、これ以
外の値をデータレコードの当該カラムに属するフィール
ドで検出したら処理を打ち切る機構を備えてもよい。こ
のとき各次元のとり得る値の組または条件は、例えばデ
ータレコード群とは別に１つのファイルとしてまとめて
登録しておき、データ処理装置７の起動時などに自動的
に取り込むようにすることにより実現できる。

【００６０】また、各フィールドの値を記録する場合で
も、各次元のとり得る要素数の上限をユーザがあらかじ
め設定できるようにしておいてよい。このとき、各次元
において要素の個数が上限を越えたら、そのフィールド
を含むカラムは次元でなくデータ値を保持している可能
性があるので、フィールドの値の記録をやめるようにし
てよい。あるいは、データベース設計の方針によって
は、この時点でデータをロードする作業を中止してもよ
い。

【００６１】第２の方針は、データレコードにおけるフ
ィールドのそれぞれについてユーザが長さを指定し、全
レコードの当該フィールドをその長さに合わせて編集す
る方法がある。この処理の様子を、図１５に示す。

【００６２】図１５において、まずユーザが各フィール
ドの区切り文字、およびデータレコード内の各フィール
ドについてそれぞれの長さを指定する（ステップＳ５
１）。そして、ロード元のデータをデータ処理装置７に
入力し（ステップＳ５２）、ユーザの指定した区切り文
字をもとに各データレコードをフィールドに分割する
（ステップＳ５３）。この部分は図１４の処理と同様で
ある。ここで、フィールドへの分割と各フィールドの長
さの指定は逆の順序で行なってもよい。更に全データレ
コードについて、それぞれのフィールドをユーザ指定の
フィールド長と比べ、ユーザ指定よりも長い場合は、は
み出した部分をＭＤＤＢ３にロードしない設定にし（ス
テップＳ５４）、ユーザ指定より短い場合は、もとのデ
ータフィールドの後ろに空白文字を詰めて、ユーザ指定
の長さと同じになるようにする（ステップＳ５５）。ま
た、データ処理装置７はこれらの処理と合わせて、各フ
ィールドの値を記録していく。

【００６３】ここで例えば、空白文字の代わりにユーザ
が詰めるべき文字をあらかじめ設定しておく仕組みを提
供してもよい。また、はみ出した場合はその時点でデー
タロードの作業を中止するような設定を可能にしてもよ
い。ここでは処理を続行するものとして説明を続ける。
全てのデータレコードについて、上記の作業を終了した
ら、編集した後のデータレコード群のカラムをロード先
の次元として定義する。このとき、ユーザが各次元につ
いて提示された値一覧をもとに階層構造をその場で対話
的に定義する方法を提供してもよい。この機能を提供し
ない場合は、各フィールドの値を記録するのをやめるよ
う設定できるようにしてもよい。

【００６４】また、各フィールドの値を記録する場合で
も、各次元のとり得る要素数の上限や値についての条件
をユーザがあらかじめ設定できるようにしておいてよ
い。上限を上回る要素を検出したときの処理も図１４の
場合と同様である。この後、生成した次元の定義の順序
に従ってロード対象となるフ ィールド群をソート装置
８によりソートし、データレコードの編集および並べ替
えを行ない、ロード先ＭＤＤＢ３にデータをロードする
（ステップＳ５６）。

【００６５】第３の方針は、データレコードのうち可変
長のフィールドの長さを、全レコードの当該フィールド
の中で最も長いもの、または最も短いものに合わせる方
法がある。図１６に、最も長いフィールドに合わせる処
理の様子を示す。

【００６６】図１６において、ロード元のデータをデー
タ処理装置７に入力し（ステップＳ６１）、ユーザの指
定した区切り文字をもとに各データレコードをフィール
ドに分割する（ステップＳ６２）。そして、各データレ
コードにおける可変長の各フィールドについて、最も長
いものの長さを調べる（ステップＳ６３）。あとの処理
は、図１５の説明においてユーザ指定の長さと同じ長さ
か、ユーザ指定の長さより短いフィールドに対して行な
う処理と同様の処理を行なう（ステップＳ６４）。ただ
し図１５におけるユーザ指定の長さは、図１６において
は全レコードの当該フィールドにおける最長のものの長
さに対応する。

【００６７】図１６において、各データレコードのフィ
ールドの中で「最長」のフィールドを探す過程を「最
短」のフィールドを探す過程に置き換え、更にそれぞれ
のフィールドの編集の過程を図１５におけるユーザ指定
の長さより長いフィールドの編集の過程に置き換える
と、最も短いフィールドに他のレコードのフィールドを
合わせる実現方法になる。この後、図１６のステップに
おいては、生成した次元の定義の順序に従ってロード対
象となるフィールド群をソート装置８によりソートし、
データレコードの編集および並べ替えを行ない、ロード
先ＭＤＤＢ３にデータをロードする（ステップＳ６
５）。

【００６８】なお、必ずしも図１３のようにフィールド
の編集方針を３つ備えている必要はない。データベース
設計の方針によっては、図１４または図１５または図１
６の方法の１つあるいはいずれか２つの組み合わせを備
えることにより実現してもよい。その際、当該方法では
ＭＤＤＢにデータをロードできないようなデータレコー
ド群においては、ロードできないことが分かった時点で
処理を中止するようにしてもよい。ロード先のＭＤＤＢ
３の次元の定義の順序の決め方、およびデータレコード
中のフィールドの個数についての制限またはロードすべ
きフィールドの選び方については、実施の形態３と同様
である。

【００６９】実施の形態５．この発明の実施の形態５に
おいては、データ構造に関する付加情報を持たないデー
タレコード群から自動的にフィールドを抽出する際、ロ
ード先のＭＤＤＢ３で既に別のデータについて適用され
ているデータ定義を参照し、次元の要素の値をロード元
のデータと比較して、再利用可能なデータ定義を適用す
るものである。これは例えば地名や年月日など、頻繁に
利用される次元の階層構造をあらためて定義することな
く新しいデータベースに適用することを可能にするもの
である。

【００７０】処理フローを図１７に従って説明する。フ
ィールドの区切り文字を指定し（ステップＳ７１）、デ
ータ値を含むカラムを指定する（ステップＳ７２）。そ
して、ロード元データをデータ処理装置にロードする
（ステップＳ７３）。続いて、ロード先のＭＤＤＢ３で
既に存在するデータ定義をロードする。このときロード
するデータ定義は、ロード元のデータ定義に対応する、
しないには関係なく、例えばロード先のＭＤＤＢ３にあ
る全てのデータ定義をロードしてもよい。また、データ
ベース設計の方針によっては、例えばユーザが対話的に
参照すべきデータ定義を指定する仕組みを提供してもよ
く、また例えば利用するデータ定義の種類をあらかじめ
データ処理装置に登録しておくような仕組みを提供して
もよい。ここでは、ロード先のＭＤＤＢ３にある全ての
データ定義をロードするものとして説明を続ける。

【００７１】さらに、ユーザの入力した区切り文字に従
って各データレコードをフィールドに分割する（ステッ
プＳ７４）。そして、データ処理装置７は、それぞれの
カラムについて、そのカラムに属するフィールド群が同
一の特定の次元の要素となっているかどうかを調べる
（ステップＳ７５）。ある次元について、全てのレコー
ドでそのカラムに属するフィールドの値がその次元の要
素であったら、そのカラムはロード先のＭＤＤＢ３でそ
の次元の定義を適用してよい（ステップＳ７６）。

【００７２】あるカラムにおいて、１つでもその次元に
属さないフィールドがあったら、そのカラムに対してそ
の次元の定義を適用することはできない。このとき、図
１７では当該フィールドをＭＤＤＢにロードしないが
（ステップＳ７７）、これはデータベース実現の方針に
よる。例えばユーザがそのカラムに対して対話的に次元
を定義する機能を提供してもよく、また例えば、自動的
に階層構造を持たない次元をそのカラムに対して定義し
てもよい。データ処理装置７は、全てのカラムについ
て、適用可能な次元があるかどうかを調べる。このと
き、図１７では各カラムについて全レコードを調べる
が、各レコードについて全てのカラムを並行して調べる
ようにしてもよい。

【００７３】また、図１７では、ロード先のＭＤＤＢ３
にある全ての次元定義を参照するが、これもデータベー
ス実現の方針による。例えば、「地名」や「年月日」な
ど頻繁に使う次元定義だけをあらかじめデータ処理装置
７に登録し、ＭＤＤＢ３から参照するようにしてよい。
この後、図１７のステップＳ７８においては、生成した
次元の定義の順序に従ってロード対象となるフィールド
群をソート装置８によりソートし、データレコードの編
集および並べ替えを行ない、ロード先ＭＤＤＢ３にデー
タをロードする。

【００７４】実施の形態６．この発明の実施の形態６に
おいては、ロードするデータの最終形態をフラットとす
べきかキューブとすべきかを自動的に判定し、より効率
的にＭＤＤＢ３にデータをロードすることを可能にする
ものである。

【００７５】「キューブ」とは、データの各次元におけ
る分類ごとの集計値を全て含むデータの形態であり、
「フラット」とは集計値を含まないデータの形態であ
る。図３〜図７のＭＤＤＢの例で用いたデータを使って
キューブを構成する場合は、図３の縦軸の「全国」「地
方（関東、中部、近畿、九州）」「都市（東京、鎌倉な
ど）」を１つの次元（場所の次元）の階層とし、また図
７の縦軸の「製品合計」「製品分類（家電、コンピュー
タ、ＡＶ）」「製品名（洗濯機、冷蔵庫など）」の売上
高をもう一つの次元（製品の次元）の階層とし、図３の
横軸の時間の全てについて、それぞれの場所と製品のそ
の時期の売り上げを計算し、また場所と製品の次元の階
層のレベルのそれぞれについて売り上げを計算した結果
を保持するデータを生成する。ここで、図７の縦軸の情
報は図３〜６では明示的に示されていないが、ＭＤＤＢ
内部では図３〜６の画面の垂直方向にある仮想的な軸と
して実現されている。また、時間については、例えば
「１９９６年１月１日」の売り上げは年のレベル（「１
９９６年」）、月のレベル（「１９９６年１月」）、日
のレベル（「１９９６年１月１日」）という階層構造を
自然に持っている。データベース実現の方針によって
は、キューブ形式のデータを生成するためには、この階
層構造についてもそれぞれのレベルで売り上げを集計す
る必要がある。

【００７６】図２１に、図３〜図７のＭＤＤＢの例にお
ける場所の次元の階層構造を示す。また、図２２に、図
３〜図７のＭＤＤＢの例における製品の次元の階層構造
を示す。ところで、一般にＭＤＤＢでは、ロード元のデ
ータの件数が少ないときは、キューブ形式でデータをロ
ードする場合と、フラット形式でデータをロードしロー
ルアップ処理をＭＤＤＢ内部で行なう場合とで、後者の
方が短い時間で済む場合がある。これは、ＭＤＤＢのデ
ータおよび付加情報（ＧＵＩによるロールアップ操作や
ドリルダウン操作を提供するために使用される情報）が
十分小さいとき、これらのデータ全体がＭＤＤＢシステ
ムを実現するコンピュータの主記憶装置に収まり、十分
高速にロールアップ計算を実現できるようなことがある
からである。

【００７７】本実施の形態におけるデータ処理装置７は
上記のことを利用して、より高速にＭＤＤＢ３にデータ
をロードできるよう、ロードにかかる時間をあらかじめ
予測し、ロードする際のデータの形式をフラット形式の
ままにするか、キューブ形式にするか自動的に判断し、
必要に応じてロード元のデータをもとにキューブ形式の
データを自動的に生成して、ＭＤＤＢ３にデータをロー
ドする。

【００７８】本実施の形態における処理フローを図１８
に示す。まず、ロード先ＭＤＤＢ３のデータ定義を生成
する（ステップＳ８１）。続いて、サンプルデータを用
いてフラット形式およびキューブ形式のサンプルデータ
による多次元データベースへのデータロードの性能測定
を自動的に行なう（ステップＳ８２）。ステップＳ８２
における測定の処理フローを図１９に示す。

【００７９】ここで、測定するサンプルデータの個数お
よびそれぞれのサイズはデータベース設計の方針によっ
てよく、例えばあらかじめデータ処理装置に登録してお
いてよい。また例えば、ユーザが性能測定時に指定する
仕組みを提供してもよい。あるいは例えばデータ処理装
置が乱数を用いて決めてもよい。またサンプルデータの
内容自体もデータベース設計の方針による。例えばあら
かじめデータ処理装置がサンプルデータを全て保持し、
性能測定にあたってＭＤＤＢを実現するコンピュータに
コピーするようにしてよい。また例えば、性能測定にあ
たってデータ処理装置が指定された大きさのサンプルデ
ータを乱数を用いて生成するようにしてもよい。

【００８０】上記に示すような何らかの方法でデータを
生成した後、データ処理装置はまずフラット形式のまま
データをＭＤＤＢにロードし、このステップＳ９１にお
ける処理にかかる時間を測定する。続いて、ＭＤＤＢの
機能を用いてロード後のデータをＭＤＤＢ内部でキュー
ブ形式に変換し、このステップＳ９２における処理にか
かる時間を測定する。このステップＳ９１とステップＳ
９２にかかる時間の合計が、このサンプルデータのサイ
ズにおけるフラット形式のデータのロード時間である。
このとき、データ処理装置はステップＳ９３における処
理において、ステップＳ９１とステップＳ９２にかかる
時間およびフラット形式のデータのサイズを１組の情報
として記録する。

【００８１】データ処理装置７はまた、上記のフラット
形式のデータからキューブ形式のデータを生成し、この
生成のステップＳ９４における処理にかかった時間を測
定する。そして、キューブ形式のデータをＭＤＤＢにロ
ードし、このロードのステップＳ９５における処理にか
かった時間を測定する。このステップＳ９４とステップ
Ｓ９５にかかった合計時間が、このデータのキューブ形
式でのロード全体の時間である。データ処理装置７はス
テップＳ９６における処理において、これらの処理と合
わせて、ステップＳ９４とステップＳ９５の合計時間を
記録し、また、データの値を格納するためのサイズ、次
元の次数、各次元のレベル数および各レベルのメンバー
数、実際に生成したキューブ形式のデータのサイズを記
録する。

【００８２】データ処理装置７はステップＳ９１〜ステ
ップＳ９６の処理を繰り返し、ロードすべきデータのサ
イズとフラット形式、キューブ形式それぞれのロード時
間の関係を求める。キューブ形式でロードする際の最終
的なデータサイズは、ＭＤＤＢへの命令などの付加デー
タを除くと、各次元の階層構造に含まれるメンバー数を
それぞれ加えた値に、データの値の格納に必要なサイズ
をさらに乗じた値になる。図３ 〜図７のＭＤＤＢの例
だと、場所の次元には図２１に示すように８＋４＋１＝
１３、製品の次元は図２２に示すように６＋３＋１＝１
０のメンバーがそれぞれ存在する。このＭＤＤＢについ
てキューブの大きさを計算すると、１３×１０×（月
数）×データの値の格納に必要なサイズ、となる。な
お、時間の次元における自然な階層構造（「年」のレベ
ル、「月」のレベル、「日」のレベル）を考慮する場合
は、時間の次元の階層ごとの要素数も上記の結果に合わ
せて計算する必要がある。

【００８３】データ処理装置は、ステップＳ８２での性
能測定結果をもとに、フラット形式のデータサイズにお
けるロード性能を見積もる。この予測において、サンプ
ルデータで測定しなかったサイズのデータについては、
データサイズならびにステップＳ９３で記録したロード
時間をそれぞれ横軸と縦軸にした平面において測定点の
間は測定点どうしを直線で結んだ部分の値に従うもとの
してよい。これは、データロードにかかる時間がロード
すべきデータのサイズについて単調増加であることによ
る。

【００８４】また、ステップＳ８２での性能測定結果お
よびロード元データのサイズおよびデータ定義をもと
に、ロード元データをキューブ形式に変換したときの変
換処理にかかる時間（ステップＳ８３）および変換後の
データをＭＤＤＢにロードするのにかかる時間を予測す
る（ステップＳ８４）。この予測においては、フラット
形式同様、サンプルデータで測定しなかったサイズのデ
ータについては、データサイズならびにステップＳ９６
で記録したロード時間をそれぞれ横軸と縦軸にした平面
において測定点の間は測定点どうしを直線で結んだ部分
の値に従うものとしてよい。

【００８５】データ処理装置７はロード元データのサイ
ズにおいてフラット形式またはキューブ形式のうちデー
タロード性能の予測値のより短い方の形式でデータをＭ
ＤＤＢ３にロードする（ステップＳ８５）。なお、デー
タ処理装置７の実現の方針によっては、当該データのサ
イズ付近でフラット形式およびキューブ形式のロード性
能に有意な差がないときは、そのサイズ付近でのロード
性能を改めて詳しく測り直す機構を備えてもよい。この
とき、再測定するための性能差の基準はユーザの設定に
任せてよい。このとき例えば、ユーザに再測定するかど
うか対話的に確認してもよく、自動的に再測定を行なう
ようにしてもよい。

【００８６】実施の形態７．この発明の実施の形態７に
おいては、データ処理装置７を定期的に稼働し、ロこの
発明の実施の形態７においては、データ処理装置７を定
期的に稼働し、ロード元のデータが更新されている場合
は必要に応じてロード先のデータ定義を自動的に定義を
再生成し、ロード先のＭＤＤＢ３にデータをロードし直
す。例えば商品寿命の短い製品の売り上げ記録など、頻
繁にデータ定義を更新する必要があるデータベースに多
次元データベースを適用する場合に有効である。

【００８７】本実施の形態におけるデータ処理装置７の
処理フローを図２０に示す。まず、一定時間ごとにロー
ド元のデータをチェックし、前回データ処理装置がチェ
ックした時点以降にデータが変更されているかどうか調
べる（ステップＳ１０１）。これは例えば、ロード元の
データに最終書き換え時刻の情報を付加し、またデータ
処理装置はこのデータをチェックした時刻の情報を記録
し、これらの情報を比較し、ロード元のデータの方が新
しいかどうか調べることにより実現できる。

【００８８】またデータベース設計の方針によっては、
例えばデータ処理装置はデータの追加のみを調査の対象
としてよい。この場合、データの最終書き換え時刻の代
わりにデータのサイズを比較し、データ処理装置が前回
に確認したときよりデータのサイズが大きくなっている
かどうかを調べてもよい。もしデータに変化がないとき
は、データ定義を更新する必要がないので、データ処理
装置はそのデータについてのチェックを終了する。な
お、例えばこのとき、データ処理装置７は必要に応じて
データをチェックした時刻を記録してもよい。もしデー
タが変化している場合、データ処理装置はロード先のＭ
ＤＤＢ３においてこのデータに対応するデータベースの
データ定義を参照する（ステップＳ１０２）。

【００８９】続いてデータ処理装置７は、ロード元の全
てのデータレコードをデータ定義と比較し、各カラムに
ついてそのカラムと対応する次元に属さない値、つまり
その次元における新しい要素が追加されているかどうか
を確かめる（ステップＳ１０３）。もし新しい要素が追
加されている場合は、データ処理装置内部にこの値と対
応する次元を記録する（ステップＳ１０４）。もし追加
されていない場合はこの処理をスキップする。データ処
理装置７は、全てのデータレコードの全てのカラムにつ
いて調べ終わったら、ステップＳ１０４で記録したデー
タを次元の要素として登録し、新たにデータ定義を生成
する（ステップＳ１０５）。もしステップＳ１０４で新
たな要素データの値を検出しなかったときは、データ定
義を更新する必要はない。

【００９０】そして、データ処理装置７は、新たなデー
タ定義に基づきＭＤＤＢ３にデータをロードする（ステ
ップＳ１０６）。このとき、データのチェックを十分頻
繁に行なえば、ユーザは自動的に、新しいデータを対象
に分析を行なう準備をすることができる。この際、ユー
ザはＭＤＤＢによるデータ分析を行なう際、自分で次元
の定義を改めて生成する必要があるかどうか確認した
り、また定義の再生成が必要な場合に次元を自分で定義
し直したりする手間を省くことができる。

【００９１】またこのとき、ＭＤＤＢを管理するコンピ
ュータ本体（図示せず）でなくデータ処理装置７がロー
ド元のデータのチェックを行なうので、ＭＤＤＢを管理
するコンピュータ本体に計算時間の負担をかけることな
く、頻繁にデータ定義を更新することが可能になる。多
次元データベースは主にデータの多角的かつ柔軟な解析
を目的としており、対象となるデータが新しいほど分析
の精度が高くなるので、ＭＤＤＢのユーザにとっては本
実施の形態による装置の導入は大きな分析精度向上をも
たらす。

【００９２】以上述べたように、この発明におけるデー
タ処理装置７は、データ変換およびＭＤＤＢ３へのデー
タロードの性能を予め測定し、試行錯誤によりデータを
最も高速にＭＤＤＢ３へロードする次元の定義順序を探
すように構成し、また、ロードする際のデータの形式を
フラット形式のままにするか、キューブ形式にするか判
断するためロードにかかる時間を予め測定するように構
成したため、サンプルデータによる測定に多少の時間を
要するが、測定後、適正に処理してロードを完了するこ
とにより、合計時間としてみると迅速なデータ処理を実
現することができる。

【００９３】

【発明の効果】この発明によるデータ処理方法は以上の
様に構成されているので、以下に示す効果を奏する。

【００９４】ロード先のデータ定義を参照しロード元の
データを構成する複数の次元の要素の構成順を組み替え
る様に構成したので、データ定義が異なるロード先へも
人手を介することなくロードすることができる。

【００９５】また、構成順を組み替えて測定を繰り返す
ことによりロード時間が最小となる構成順をロード先の
データ定義として生成する様に構成したので、高速にロ
ードすることができる。

【００９６】さらに、ロード元のデータ定義を参照し上
記ロード先のデータ定義を対話的に設定する様に構成し
たので、多次元データベースを効率的に構築することが
できる。

【００９７】また、データをフラット形式で多次元デー
タベースへロードするかキューブ形式のデータを生成し
た後多次元データベースへロードするかを合計時間の少
ない方に決定する様に構成したので、高速にロードする
ことができる。

【００９８】さらにまた、ユーザが指定する区切り文字
を検出することによりデータレコードのフィールドの値
を抽出するように構成したので、データ構造に関する付
加情報を持たない大量のデータからＭＤＤＢのデータ定
義に必要な情報を容易に取り出すことができる。

【００９９】また、可変レコード長のレコードを単位と
するデータレコード群に対してもデータレコードのフィ
ールドの値を抽出するように構成したので、データ形式
にとらわれずに必要な情報を取り出すことができる。

【０１００】さらに、抽出したフィールドの値とロード
先のデータ定義とを比較し利用可能なデータ定義を再利
用するように構成したので、多次元データベースを効率
的に構築することができる。

【０１０１】また、ロード元のデータを定期的に監視し
データの更新を検出したときデータを処理後ロードする
ように構成したので、多次元データベースを常時新規な
データで維持することができる。

【図面の簡単な説明】

【図１】 この発明の実施の形態１のデータ処理装置を
示すシステム構成図である。

【図２】 この発明の実施の形態１のデータ処理方法を
示すフローチャートである。

【図３】 この発明の実施の形態１のＭＤＤＢを示すデ
ータ分析表である。

【図４】 この発明の実施の形態１のＭＤＤＢを示すデ
ータ分析表である。

【図５】 この発明の実施の形態１のＭＤＤＢを示すデ
ータ分析表である。

【図６】 この発明の実施の形態１のＭＤＤＢを示すデ
ータ分析表である。

【図７】 この発明の実施の形態１のＭＤＤＢを示すデ
ータ分析表である。

【図８】 この発明の実施の形態１のロード先ＭＤＤＢ
のデータ表現を示す構成図である。

【図９】 この発明の実施の形態１のロード元データの
データ形式を示す構成図である。

【図１０】 この発明の実施の形態１のデータ処理方法
を示すフローチャートである。

【図１１】 この発明の実施の形態２のデータ処理方法
を示すフローチャートである。

【図１２】 この発明の実施の形態３のデータ処理方法
を示すフローチャートである。

【図１３】 この発明の実施の形態４のデータ処理方法
を示すフローチャートである。

【図１４】 この発明の実施の形態４のデータ処理方法
の第１の方針を示すフローチャートである。

【図１５】 この発明の実施の形態４のデータ処理方法
の第２の方針を示すフローチャートである。

【図１６】 この発明の実施の形態４のデータ処理方法
の第３の方針を示すフローチャートである。

【図１７】 この発明の実施の形態５のデータ処理方法
を示すフローチャートである。

【図１８】 この発明の実施の形態６のデータ処理方法
を示すフローチャートである。

【図１９】 この発明の実施の形態６のデータ処理方法
における性能測定方法を示すフローチャートである。

【図２０】 この発明の実施の形態７のデータ処理方法
を示すフローチャートである。

【図２１】 この発明の実施の形態１〜７のＭＤＤＢに
おける場所の次元の階層構造を示す構成図である。

【図２２】 この発明の実施の形態１〜７のＭＤＤＢに
おける製品の次元の階層構造を示す構成図である。

【図２３】 この発明の実施の形態１〜７のＭＤＤＢに
おけるロード元又はロード先の次元に対応するフィール
ドを探す処理の手順を示す模式図である。

【図２４】 この発明の実施の形態１〜７のロード元デ
ータの構造を示す説明図である。

【図２５】 従来例のデータ処理方法を示すシステム構
成図である。

【符号の説明】

１ 関係データベース、２ 第１の多次元データベース
（ロード元）、３ 第２の多次元データベース（ロード
先）。

【手続補正書】

【提出日】平成９年１２月１７日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図６

【補正方法】変更

【補正内容】

【図６】

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】図７

【補正方法】変更

【補正内容】

【図７】

【手続補正３】

【補正対象書類名】図面

【補正対象項目名】図２２

【補正方法】変更

【補正内容】

【図２２】

Claims (8)

【特許請求の範囲】
1. 【請求項１】 ロード元である関係データベース又は第
   １の多次元データベースからロード先の第２の多次元デ
   ータベースへデータをロードするシステムにおいて、上
   記ロード先のデータ定義を参照し上記データを構成する
   複数の次元の要素の構成順を組み替えるステップ、上記
   各次元の要素順に上記データをソートし上記第２の多次
   元データベースへ上記データをロードするステップから
   なるデータ処理方法。
2. 【請求項２】 ロード元である関係データベース又は第
   １の多次元データベースからロード先の第２の多次元デ
   ータベースへデータをロードするシステムにおいて、上
   記ロード元のデータ定義を参照し上記データを構成する
   複数の次元の要素の構成順を組み替えるステップ、組み
   替えた構成順においてサンプルデータによりロード時間
   を測定するステップ、上記構成順を組み替えて上記測定
   を繰り返すことにより上記ロード時間が最小となる構成
   順を上記ロード先のデータ定義として生成するステッ
   プ、上記ロード先のデータ定義に基づき各次元の要素順
   に上記データをソートし上記第２の多次元データベース
   へ上記データをロードするステップからなるデータ処理
   方法。
3. 【請求項３】 ロード元である関係データベース又は第
   １の多次元データベースからロード先の第２の多次元デ
   ータベースへデータをロードするシステムにおいて、上
   記ロード元のデータ定義を参照し上記ロード先のデータ
   定義を対話的に設定するステップ、設定したデータ定義
   に基づく要素の構成順のサンプルデータによりロード時
   間を測定するステップ、上記構成順を組み替えて上記測
   定を繰り返すことにより上記ロード時間が最小となる構
   成順を上記ロード先のデータ定義として生成するステッ
   プ、上記ロード先のデータ定義に基づき各次元の要素順
   に上記データをソートし上記第２の多次元データベース
   へ上記データをロードするステップからなるデータ処理
   方法。
4. 【請求項４】 ロード元である関係データベース又は第
   １の多次元データベースからロード先の第２の多次元デ
   ータベースへデータをロードするシステムにおいて、フ
   ラット形式のサンプルデータを上記第２の多次元データ
   ベースへロードする第１の時間を測定するステップ、そ
   のフラット形式のサンプルデータを用いて上記第２の多
   次元データベースにおいてキューブ形式のデータを生成
   する第２の時間を測定するステップ、上記フラット形式
   のサンプルデータを用いて上記関係データベース又は第
   １の多次元データベースにおいてキューブ形式のデータ
   を生成する第３の時間を測定するステップ、そのキュー
   ブ形式のデータを上記第２の多次元データベースへロー
   ドする第４の時間を測定するステップ、上記第１の時間
   と上記第２の時間の合計時間と上記第３の時間と上記第
   ４の時間の合計時間とを比較し上記データをフラット形
   式で上記第２の多次元データベースへロードするかキュ
   ーブ形式のデータを生成した後上記第２の多次元データ
   ベースへロードするかを上記合計時間の少ない方に決定
   するステップ、この決定結果に基づき上記第２の多次元
   データベースへ上記データをロードするステップからな
   るデータ処理方法。
5. 【請求項５】 データ構造に関する付加情報を有しない
   データレコード群からユーザが指定する区切り文字を検
   出することにより上記データレコードのフィールドの値
   を抽出するステップ、抽出したフィールドの値に基づく
   要素の構成順のサンプルデータによりロード時間を測定
   するステップ、上記構成順を組み替えて上記測定を繰り
   返すことにより上記ロード時間が最小となる構成順をロ
   ード先のデータ定義として生成するステップ、上記ロー
   ド先のデータ定義に基づき各次元の要素順に上記データ
   をソートし多次元データベースへ上記データをロードす
   るステップからなるデータ処理方法。
6. 【請求項６】 上記データレコード群は可変レコード長
   のレコードを単位とすることを特徴とする請求項５記載
   のデータ処理方法。
7. 【請求項７】 データ構造に関する付加情報を有しない
   データレコード群からユーザが指定する区切り文字を検
   出することにより上記データレコードのフィールドの値
   を抽出するステップ、抽出したフィールドの値とロード
   先のデータ定義とを比較し利用可能なデータ定義を再利
   用することにより新たにロード先のデータ定義を生成す
   るステップ、その新たなデータ定義に基づく要素の構成
   順に上記データレコード群を組み替えるステップ、上記
   新たなデータ定義に基づき各次元の要素順に上記データ
   をソートし多次元データベースへ上記データをロードす
   るステップからなるデータ処理方法。
8. 【請求項８】 ロード元のデータを定期的に監視し上記
   データの更新を検出したとき上記データを適正に処理後
   ロードすることを特徴とする請求項１〜請求項６のいず
   れかに記載のデータ処理方法。