JP2004030221A - 変更対象テーブル自動検出方法 - Google Patents

Abstract

【課題】データモデルなどの雛型が定まったＢＩシステムに対して、ＭＤスキーマに次元の追加などの変更を加える場合に、システム全体の整合性を保つために、カラムの追加などの変更を加えるべきテーブルを特定する。
【解決手段】ＭＤスキーマ定義変更処理により、ＭＤスキーマに対する次元の追加などの変更情報から、カラムの追加などの変更を加えるべきロードテーブルを特定する。そして変更候補テーブル抽出処理により、ロードテーブルの変更に伴い、カラムの追加などの変更を加えるべき全てのテーブルとカラムの組合せを出力する。そして変更対象テーブル決定処理により、変更すべきテーブルの組合せを一組出力する。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、分析システムのカスタマイズ支援技術に関する。特に多次元データベースの分析スキーマの次元を追加、削除、変更した場合に、リレーショナル・データベースの中で、カラムの追加、削除、変更が必要なテーブルをリストアップする方法に関する。
【０００２】
【従来の技術】
近年、コンピュータ機器と、磁気カード、ＩＣカードが一般社会に普及し、百貨店、専門店、家電量販店、スーパーマーケットなど、幅広い業種において、ハウスカードにより、氏名、住所などの顧客の属性データや、購買履歴を蓄積、管理する情報系システム（データウェアハウス）の構築が可能になった。そして最近では、構築されたデータウェアハウスを、企業の戦略立案に利用するビジネスインテリジェンス・ソリューションが注目されている。
【０００３】
ビジネスインテリジェンスとは、収集、格納、分析したデータに、企業人が利用できるようにすることにより、よりよい意思決定を支援するアプリケーションと技術の総称である。そして、ビジネスインテリジェンス・アプリケーションには、意思決定システム、問い合わせ、レポーティング、ＯＬＡＰ（Ｏｎ　Ｌｉｎｅ　Ａｎａｌｙｔｉｃａｌ　Ｐｒｏｃｅｓｓｉｎｇ）、統計解析、予測、データマイニングが含まれる。
【０００４】
ビジネスインテリジェンス・アプリケーションは、リレーショナル・データベース（ＲＤＢ：Ｒｅｌａｔｉｏｎａｌ　Ｄａｔａｂａｓｅ）と、多次元データベース（ＯＬＡＰ）を併用した構成がよく知られているが、ＯＬＡＰでは、多次元データベース（ＭＤＢ：Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ　Ｄａｔａｂａｓｅ）の構造をＭＤスキーマ（Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ　ｓｃｈｅｍａ）によって記述している。
【０００５】
また、これら情報系システムの構築期間の短期化傾向が強まっている。構築期間を短縮するために、以下のような製品及び技術が知られている。
【０００６】
１つは、業種・業務別のパッケージの提供である。例えば、ＩＢＭ社のＳｔａｒｔＮｏｗ　ｆｏｒ　Ｒｅｌａｔｉｏｎｓｈｉｐ　Ｍａｒｋｅｔｉｎｇは、ＣＲＭ（Ｃｕｓｔｏｍｅｒ　Ｒｅｌａｔｉｏｎｓｈｉｐ　Ｍａｎａｇｅｍｅｎｔ）に特化したハードウェア、ソフトウェア、分析モデル、業種別導入支援サービスを一体として提供している。（ＳｔａｒｔＮｏｗ　ｆｏｒ　Ｒｅｌａｔｉｏｎｓｈｉｐ　ＭａｒｋｅｔｉｎｇはＩＢＭ社の登録商標である。）（従来技術１）
他方は、データウェアハウス構築支援ツールの提供である。Ｉｎｆｏｃｏｍ社が提供しているＲｅｄＢｒｉｃｋ　Ｗａｒｅｈｏｕｓｅは、データウェアハウス構築専門のデータベースである。データウェアハウスの設計、構築を支援するＲｅｄ　Ｂｒｉｃｋ　Ｗａｒｅｈｏｕｓｅ　Ａｄｍｉｎｉｓｔｒａｔｏｒと呼ばれるツールを提供している。Ｒｅｄ　Ｂｒｉｃｋ　Ｗａｒｅｈｏｕｓｅ　Ａｄｍｉｎｉｓｔｒａｔｏｒは、データウェアハウスを構成するＲＤＢテーブル間の関係を定義するＧＵＩや、必要なディスク容量の概算を算出するＧＵＩを提供している。（ＲｅｄＢｒｉｃｋ　Ｗａｒｅｈｏｕｓｅ及びＲｅｄ　Ｂｒｉｃｋ　Ｗａｒｅｈｏｕｓｅ　ＡｄｍｉｎｉｓｔｒａｔｏｒはＩｎｆｏｃｏｍ社の登録商標である。）
また、Ｏｒａｃｌｅ社は、データウェアハウスの設計、実装、管理をするＯｒａｃｌｅ　Ｗａｒｅｈｏｕｓｅ　Ｂｕｉｌｄｅｒ（ＯＷＢ）を提供している。Ｏｒａｃｌｅ　Ｗａｒｅｈｏｕｓｅ　Ｂｕｉｌｄｅｒ（ＯＷＢ）はＯｒａｃｌｅ社の登録商標である。ＯＷＢを利用すると、ＧＵＩにより、ＲＤＢテーブル、ＭＤスキーマ、ＥＴＬジョブの設計が可能である。（従来技術２）
【０００７】
【発明が解決しようとする課題】
上記従来技術１は、パッケージの適用により、導入期間を短縮するものである。顧客がパッケージの分析モデルをそのまま適用するならば、３ヶ月以内の構築も可能であろう。ただし、データウェアハウス及びＢＩ（Ｂｕｓｉｎｅｓｓ　Ｉｎｔｅｌｌｉｇｅｎｃｅ）システムは、戦略策定、意思決定を支援するシステムであり、自社の特徴を活かした他社システムとの差別化、すなわちカスタマイズが必須である。このような事情により、自社の特徴を活かしたＢＩシステムを構築するには、パッケージの適用のみでは、構築期間を短縮することはできない。
【０００８】
上記従来技術２は、構築支援ツールによりデータウェアハウスの設計、実装を支援するものであり、パッケージのような既存のモデルのカスタマイズを支援し、構築期間を短縮するものではない。即ち、既存のモデルの中のあるテーブルの項目名を変更するような場合に、他のテーブルの中にも変更すべき項目が存在するかどうか、または変更すべきテーブル及び項目を抽出することはできない。
【０００９】
上記従来技術の問題点を鑑み、本発明の目的は、リレーショナル・データベースと多次元データベースを併用したデータウェアハウス、およびＢＩシステムにいて、多次元データベースにより実装された分析システム（ＭＤスキーマ）に新たな次元を加えた場合に、リレーショナル・データベースの中で、カラムを追加すべきテーブルをリストアップすることである。
【００１０】
【課題を解決するための手段】
本発明の目的を達成するため、本発明の変更対象テーブル自動検出方法では、ＭＤスキーマ定義変更処理により、ＭＤスキーマの中で変更すべきファイルとその変更方法をリストアップし、リレーショナル・データベースの中で、カラムを追加すべきロード元テーブルを特定する。ここで、ロード元テーブルとは、ＲＤＢテーブルの中で、直接ＭＤＢに読み込むテーブルである。そして、変更候補テーブル抽出処理により、テーブル間の処理を記述したテーブル関連情報に基づいて、変更対象となるロードテーブルから、その生成元となるテーブルを順に辿ることにより、全ての変更候補となるテーブルの組合せをリストアップする。
【００１１】
そして、変更対象テーブル決定処理により、全ての変更候補であるテーブルの組合せの中から、変更すべきレコードの数の総和が最小となるテーブルの組合せを出力する。
【００１２】
【発明の実施の形態】
図面を用いて本発明の実施の形態について説明する。
【００１３】
この実施形態が対象とする分析システム及び、本発明の変更対象テーブル検出処理を構成する処理と、これらの間のデータの流れを図１に示す。
【００１４】
本実施形態では、リレーショナル・データベースと多次元データベースを併用した分析システムに対して、特定のＭＤスキーマに新たな次元を追加した場合に、ＭＤスキーマ及びＲＤＢスキーマの定義ファイルの変更箇所と変更処理をリストアップする。
【００１５】
本実施形態は、以下の処理から構成される。
１）ＭＤスキーマ定義変更処理１０２：ＭＤスキーマに追加する次元を特定する次元追加情報１０１を入力して、ＭＤスキーマの定義ファイルを変更し、次元を追加すべきＭＤスキーマにロードするＲＤＢテーブルの定義ファイルに対するカラム追加情報１０３を出力する。
【００１６】
２）変更候補テーブル抽出処理１０５：カラム追加情報１０３と、明細テーブルやマスタテーブルなどからＭＤスキーマにロードするテーブルを生成するまでの、テーブル間の処理を記述したテーブル関連情報１０４を入力し、テーブル関連情報１０４を、変更対象となるロードテーブルから、その生成元となるテーブルを順に辿ることにより、全ての変更候補となるテーブルの組合せをリストアップし、変更候補テーブル情報１０６として出力する。
【００１７】
３）変更対象テーブル決定処理１０７：変更候補テーブル情報１０６と、テーブル別レコード数情報１０８を入力して、全ての変更候補となるテーブルの組合せについて、レコードの総数を計算し、レコードの総数が最小の組合せをテーブル定義変更情報１０９として出力する。
【００１８】
図１に示す分析システムは、図２に示すような定義ファイルにより定義されている。リレーショナル・データベース（ＲＤＢ）により実装されている部分と、多次元データベース（ＭＤＢ）により実装されている部分では、その定義方法も異なる。ＭＤスキーマに新たな次元を追加する場合には、図２に示すテーブル定義ファイル２０１、スキーマ構成次元定義ファイル２０２、次元定義ファイル２０３、階層定義ファイル２０４、マッピング情報ファイル２０５を修正、または追加することになる。本発明は、上記のファイルの中で、具体的に修正すべきファイルとその変更処理を特定することを目的とする。
【００１９】
ＭＤＢのスキーマ定義は、スキーマ構成次元定義ファイル２０２、次元定義ファイル２０３、階層定義ファイル２０４、マッピング情報ファイル２０５から構成される。
【００２０】
スキーマ構成次元定義ファイル２０２には、各ＭＤスキーマを構成する次元が定義される。ＭＤスキーマごとに１ファイルとなる。１行目にＭＤスキーマ名称、２行目以降にＭＤスキーマを構成する次元名称と次元属性が記述される。次元属性によって、各次元がキー次元、分析次元のいずれであるかを示す。例えば、図２において、ＭＤスキーマ属性分析は、年月次元、年齢次元、性別次元、趣味次元などから構成される。
【００２１】
次元定義ファイル２０３には、各次元に対応する階層名称が定義される。次元ごとに１ファイルを構成し、各ファイルの１行目に次元名称、２行目に階層名称が記述される。
【００２２】
具体的な階層の構成要素は、階層定義ファイル２０４に定義される。各階層を構成する要素をメンバと呼ぶ。各次元の値は、ここに定義されたメンバのいずれかの値を取る。各階層には、１行目に階層名称、２行目以降に、各階層を構成するメンバが記述され、最下位のメンバを含む全てのメンバが記述される。最下位メンバは、その全ての親メンバと共に記述する。例えば、図２に示す年月階層は、２階層であり、「２０００年度」は、「２０００／４」及び「２０００／５」の親メンバである。
【００２３】
すなわち、スキーマ構成次元定義ファイル２０２には、各スキーマを構成する次元が記述されている。階層定義ファイル２０４には、階層を構成するメンバが定義されている。次元定義ファイル２０３には、スキーマを構成する各次元と階層の対応が定義されている。よって、スキーマ構成次元定義ファイル２０２、次元定義ファイル２０３、階層定義ファイル２０４により、ＭＤスキーマを定義できる。
【００２４】
マッピング情報ファイル２０５には、ＭＤスキーマにロードするテーブルと、そのテーブルのカラムと、ＭＤスキーマの次元の対応付けを定義する。ＭＤスキーマごとに１ファイルを構成する。図２に示す例では、１行目にＭＤスキーマ名称、３行目にロード元のテーブル名称、５行目以降にロードテーブルのカラムと、ＭＤスキーマの次元の対応が記述されている。
【００２５】
ＲＤＢのスキーマ定義は、テーブル定義ファイルに記述される。１テーブルが１ファイルに記述される。図２に示すとおり、１行目がテーブル名称、２行目以降が、各テーブルを構成するカラムの情報である。各行がカラムに該当し、カラム名称と、データ型が一組を構成する。
マッピング情報ファイル２０５に記述されるロードテーブルの定義は、必ずテーブル定義ファイルのいずれかに含まれる。
【００２６】
図１に示す分析システムにおいて、多次元データベースにより実装された属性分析スキーマに「趣味」をキー次元として追加する場合を例として、本発明の変更対象テーブル検出処理を説明する。
【００２７】
本発明の変更対象テーブル検出処理によれば、ＭＤスキーマに軸を追加した場合に、整合性を保つために、リレーショナル・データベースにより実装されたテーブルの中で、カラムを追加すべきテーブルをリストアップする。また、追加すべきテーブルの組合せが２通り以上ある場合には、全ての組合せの中で、変更するテーブルのレコード数の総和が最小、すなわち、必要なディスク容量が最小になる組合せをリストアップする。
【００２８】
以下、変更対象テーブル検出処理を構成する各処理について説明する。
【００２９】
まず、ＭＤスキーマ定義変更処理１０２について説明する。
【００３０】
ＭＤスキーマ定義変更処理１０２は、次元追加情報１０１で指定された次元を、スキーマの定義情報であるスキーマ構成次元定義ファイル２０２に追加し、指定された次元に関する次元定義ファイル２０３と階層定義ファイル２０４を生成する。また、次元を追加するスキーマのマッピング情報ファイル２０５に追加する次元とロードテーブルのカラムの対応情報を追加する。さらに当該のＭＤスキーマのロードテーブルに追加するカラムの情報を、カラム追加情報１０３として出力する。ここで、ロードテーブルとは、図１に示すとおり、ＭＤＢに読み込ませるテーブルである。
【００３１】
次元追加情報１０１には、どのＭＤスキーマに、どのような名称のＭＤスキーマを追加するのかが記述されている。次元追加情報１０１は、図１に示すように、Ｎｏ．、ＭＤスキーマ名、次元名、変更処理により構成される。例えば、図１に示す変更処理である、Ａｄｄ＿ｄｉｍｅｎｓｉｏｎ（趣味，ｃｈａｒ（２０））は、ＭＤスキーマに趣味次元を追加し、趣味の各メンバはｃｈａｒ型で、最大２０文字であることを示す。
【００３２】
カラム追加情報１０３は、Ｎｏ．、テーブル名、カラム名、変更処理から構成される。次元追加情報１０１と同様に、１行目がカラム名、２行目以降がデータである。図１に表示しているカラム追加情報１０３は、データ型がｃｈａｒ型であり、最大２０文字の処理カラムを属性ロードテーブルに追加することを意味する。
【００３３】
図３に、ＭＤスキーマ定義変更処理１０２のフローチャートを示す。
【００３４】
ステップ３０１では、スキーマ構成次元ファイル２０２の中から、１行目のＭＤスキーマ名称が次元追加情報１０１に指定されたＭＤスキーマ名と一致するファイルを検索する。
【００３５】
ステップ３０２では、検索されたスキーマ構成次元ファイル２０２に、次元追加情報１０１に指定された次元を追加する。ここで、次元の名称は、次元追加情報１０１に指定された次元名に「次元」を加えたものである。例えば、属性分析に趣味次元を追加した場合、図２に示すように、属性分析のスキーマ構成次元定義ファイルに「趣味次元，キー」が追加される。ここで、趣味次元がキー次元であることは、次元追加情報１０１の変更処理において、趣味のデータ型がｃｈａｒ型であることから判断される。
【００３６】
ステップ３０３では、次元情報１０１に指定された次元に関する次元定義ファイル２０２を生成する。ここで、次元名称は、スキーマ構成次元定義ファイル２０２に追加した次元名称と同一であり、階層名称は、次元の名称から「次元」を取り除き、「階層」を加えたものである。
【００３７】
ステップ３０４では、新たに生成した次元定義ファイル２０２に指定した階層の階層定義ファイル２０４を生成する。新たに追加する趣味次元に関して、図２に示すようなフォーマットを有する階層定義ファイル２０４が用意されるものとする。
【００３８】
ステップ３０５では、マッピング情報ファイル２０５の中から、１行目のＭＤスキーマ名称が、次元追加情報１０１に指定されたＭＤスキーマ名称と一致するファイルを検索する。
【００３９】
ステップ３０６では、検索したマッピング情報ファイルに、次元追加情報１０１に指定された次元を追加する。ここで、マッピング情報ファイル２０５には、ロードテーブルのカラム名と次元名称を組にして格納するが、ロードテーブルのカラム名は、次元追加情報１０１に記述された次元名である。
【００４０】
ステップ３０７では、処理３０６にて検索したマッピング情報ファイルからカラム追加情報１０３を生成する。カラム追加情報１０３は、Ｎｏ．、テーブル名、カラム名、変更処理から構成される。Ｎｏ．はレコードを特定する番号であり、１、２、３、．．と昇順に整数値を代入する。テーブル名は、カラムを追加するテーブル名であり、ステップ３０６にて検索したマッピング情報ファイル２０５の中のロードテーブル名を代入する。また、ステップ３０６にて追加したカラム名を、カラム追加情報１０３のカラム名に代入する。変更処理にはＡｄｄ＿ｃｏｌｕｍｎを設定し、括弧内の引数は、次元追加情報１０１の変更処理の引数を代入する。
【００４１】
変更候補テーブル抽出処理１０５について説明する。変更候補テーブル抽出処理１０５は、ＭＤスキーマ定義変更処理１０２から出力されるカラム追加情報１０３を元に、テーブル関連情報１０４を用いて、カラムを追加すべきテーブルの組合せを全てリストアップし、変更候補テーブル情報１０６として出力する。
【００４２】
図１に示す通り、テーブル関連情報１０４は、まず「Ｆｒｏｍ」カラム、「Ｔｏ」カラム、「処理」カラムから構成される。「Ｆｒｏｍ」カラムは、さらにテーブル名、カラム名の二つのカラムから構成される。「Ｔｏ」カラムも同様に、スキーマ名、カラム名の二つのカラムから構成される。つまり、１行目、２行目がカラム名であり、３行目以降にデータが格納される。「Ｆｒｏｍ」カラムのスキーマ名、カラム名のデータに対し、同一レコードに示す処理を施すことにより、「Ｔｏ」カラムのスキーマ名、カラム名のデータが作成される。例えば、テーブル関連情報１０４の３行目のレコードは、購入実績サマリのカラム「顧客ＩＤ」は、買上明細のカラム「顧客ＩＤ」にｇｒｏｕｐ処理を施すことにより生成されることが定義されている。ここでｇｒｏｕｐ処理とは、「顧客ＩＤ」が同一のレコードを１つに集約することを意味する。
【００４３】
変更候補テーブル情報１０６は、一行目がカラム名、二行目以降がデータである。変更候補テーブル情報１０６のカラムは、カラム追加情報１０３のカラムに、関連Ｎｏ．カラムと終了フラグカラムを追加したものであり、カラム追加情報１０３と同様に、各レコードが、一つの表に対する一つのカラムの追加を表す。ここで関連Ｎｏ．とは、変更候補テーブル情報１０６の中で、当該の変更をおこなう要因となった変更処理のＮｏ．を示す。終了フラグカラムは、他のテーブルの変更の要因になるか否かを示し、他のテーブルの変更の要因になる場合には０、ならない場合には１に設定する。
【００４４】
次に、変更候補テーブル抽出処理１０５の処理フローについて説明する。図４にフローチャートを示す。
【００４５】
ステップ４０１では、カラム追加情報１０３のレコードを、変更候補テーブル情報１０６の該当するカラムにコピーする。関連Ｎｏ．及び終了フラグは０に設定する。
【００４６】
ステップ４０２では、変更候補テーブルの中のレコードを特定する変数ｐを０に初期化する。
【００４７】
ステップ４０３では、変更候補テーブルのレコードの中で、ステップ４０４以降の処理をおこなっていないレコードが存在するか否か確認する。全てのレコードについて、ステップ４０４以降の処理を実行している場合には終了し、そうでない場合には、ステップ４０４に進む。
【００４８】
ステップ４０４では、変数ｐに１を加え、ｐ番目のレコードを関連調査レコードとして選択する。例えば、Ｎｏ．＝１、テーブル名＝属性ロードテーブル、カラム名＝趣味、変更処理＝Ａｄｄ＿ｃｏｌｕｍｎ（趣味，ｃｈａｒ（２０））、関連Ｎｏ．＝０、終了フラグ＝０のレコードを、関連調査レコードとして選択したとする。
【００４９】
ステップ４０５では、テーブル関連情報１０４の中から、Ｔｏフィールドのテーブル名が関連調査レコードと一致するレコードを検索し、一致したレコードが検索できた場合には、ステップ４０６に進む。一致するレコードが検索できなかった場合には、ステップ４０７に進む。ここでは、テーブル関連情報１０４の２番目のレコードが検索されるので、ステップ４０６に進む。
【００５０】
ステップ４０６では、関連テーブルレコードを生成する。ここで、関連テーブルレコードとは、検索したレコードのＦｒｏｍフィールドのテーブルに関連調査レコードのカラム名を追加することを指し示す。これは、変更候補テーブルに対する入力候補レコードである。レコードは、テーブル名、カラム名、変更処理から構成される。ここでは、（顧客属性，趣味，Ａｄｄ＿ｃｏｌｕｍｎ（趣味，ｃｈａｒ（２０）））が、関連テーブルレコードとなる。
【００５１】
ステップ４０８では、関連テーブルレコードと同一レコードが変更候補テーブル情報１０６に存在するか否かを確認する。存在しない場合には、ステップ４０９に進み、存在する場合には、ステップ４０５に戻る。
【００５２】
ステップ４０９では、関連テーブルレコードを、変更候補テーブル情報１０６に追加する。ここで、関連Ｎｏ．は、当該の変更をおこなう要因となった変更処理のＮｏ．であるから、関連Ｎｏ．には関連調査レコードのＮｏ．を設定する。終了フラグには０を設定する。また、Ｎｏ．は、１、２、３、…と順に整数値を設定する。ここでは、追加されるレコードは、（２，顧客属性，趣味，Ａｄｄ＿ｃｏｌｕｍｎ（趣味，ｃｈａｒ（２０），１，０））となる。
【００５３】
ステップ４１０では、選択している関連調査レコードをキーとして、テーブル関連情報の全てのレコードを検索したか否かを確認する。全て検索している場合には、ステップ４０３に戻る。全て検索していない場合は、ステップ４０５に戻る。ここでは、選択している関連調査レコードをキーとして、テーブル関連情報の全てのレコードを検索したものとする。この場合、ステップ４０３に戻る。ステップ４０９で追加したＮｏ．＝２のレコードが存在するため、ステップ４０４に進みステップ４０４にてこのレコードが選択される。ステップ４０５において、テーブル関連情報１０４の中に、Ｔｏカラムのテーブル名が顧客属性であるレコードが存在しないため、ステップ４０７に進む。
【００５４】
ステップ４０７は、関連調査レコードの終了フラグカラムの値を１に設定する。ここでは、関連調査レコードが、（２，顧客属性，趣味，Ａｄｄ＿ｃｏｌｕｍｎ（趣味，ｃｈａｒ（２０），１，１））に更新される。
【００５５】
引き続き、変更対象テーブル決定処理１０７について説明する。変更対象テーブル決定処理１０７は、変更候補テーブル情報１０６の中から、必要最小限の変更を特定する情報のみを抽出し、テーブル定義変更情報１０９として出力する。変更候補テーブル情報１０６には、定義を変更するテーブルの組合せが２通り以上含まれる場合もある。テーブル定義変更情報１０９には、必要最小限の変更で対応できるテーブルの組合せのみが格納される。
【００５６】
テーブルの組合せを選択する基準としては、変更するテーブルのレコード数の総和を利用する。変更するテーブルのレコード数の総和が最小になる組合せを選択する。変更するテーブルのレコード数の総和が最小になることは、新たに必要になるディスク容量が最小になることを意味する。
【００５７】
図５に変更対象テーブル決定処理１０７のフローチャートを示す。
【００５８】
ステップ５０１では、変更レコード総数Ｎを０に初期化し、最小変更レコード数ＮｍｉｎをＮｍａｘに初期化する。ここで変更レコード総数とは、カラム追加情報１０３の各レコードと関連する一連のテーブルのレコード数の総和である。Ｎｍｉｎは、変更レコード総数の最小値である。Ｎｍａｘは、テーブル別レコード数１０８の全テーブルのレコード数の総和に１を加えた値である。例えば、Ｎｍｉｎ＝Ｎｍａｘ＝３０，０００，０００に設定したと仮定する。
【００５９】
ステップ５０２では、変更候補テーブルの中で、終了フラグの値が１であるレコードを検索し、見つかった場合には、ステップ５０３に進む。見つからなかった場合には、ステップ５０７に進む。ここでは、Ｎｏ．＝２のレコードを検索し、ステップ５０３に進む。
【００６０】
ステップ５０３では、ステップ５０２又はステップ５０４にて検索したテーブルのレコード数を、テーブル別レコード数１０８を参照し、算出する。算出した結果をｎに格納する。また、変更レコード総数Ｎにｎを加える。ここでは、ｎ、Ｎ共に１，２００，０００となる。
【００６１】
ステップ５０４では、ステップ５０３において、変更レコード数ｎを算出したレコードの関連Ｎｏ．と一致するレコードを、変更候補テーブル１０６の中から検索する。レコードが検索された場合には、ステップ５０３に戻る。関連Ｎｏ．が０である場合には、ステップ５０５に進む。ここでは、Ｎｏ．＝１のレコードが検索されるため、ステップ５０３に戻る。ステップ５０３では、ｎ＝１００，０００となり、
Ｎ＝１，２００，０００＋１００，０００＝１，３００，０００
となる。再びステップ５０４に進むと、関連Ｎｏ．が０であるため、ステップ５０５に進む。
【００６２】
ステップ５０５では、変更レコード総数ＮがＮｍｉｎよりも小さいか否か検証する。つまり、現在調査しているテーブルの組合せが、それまでに調べたテーブルの組合せのいずれよりも、レコード総数が少ないか否かを検証する。変更レコード総数ＮがＮｍｉｎよりも小さい場合には、ステップ５０６に進む。そうでない場合には、ステップ５０２に戻り、新たなテーブルの組合せについて調べる。Ｎ＝１，３００，０００、Ｎｍｉｎ＝３，０００，０００であるため、Ｎｍｉｎ＝１，３００，０００となる。
【００６３】
Ｎｍｉｎの初期値はＮｍａｘであるため、最初にステップ５０５を実行する場合には、必ずステップ５０６に進み、Ｎｍｉｎの値はＮに更新される。
【００６４】
ステップ５０７では、変更候補テーブル情報１０６の中から、変更レコード総数Ｎが最小となったテーブルの組合せ以外のレコードを削除し、テーブル定義変更情報１０９として出力する。
【００６５】
以上の実施例は以下のように変更して実施することも可能である。
【００６６】
第１に、ＭＤスキーマのある次元を削除する場合に、整合性を保つために、リレーショナル・データベースにより実装されたデータモデルの中で、カラムを削除すべきテーブルをリストアップする。
【００６７】
削除する次元の情報は、次元追加情報１０１と同様のフォーマットで記述される。例えば、趣味次元を削除する場合には、変更処理にはＤｒｏｐ＿ｄｉｍｅｎｓｉｏｎ（趣味）と記述される。データベースにより実装されたデータモデルの中で、カラムを削除すべきテーブルを特定するプロセスは、先の実施例で示した変更対象テーブル検出処理とほぼ同様である。ただし、変更候補テーブル抽出処理１０５を次のように変更する。
【００６８】
ステップ４０５において、テーブル関連情報の中から、Ｔｏフィールドのテーブル名とカラム名が、関連調査レコードと一致するレコードを検索する。
【００６９】
ステップ４０６は、検索したレコードのＦｒｏｍフィールドのテーブル及びカラムを関連テーブルレコードに設定する。
【００７０】
カラム削除時には、変更候補テーブル抽出処理１０５をおこなった後に、図６に示す変更対象カラム決定処理をおこなう。変更対象カラム決定処理において、削除するカラムが、他のＭＤスキーマの生成元となるテーブルのカラムの生成元となっているか否かを確認する。他のスキーマの生成元となるテーブルのカラムの生成元となっている場合には、当該カラムを削除しない。図６のフローチャートについて説明する。
【００７１】
ステップ６０１では、変更候補テーブルのレコードを特定する番号ｐを０に初期化する。
【００７２】
ステップ６０２では、変更候補テーブルのレコードの中で、ステップ６０３以降の処理をおこなっていないレコードが存在するか否かを確認する。全てのレコードについて、ステップ６０３以降の処理を実行している場合には終了し、そうでない場合には、ステップ６０３に進む。
【００７３】
ステップ６０３では、変更候補テーブルの変数ｐに１を加え、ｐ番目のレコードを関連調査レコードとして選択する。例えば、Ｎｏ．＝２、テーブル名＝顧客属性、カラム名＝趣味、変更処理＝Ｄｒｏｐ＿ｃｏｌｕｍｎ（趣味）、関連Ｎｏ．＝１、終了フラグ＝１のレコードを、関連調査レコードとして選択したとする。
【００７４】
ステップ６０４では、テーブル関連情報１０４の中から、Ｆｒｏｍフィールドのテーブル名とカラム名が関連調査レコードと一致するレコードを検索し、一致したレコードが検索できた場合には、ステップ６０５に進む。一致するレコードが検索できなかった場合には、ステップ６０２に進む。ここでは、テーブル関連情報１０４の２番目のレコードが検索されるので、ステップ６０５に進む。
【００７５】
ステップ６０５では、関連テーブルレコードを生成する。ここで、関連テーブルレコードは、検索したレコードのＴｏフィールドのカラムに、関連調査レコードの変更処理をほどこすことを示す。レコードは、テーブル名、カラム名、変更処理から構成される。ここでは、（顧客属性，趣味，Ｄｒｏｐ＿ｃｏｌｕｍｎ（趣味））が、関連テーブルレコードとなる。
【００７６】
ステップ６０６では、関連テーブルレコードと同一レコードが変更候補テーブル情報１０６に存在するか否かを確認する。存在しない場合には、ステップ６０７に進み、存在する場合には、ステップ６０４に戻る。
【００７７】
ステップ６０７では、関連調査レコードを、変更候補テーブル情報１０６から削除する。
【００７８】
ステップ６０８では、選択している関連調査レコードをキーとして、テーブル関連情報の全てのレコードを検索したか否かを確認する。全てのレコードを検索している場合には、ステップ６０２に戻る。全てのレコードを検索していない場合は、ステップ６０４に戻る。
【００７９】
また、次元を削除する場合には、変更対象テーブル決定処理１０７は実行せず、変更候補テーブル情報１０６のＮｏ．、テーブル名、カラム名、変更処理が、テーブル定義変更情報１０９にコピーされる。
【００８０】
第２に、ＭＤスキーマのある次元の名称を変更する場合に、整合性を保つために、リレーショナル・データベースにより実装されたデータモデルの中で、名称を変更すべきテーブルとカラムをリストアップする。
【００８１】
名称を変更する次元の情報は、次元追加情報１０１と同様のフォーマットで記述される。例えば、趣味次元の名称を「主な趣味」に変更する場合には、次元名は「主な趣味」となり、変更処理はＣｈａｎｇｅ＿ｎａｍｅ（主な趣味）となる。データベースにより実装されたデータモデルの中で、カラムの名称を変更するテーブル及びカラムを特定するプロセスは、先の実施例で示した変更対象テーブル検出処理とほぼ同様である。ただし、変更候補テーブル抽出処理１０５を次のように変更する。
【００８２】
ステップ４０５において、テーブル関連情報の中から、Ｔｏフィールドのテーブル名とカラム名が、関連調査レコードと一致するレコードを検索する。
【００８３】
ステップ４０６は、検索したレコードのＦｒｏｍフィールドのカラム名を関連調査レコードのカラム名に変更するものとし、関連テーブルレコードに設定する。
【００８４】
また、次元の名称変更時には、第１の変更例と同様に、変更候補テーブル抽出処理１０５をおこなった後に、図６に示す変更対象カラム決定処理をおこなう。ここでは、名称を変更するカラムが、他のテーブルの生成と不整合を生じていないかを検証し、不整合が生じている場合には、該当するテーブルのカラムの名称も変更する。
【００８５】
変更対象カラム決定処理は、ステップ６０７のみ、「関連テーブルレコードを変更候補テーブルに追加する」処理に変更する。
【００８６】
また第１の変更例と同様に、変更対象テーブル決定処理１０７は実行せず、変更候補テーブル情報１０６のＮｏ．、テーブル名、カラム名、変更処理が、テーブル定義変更情報１０９にコピーされる。
【００８７】
第３に、ＭＤスキーマのある次元に関連する階層の最下位メンバの最大文字数を変更する場合に、整合性を保つために、リレーショナル・データベースにより実装されたデータモデルの中で、カラムのレコード長を変更すべきテーブルとカラムをリストアップする。
【００８８】
最大文字数を変更する次元の情報は、次元追加情報１０１と同様のフォーマットで記述される。例えば、趣味次元の最下位メンバの最大文字数を３２文字に変更する場合には、変更処理をＣｈａｎｇｅ＿ｌｅｎｇｔｈ（３２）に設定する。データベースにより実装されたデータモデルの中で、レコード長を変更すべきテーブル及びカラムを特定するプロセスは、第２の変更例と同様である。
【００８９】
以上に述べた本発明の方法を実行するプログラムを、計算機で読み取り可能な記憶媒体に格納し、実行時に、このプログラムをメモリに読み込んで実行することも可能である。
【００９０】
【発明の効果】
本発明によれば、データモデルなどの雛型が定まったデータウェアハウス、およびＢＩシステムに対して、システムの構成要素であるスキーマに新たな次元を追加、削除する場合に、リレーショナル・データベースの中で、カラムを追加、削除すべきテーブルをリストアップできる。また、スキーマの名称を変更する場合に、リレーショナル・データベースの中で、カラムの名称を変更すべきテーブルとカラムをリストアップできる。また、スキーマのある次元に関連する階層の最下位メンバの最大文字数を変更する場合に、リレーショナル・データベースの中で、カラムのレコード長を変更すべきテーブルとカラムをリストアップできる。
【図面の簡単な説明】
【図１】本発明が対象とする分析システムの構成図と本発明の処理フロー図である。
【図２】本発明が対象とする分析システムを構成するスキーマの定義情報を構成図である。
【図３】ＭＤスキーマ定義変更処理のフローチャートである。
【図４】変更候補テーブル抽出処理のフローチャートである。
【図５】変更対象テーブル決定処理のフローチャートである。
【図６】変更対象カラム決定処理のフローチャートである。
【符号の説明】
１０１…次元追加情報、１０２…ＭＤスキーマ定義変更処理、１０３…カラム追加情報、１０４…テーブル関連情報、１０５…変更候補テーブル抽出処理、１０６…変更候補テーブル情報、１０７…変更対象テーブル決定処理、１０８…テーブル別レコード数、１０９…テーブル定義変更情報
２０１…テーブル定義ファイル、２０２…スキーマ構成次元定義ファイル、２０３…次元定義ファイル、２０４…階層定義ファイル、２０５…マッピング情報ファイル

Claims (7)

1. リレーショナル・データベースに蓄積された明細データと属性データを集計して加工する際に、
   データベースの構造を定義したＭＤスキーマの中で変更すべきファイルとその変更方法をリストアップし、リレーショナル・データベースの中で、カラムを追加すべきロード元テーブルを特定し、
   テーブル間の処理を記述したテーブル関連情報に基づいて、変更対象となるロードテーブルから、その生成元となるテーブルを順に辿ることにより、全ての変更候補となるテーブルの組合せをリストアップし、
   複数の変更候補であるテーブルの組合せの中から、変更すべきレコードの数の総和が最小となるテーブルの組合せを出力することを特徴とする変更対象テーブル自動検出方法。
2. 前記テーブルの組合せをリストアップする際に、
   次元を追加、削除、変更する分析モデルを生成するためのロードテーブルを特定し、
   前記ロードテーブルをキーとして、リレーショナル・データベース上に定義されたテーブル間の関係を、生成元となるテーブル名及びカラム名、生成されたテーブル名及びカラム名と生成処理を一組のレコードとしたテーブル関連情報の生成されたテーブル名を検索し、検索したレコードの生成元テーブル名を次の検索キーとしてテーブル関連情報を検索する処理を繰り返すことにより、カラムを追加、削除、変更すべきテーブルの組合せをリストアップすることを特徴とする請求項１に記載の変更対象テーブル自動検出方法。
3. 前記項目を追加すべきテーブルの組合せに対して、レコード数の合計を算出し、該レコード数の合計が最少となるテーブルの組合せを抽出することを特徴とする請求項１及び２に記載の変更対象テーブル自動検出方法。
4. 前記カラムを削除すべきテーブルの組合せに対して、削除対象となっているカラムが、他のスキーマの生成に利用されているか否かを確認し、他のスキーマの生成に利用されている場合には、削除対象から外すことを特徴とする請求項１及び２に記載の変更対象テーブル自動検出方法。
5. 前記カラムを変更すべきテーブルの組合せに対して、変更対象となっているカラムが、他のスキーマの生成に利用されているか否かを確認し、他のスキーマの生成に利用されている場合には、当該のスキーマを生成するテーブルに対して、同様の変更を施すことを特徴とする請求項１及び２に記載の変更対象テーブル自動検出方法。
6. 変更対象テーブル自動検出方法を計算機で実施するプログラムを記憶した記憶媒体であって、前記方法は、
   データベースの構造を定義したＭＤスキーマの中で変更すべきファイルとその変更方法をリストアップし、リレーショナル・データベースの中で、カラムを追加すべきロード元テーブルを特定し、
   テーブル間の処理を記述したテーブル関連情報に基づいて、変更対象となるロードテーブルから、その生成元となるテーブルを順に辿ることにより、全ての変更候補となるテーブルの組合せをリストアップし、
   複数の変更候補であるテーブルの組合せの中から、変更すべきレコードの数の総和が最小となるテーブルの組合せを出力することを特徴とする記憶媒体。
7. 変更対象テーブル自動検出システムは、
   データベースの構造を定義したＭＤスキーマの中で変更すべきファイルとその変更方法をリストアップし、リレーショナル・データベースの中で、カラムを追加すべきロード元テーブルを特定するＭＤスキーマ定義変更手段、
   テーブル間の処理を記述したテーブル関連情報に基づいて、変更対象となるロードテーブルから、その生成元となるテーブルを順に辿ることにより、全ての変更候補となるテーブルの組合せをリストアップする変更候補テーブル抽出手段、　複数の変更候補であるテーブルの組合せの中から、変更すべきレコードの数の総和が最小となるテーブルの組合せを出力する変更対象テーブル決定手段を有することを特徴とする変更対象テーブル自動検出システム。

Images