【課題】データベースのテーブル関係及び参照データをメタデータとして保存し、これを用いてレポートを作成するOLAPシステムにおいて、レポートの重要度を演算するオンライン分析処理システムを提供する。
【解決手段】OLAPサーバ30において、ビッグデータを保存するデータキューブのデータを参照するために作成されるテーブル関係図及び参照項目をメタデータとして構成して保存するメタデータ構成部31と、一つの選択されたメタデータの参照項目だけでピボットテーブルを構成し、ピボットテーブルの結果を含むレポート作成をサポートするレポート作成部34と、レポートのピボットテーブルに使用された参照項目が他のレポートに使用される割合に、当該参照項目を含むテーブルのリンクによる加重値を加重して当該参照項目の重要度を求め、レポート内の参照項目の重要度を合算して前記レポートの重要度を算出するレポート分析部35とを含む。
前記レポート分析部は、当該参照項目の重要度を求めるとき、前記レポートに使用される全体参照項目の個数を反比例して算出することを特徴とする、請求項1に記載のメタデータ基盤のオンライン分析処理システム。
前記レポート分析部は、前記レポートのピボットテーブルのデータ領域において値が表示されないセルの割合を加重して前記レポートの重要度を算出することを特徴とする、請求項1に記載のメタデータ基盤のオンライン分析処理システム。
【背景技術】
【0002】
一般に、オンライン分析処理(OLAP:on−line analytical processing)システムとは、ビッグデータをデータウェアハウス(DW:data warehouse)またはデータキューブにより構成して蓄積し、蓄積されたビッグデータを用いてオンライン上で簡単に接続して分析するためのツールのことをいう。すなわち、企業の膨大なデータを統計分析などの定型的若しくは非定型的な方法を用いて様々に分析したり、分析された情報を理解し易い一目瞭然なレポートの形式に加工したりして、ビジネスをより合理的に行うようにサポートする一連のツールのことをいう。
【0003】
特に、最近、ソーシャル・ネットワーキング・サービス(SNS)、ソーシャルメディアなどのデータに対する分析の重要性が次第に高くなるに伴い、企業体の製品に対する顧客管理や製品広報などのためのビッグデータ(Big data)を収集して分析を行おうとする企業が段々増えてきている。ビッグデータという用語は、ある程度経過した時間内に属するデータを収集、管理、保存、検索、共有、分析及び視覚化するための通常のソフトウェアツール及びコンピュータシステムでは取り扱い難いレベルのデータ量を有するデータセット(data set)に対して主として適用される。ビックデータのサイズは、テラバイト、エクサバイトまたはゼタバイトの範囲を有していてもよい。ビッグデータは様々な分野に存在するが、例えば、ウェブログ(web logs)、無線周波数認識装置(RFID)、センサーネットワーク、ソーシャルネットワーク、ソーシャルデータ、インターネットテキストと文書、インターネット検索インデキシング、販売時点(POS:point of sales)データ、販売記録、医療記録、写真記録、ビデオ記録及び電子商取引などが挙げられる。
【0004】
上記のようなビッグデータを用いて分析を行うためにオンライン分析処理システムが多様に開発されてきた。例えば、ウェブ環境などのオンライン上においてデータベースを照会して分析するレポーティング技術が提案されている(下記の特許文献1,2)。しかし、上記先行技術は、開発者がレポートの枠組みを設計するために、レポートの作成ツールや言語を学ばなければならないという問題や、分析レポートを作成するたびに毎回データベースからデータベーステーブル(以下、「DBテーブル」)を選択し、それらの間の関係を設定し、SQLなどのデータベース質問を作成しなければならないという問題がある。
【0005】
かかる問題を解決するために、過去に作成した分析レポートの結果物を再利用できる環境を提供する技術を提示した(下記の特許文献3)。ほとんどの一般的なユーザが作成する分析レポートは、過去に作成された分析レポートに比べてさほど異なってはおらず、少しずつ変形された形で作成される。したがって、過去に作成した分析レポートの結果をメタデータとして再利用できる環境を提供して、分析レポート作成作業をより簡単に行うようにサポートしている。
【0006】
即ち、OLAPレポートは、メタデータ又はメタデータを用いてレポートを作成する。メタデータは、企業の全てのデータソースを同じ観点で標準化して設計した構造ファイルである。このように設計されたメタデータは、クエリに慣れていないユーザにとってデータアクセスの利便性を提供する。また、メタデータを用いて作成したレポートは、標準化された形で自動的に生成されたクエリにより生成されるため、管理面やデータの整合性の観点から一貫性を維持することができる。直接現業ユーザが様々な観点からデータを分析できる非定型分析のためのレポート生成時に、主としてメタデータを用いる。
【0007】
メタデータを用いたレポートの生成機能は、一般のユーザに対して利便性を提供するが、管理面からみると、次のような不都合が生じる可能性がある。
【0008】
第一に、メタデータを用いたレポートが多くなると、特定のユーザが所望するレポートを発見し難く、同じ結果を算出するレポートが多数存在することになる。このため、一層正確な検索機能が必要となる。
【0009】
第二に、レポートを客観的に評価する基準がない。すなわち、メタデータを用いたレポートがうまく作成されたかどうかを評価する客観的基準がない。また、レポート間の重要度を比較できる基準がないということである。
【発明を実施するための形態】
【0023】
以下、本発明の実施のための具体的な内容を図面を参照して説明する。
【0024】
なお、本発明を説明する各図面において、同一の部材には同一の符号を付し、その繰り返しの説明は省略する。
【0025】
まず、本発明に係るメタデータ基盤のオンライン分析処理システムを実施するための全体システムを、
図1を参照して説明する。
【0026】
図1に示すように、本発明を実施するための全体システムは、ユーザが使用するビッグデータを保存するデータキューブ60と、メタデータを保存するメタデータベース(以下、「メタDB」)40と、ユーザ端末20と、オンライン上でレポート作成サービスを提供し、レポートを分析するOLAPサーバ30とで構成される。
【0027】
まず、データキューブ60は、通常のデータベース(またはデータウェアハウス、データキューブ)であり、企業などがビジネスを行うことで蓄積されるデータを保存する。以下では、データキューブ60に保存されるデータをビッグデータとして呼ぶことにする。好ましくは、データキューブ60は、関係データベース(RDB:relational database:リレーショナルデータベース)により構成されてもよい。
【0028】
好ましくは、データキューブ60は多数のDBテーブルで構成され、各DBテーブルは多数のレコードで構成され、各レコードが一つの情報または一連のデータを示す。すなわち、各レコードは多数のフィールドで構成され、各フィールドにフィールド値が保存される。一方、一つのDBテーブルに属する全てのレコードは、同一のフィールドを有する。すなわち、1つのDBテーブルは多数のフィールドを有し、DBテーブルに記録されるレコードは、DBテーブルのフィールドにフィールド値を保存する。
【0029】
また、データキューブ60は、データ(またはビッグデータ)を管理するためのデータベース管理システム(DBMS:database management system)を備え、データの保存、削除、検索などの作業をクエリを用いて行う。特に、データキューブ60は、商用化されたデータベースであり、データを処理するための一般的なクエリ機能を用いてデータクエリサービスを行う。すなわち、クエリは、DBテーブルと、当該DBテーブルに対する参照項目(フィールドなど)とにより定義されるか設定される。
【0030】
次に、メタDB40は、メタデータ(またはメタメタデータ、メタデータ)を保存するための通常のデータベース(DB)であり、データキューブ60のビッグデータを参照するためのDBテーブル関係及び参照項目についての情報を示すメタデータ(またはメタメタデータ、メタデータ)を保存する。
【0031】
メタデータとは、クエリを作成するために参照すべきDBテーブル及び、当該参照項目、条件などを定義したデータのことをいう。特に、DBテーブルが少なくとも2つである場合には、DBテーブル間の関係も定義される。すなわち、メタデータは、クエリの作成に用いられるDBテーブル、テーブル間の関係、参照項目(参照するフィールド)、条件などを記録したデータである。
【0032】
ユーザは、データキューブ60から自分が必要とするデータを抽出するために、メタデータを用いて簡単にクエリを作成することができる。すなわち、メタデータにおいてDBテーブル、テーブル間の関係、参照項目が定義されているので、ユーザは参照項目を自分が所望する出力形態として定義したり、一部の条件を簡単に訂正して所望のクエリを作成したりできる。なお、後述するOLAPサーバ30は、グラフィカルユーザインタフェース(GUI:Graphical User Interface)を用いてドラッグ&ドロップで簡単にクエリを作成するようにサポートしている。
【0033】
また、メタDB40は、当該メタデータによって生成されたレポート情報を保存する。ユーザは、メタデータを用いてクエリを作成し、クエリを用いて所望のデータ(またはビッグデータ)を取り込む。そして、ビッグデータの分析結果をレポートとして作成する。このように、メタデータによってレポートが生成されると、当該メタデータについて作成されたレポート情報を追加的に記録して保存する。
【0034】
ユーザ端末30は、パーソナルコンピュータ(PC)、タブレットPC、スマートフォンなどのコンピューティング機能を有するコンピュータ端末であり、OLAPサーバ30とネットワーク(図示せず)により接続されて、オンライン上でレポートの作成作業を行う。このとき、ユーザ端末30には、OLAPサーバ30と連動してレポートの作成作業を処理するクライアント(図示せず)がインストールされ、クライアントによりレポートの作成作業が処理できる。
【0035】
また、ユーザ端末30は、メタデータの検索、ビッグデータの要請、ビッグデータの分析などのオンライン上でビッグデータ関連作業をOLAPサーバ30に要請し、その結果をOLAPサーバ30から取得してWebブラウザ上に表示する。
【0036】
次に、OLAPサーバ30は、オンライン分析処理(OLAP)を行うサーバであり、ユーザ端末30からメタデータ検索、ビッグデータクエリなどに対する要請を受信し、当該検索またはクエリ要請を処理してその結果をユーザ端末30に送信するサーバである。
【0037】
特に、OLAPサーバ30は、ビッグデータを要請するクエリ(またはデータ参照質問)を用いて、データキューブ60に保存されているビッグデータを取り込む。クエリとは、データキューブ60に保存されているビッグデータの検索または更新時に発生する問い合わせを記述するデータ操作言語を意味する。データベースにおいて、クエリは、一種の命令語のような役割を果たす。関係データベースの構造化問い合わせ言語(Structured Query Language:以下、「SQL」)の形式で表現されるが、場合によっては、SQL以外の他の形式で表現されてもよい。
【0038】
また、OLAPサーバ30は、メタデータをメタDB40から検索し、検索されたメタデータを取り込み、当該メタデータによりクエリ作成環境を設定する。すなわち、参照するDBテーブル、テーブル間の関係、及び参照する項目などを設定する。好ましくは、このようなクエリ作成環境をGUI形態で表示する。ユーザは、OLAPサーバ30に設定されたクエリ作成環境下で簡単な操作(ドラッグ&ドロップなど)により自分が所望するデータを処理するクエリを作成することができる。
【0039】
また、OLAPサーバ30は、クエリを用いてデータキューブ60から取り込んだビッグデータを使用することで、レポートを作成できる著作環境をサポートする。
【0040】
また、OLAPサーバ30は、メタデータの頻度を用いてレポートの重要度を演算する。メタデータは、クエリの作成と関連して、DBテーブル、テーブル間の関係、参照項目、条件、作成されたレポートなどに対するデータを有する。OLAPサーバ30は、これらのデータを用いてレポートの重要度などを分析する。
【0041】
次に、本発明の一実施例に係るメタデータ基盤のオンライン分析処理システムの構成を、
図2を参照して説明する。
【0042】
図2に示すように、本発明の一実施例に係るメタデータ基盤のオンライン分析処理システム30は、メタデータ構成部31と、クエリ作成部33と、レポート作成部34と、レポート分析部35とで構成される。
【0043】
メタデータ構成部31は、データキューブ60のビッグデータを参照するために作成されるテーブル関係図及び参照項目をメタデータとして構成して保存する。好ましくは、前記メタデータをキーワードで検索するためにデータベース化して構築する。
【0044】
メタデータ構成部31は、メタデータを管理者(デザイナー)により作成してもよく、メタデータを自動的に構成してもよい。
【0045】
例えば、メタデータ構成部31は、データキューブ60のデータを参照するために作成されるクエリ(テーブル関係図及び参照項目など)からメタデータを構成して保存する。ユーザは、レポート作成のための新しいクエリを作成してよく、検索されたメタデータを訂正して新しいクエリを作成してもよい。このとき、保存されているメタデータとは異なる形態のテーブル関係図及び参照項目などが構成されると、このテーブル関係図及び参照項目を新しいメタデータとして追加してもよい。また、メタデータは、他のオンライン分析処理(OLAP)で作成されるテーブル関係図及び参照項目のデータを収集して構成されてもよい。
【0046】
特に、メタデータは、データキューブ60を参照するDBクエリ文(例えば、SQL文など)から自動的に抽出できる。参照項目は、クエリ文の参照項目(例えば、SELECT文に記載された参照項目)から抽出し、テーブル関係図は、前記クエリ文において参照するDBテーブル及びDBテーブル間のフィールド条件から抽出できる。
【0047】
メタデータは、基本的にテーブル関係図及び参照項目で構成される。
【0048】
また、テーブル関係図は、DBテーブル及びジョイン(join)(またはリンク)関係により構成される。テーブル関係図は、通常の実体関連モデル(ERD:Entity−relationship Model)と類似している。但し、特定の目的のデータ(データキューブのデータ)を参照するために、DBテーブルのジョイン(join)関係を予め定義して、自動的にSQLを生成できるジョイン関係を設定しておく。
【0049】
DBテーブルとは、データキューブ60に構成されるテーブルのことをいう。 DBテーブルは、通常のデータベーステーブルであり、多数のカラム(またはフィールド)で構成され、DBテーブルの各データは各フィールドの値を有する。
【0050】
ジョイン関係は、少なくとも2つのDBテーブル間のジョイン(join)を行うための条件のことであり、DBテーブルのフィールド間の条件として表示される。ジョイン関係は、通常のデータベースにおけるジョイン関係であり、具体的説明は省略する。
【0051】
図3は、テーブル関係図を例示している。
図3に示すように、4つのDBテーブルで構成されている。すなわち、<職員(Emplyee)>、<給与(Salary)>、<住所(Address)>、および<職位(Work position)>の4つのDBテーブルで構成される。また、ジョイン関係として、<職員−給与>、<職員−住所>、<職員−職位>間にそれぞれの関係を有する。 <職員−給与>関係では、社員番号フィールドが同一であることを条件とし、<職員−住所>の関係では、住所コードフィールドが同一であることを条件とし、<職員−職位>の関係では、職位コードフィールドが同一であることを条件とする。
【0052】
参照項目は、データキューブ60のデータを参照するための項目であり、DBテーブルのフィールド項目と、前記フィールド項目を加工して取得する派生項目とで構成される。すなわち、参照項目は、ユーザが参照項目として選択したテーブルのカラム名(フィールド名)、またはユーザがカラム名(フィールド名)などを利用して定義した参照項目(派生項目)で構成される。
【0053】
一方、参照項目は、次元(dimension)形式と測定値(measure)形式とに分けられる。好ましくは、参照項目(またはカラム)の値が文字である場合、次元形式で指定し、参照項目の値が数値である場合、測定値形式で指定する。
【0054】
OLAPキューブ(cube)定義やデータウエアハウス(DW:Data warehouse)においてテーブルの各カラムは、次元(dimension)形式と測定値(Measure)形式とに事前に分類されて設定されてもよい。特に、次元は構造化されたラベル情報を提供する。前記のように、データキューブ60に、DBテーブルのフィールド(またはカラム)に対して事前に次元形式または測定値形式で設定されている場合は、当該設定に基づいて参照項目の形式が設定される。
【0055】
一方、測定値は、整列されていない数値、数値演算が可能な値を意味する。必ずしも全ての場合に文字列値が次元になり、数値が測定値になるわけではない。例えば、製品番号という項目は数値であるが次元形式として分類される(すなわち、製品番号を数値演算することができない)。また、文字列項目をカウント(count)する場合(例えば、登録ユーザ数はユーザ名count)、測定値形式として分類されるべきである。自動的に分類する基準は文字列または数値であり、ユーザまたは管理者により当該参照項目の形式が補正できる。
【0056】
図3の例を参照すると、カラム名<職位名>、<氏名>、<マイナンバー1>、<年月>、<郵便番号>、<住所_都道府県>、<住所_市区町村>は、次元形式の項目であり、カラム名<基本給>、<手当>は、測定値形式の項目である。
【0057】
参照項目を次元形式と測定値形式とに分ける理輔は、次元別に測定値がグループ(aggregation)となるからである。参照項目の定義によれば、測定値形式の参照項目はグループ関数(Aggregation Function)属性を有する。ここで、グループ関数とは、合計(SUM)、最小値(MIN)、最大値(MAX)、平均(AVG)、カウント(count),distinct count などをいう。また、ピボットテーブルにおけるデータ領域には、グループ関数により計算された値が表示される。
【0058】
例えば、2つの次元形式の参照項目が1つの測定値形式の参照項目を選択すると、クエリ文(SQL)は、下記のように生成される。
【0059】
[クエリ文1]
Select dim1、dim2 sum(measure)from table
Group by dim1、dim2
図3の例において、<人事及び給与情報>メタデータの場合、<基本給>測定値の参照項目のみを選択した場合、結果データは、全職員の基本給となり、氏名(次元)、基本給(測定値)を選択した場合、氏名別基本給の合計となる。また、氏名(次元)、年月(次元)、基本給(測定値)を選択した場合、氏名別、年月別の基本給データが照会される。
【0060】
一方、データキューブのデータを参照するためのクエリにおいて、参照されたカラムだけを参照項目として選定される。すなわち、必ずしもDBテーブルの全てのカラムが参照項目として選定されるわけではない。
図3の例において、参照項目としては、DBのテーブルにおいてチェック表示されたフィールド、すなわち、<職位名>、<氏名>、<マイナンバー1>、<年月>、<郵便番号>、<住所_都道府県>、<住所_市区町村>、<基本給>、<手当>などだけが選定される。<職員(Employee)>テーブルの<マイナンバー2>、<入社日付>、<部署コード>などは、参照項目として選定されない。
【0061】
次に、派生項目とは、DBテーブルのカラム(またはフィールド)に対する演算によりテーブル内にない項目を派生的に作り出したもののことをいう。派生項目も一つの参照項目であり、次元形式と測定値形式とに分けられる。
【0062】
次元形式として派生させた参照項目の例を挙げると、<期間>テーブル内に<年月>というカラムが存在する場合、下記のように<年度>、<月>などを派生項目として作成することができる。
【0063】
<年度>:substr(<年月>、1,4)
<月>:substr(<年月>、5,2)
また、測定値形式として派生させた参照項目の例として、計算式を用いた参照項目が生成できる。例えば、DBテーブルに<生産量>、<処理量>カラムが存在する場合、<実收率>カラムを計算式を用いて派生項目として生成することができる。
【0064】
<実收率>:<生産量>/<処理量>×100
好ましくは、メタデータの参照項目をテーブルで構成して保存してもよい。具体的には、
図4に示すように、メタデータの参照項目は、メタデータの名前であるメタデータ名、参照項目の名前である参照項目名、DBテーブルの名前であるテーブル名、テーブル内の参照フィールドであるカラム名、次元/測定値形式を示す形式、計算式を用いる派生項目である場合、当該計算式を表示する数式などで構成される。
【0065】
好ましくは、数式は、派生項目の数式(Formula)属性として保存する。保存された数式は、後ほどメタデータを再利用して自動的にクエリ文(SQL)を作成する際にそのまま用いられる。一方、数式は、SQL文法のそのままの数式を使用してもよく、標準化された数式で管理して、データキューブ(またはデータベース)の種類に適したクエリ文(SQL)に自動的に変更してもよい。 DB種類別に提供される関数(function)の文法が異なる場合があるからである。例えば、SUBSTRING関数が、オラクル(商標ORACLE)ではSUBSTRであり、MS−SQLではMIDであるようにそれぞれ異なってもよい。
【0066】
次に、クエリ作成部33は、ユーザにより選択されたメタデータの参照項目だけでクエリを構成できるインターフェース画面(以下、クエリデザイン画面)を表示する。特に、クエリデザイン画面は、ドラッグ・アンド・ドロップ(drag&drop)方式によるインタフェースを有する。
【0067】
図5に示すように、クエリデザイン画面は、メタデータの参照項目を表示する領域(以下、「項目表示領域」)と、選択された参照項目を表示する領域(以下、「選択表示領域」)とで構成される。選択された参照項目領域(または選択表示領域)は、次元形式(次元領域)と測定値形式(またはデータ領域)とに分けられて表示される。好ましくは、選択された参照項目の領域には、フィルタリングにより選択される参照項目を表示するフィルター領域がさらに含まれてもよい。
【0068】
クエリデザイン画面において、ドラッグ・アンド・ドロップ方式により項目表示領域に表示される参照項目が選択され、選択表示領域に選択された参照項目が表示される。
【0069】
クエリ作成部33は、クエリデザイン画面上での選択表示領域に、選択された参照項目が表示されると、自動的にクエリ文を生成する。ユーザが<氏名>、<年月>、<基本給>を選択した場合について説明する。当該キーワードを参照項目として有しているテーブル関係のメタデータを用いて自動的にクエリ文(SQL)が生成される。この時、参照項目の属性として、メタデータに定義された次元、測定値、グループ関数を基準としてグループ化し、データ件数を次元の固有値で最小化し、データキューブにデータを照会してレポートを作成する。SQL文に必要なジョイン(join)構文の場合、テーブル関係のメタデータに何百個のテーブルが定義されていても、選択した参照項目を有するテーブルだけが関係メタデータ関係図において最小全域木(Minimum spaning tree)アルゴリズムであり、テーブル間の最小のジョイン(join)によりSQLが生成される。
【0070】
図5の例において、メタデータのテーブル関係図により下記のようなクエリ文(SQL)が自動的に生成され、データキューブ60のデータを自動的に照会することができる。
【0071】
[クエリ文]
SELECT B.氏名、C.年月、sum(C.基本給)from F_employee B,F_SALARY C
Where b.社員番号=c.社員番号
Group by B.氏名、C.年月
また、クエリデザイン画面の項目表示画面には、メタデータの参照項目だけが表示される。すなわち、参照項目を含むDBテーブル内の参照項目以外の他のカラム名は表示されない。これは、DBのテーブル内には、エンドユーザ(end−user)に公開してはならない情報もあり得るからある。すなわち、本発明によってデータのセキュリティが強化できる。
【0072】
メタデータの参照項目は、実際のテーブルには存在しない論理的な束(フォルダ)により階層的に構成され、このような構成には、ユーザにとって項目を選択しやすいように分離して表示する機能も含まれてもよい。
図6の例では、<Dimension>、<組織>、<期間>、<商品>、<担保>などの論理的なグループをフォルダ形態に分けて参照項目を選択できるようにユーザに提供する。
【0073】
次に、レポート作成部34は、ユーザによって一つのメタデータが選択されると、選択されたメタデータの参照項目だけでピボットテーブルを構成できるインターフェース画面(以下、「ピボットデザイン画面」)を表示する。特に、ピボットデザイン画面は、ドラッグ・アンド・ドロップ(drag&drop)方式によるインタフェースを有する。
【0074】
図7に示すように、ピボトデザイン画面は、メタデータの参照項目を表示する領域(以下、「項目表示領域」)と、選択された参照項目を表示する領域(以下、「選択表示領域」)とで構成される。選択された参照項目領域(または選択表示領域)は、カラム領域と、行領域と、データ領域とに区分される。または、ページ領域にさらに区分されてもよい。
【0075】
また、前述したクエリデザイン画面と同様に、ピボットデザイン画面の項目表示画面には、メタデータの参照項目だけが表示される。すなわち、参照項目を含むDBテーブル内の参照項目以外のカラム名は表示されない。また、メタデータの参照項目は、実際のテーブルには存在しない論理的な束(フォルダ)により階層的に構成され、このような構成には、ユーザにとって項目を選択しやすいように分離して表示する機能も含まれてもよい。
【0076】
ピボットデザイン画面では、ドラッグ・アンド・ドロップ方式により項目表示領域に表示される参照項目が選択され、選択表示領域に選択された参照項目が表示される。
【0077】
ページ領域において選択した参照項目の値により、現在表示された行、列、データ領域に表示された値をフィルタリングできる機能が提供される。たとえば、「年月」を参照項目をページ領域に配置した場合、ページ領域において「2013年12月」を選択して当該年月のデータのみを確認する機能が行われ、この機能は、エクセルピボットテーブルのページ領域の機能と同様の機能である。
【0078】
また、カラム領域、行領域、データ領域は、ピボットテーブルにおいてそれぞれ列、行、データのフィールドに対応される。すなわち、カラム領域、行領域、データ領域としてそれぞれ選択された参照項目がそれぞれピボットテーブルのカラム、行、データフィールドとして定められる。ピボットテーブルは、通常のピボットテーブル(例えば、マイクロソフト社のエクセルにおけるピボットテーブルなど)の方法を使用するので、具体的な説明は省略する。
【0079】
このとき、カラム領域及び行領域には、次元形式の参照項目だけが選択されて表示され、データ領域には、測定値形式の参照項目だけが選択されて表示され得る。
【0080】
レポート作成部34は、ピボットデザイン画面上での選択表示領域に、選択された参照項目が表示されると、自動的にピボットテーブルまたはピボットレポートを生成する。ピボットレポートの例は、
図8に示されている。
【0081】
ユーザが選択した参照項目のうち測定値形式の参照項目は、データ領域に自動的に配置され、次元項目値のうちの2つは行領域、1つは列領域、残りの次元はページ領域に自動的に配置される。また、このような配置により、ピボットレポートを自動生成する。
自動生成の後には、既存の他のツールが提供する方法を用いて、ユーザ所望の配置に変更してOLAP分析を行うことができる。その後、新規項目を追加して分析したい場合、編集モードに変更すると、既存のキーワードで検索し、自動配置された参照項目の表示領域(表示窓)が現れ、参照項目を追加することができる。
【0082】
すなわち、ユーザは、メタデータの参照項目(またはメタフィールドデータ)を照会し、当該参照項目を用いて様々な観点からデータを分析することができる。 OLAPサーバ30は、クエリを自動的に作成し、内部的にキューブを作成して、その結果を多次元グリッドの形状としてユーザまたはユーザ端末20に伝達する。
【0083】
次に、レポート分析部35は、メタデータ、メタデータ内の参照項目、及び生成されたレポートに対するデータを用いて各レポートの重要度を算出する。
【0084】
図9に示すように、レポート分析部35は、(a)DBのテーブルの加重値算出ステップ(S10)、(b)メタデータの頻度計算ステップ(S20)、及びレポートの評価ステップ(S30)を行うことによりレポートを分析する。
【0085】
まず、DBテーブルに対する加重値を算出する(S10)。
【0086】
メタデータを構成するテーブル情報には、リンク(ジョイン)情報がある。メタデータは、
図10に示すようなDBテーブル構造のデータを有すると仮定する。
【0087】
図10の例において、販売(Sales)テーブルと、製品(Product)テーブルのテーブル加重値(リンク加重値)を計算すると、以下の通りである。
【0088】
初期に全てのテーブルは数値1を有し、リンクに沿って連結されたテーブルに数値を伝播する。この時、接続されたリンクの数だけ分けて有する。販売(Sales)テーブルと製品(Product)テーブルの加重値は、下記のように計算する。
【0089】
Sales加重値=Product(2/3)+Store(1/2)+Period(1/1)+Promotion(1/1)=3.16
Product加重値=Sales(2/5)+Class(1/1)=1.4
DBテーブルの全体集合Tを下記のように定義する。
【0090】
T={T
1、T
2、T
3、...、T
N}
また、メタデータ内に含まれている参照項目Iを下記のように定義する。
【0091】
I={I
1、I
2、I
3、...、I
M}
また、I
j∈T
iは、参照項目I
jがDBテーブルT
iによる参照項目であることを示すものであると定義する。すなわち、参照項目I
jは、DBテーブルT
iのフィールドであるか、これから生成された参照項目であることを示す。
【0092】
また、メタデータによって生成されたレポートRを下記のように定義する。
【0093】
R={R
1、R
2、R
3、...、R
K}
また、I
j∈R
iは、参照項目I
jがレポートR
kによる参照項目であることを示すものであると定義する。
【0094】
このとき、DBテーブルT
iの加重値ω
iは、下記の数学式1により計算される。
【0096】
式中、{L(T
k)}は、テーブルT
kのリンク集合を意味し、{L(Ti、T
k)}は、テーブルT
iとテーブルT
kとの間のリンク集合を意味する。また、n()は、集合の個数を示す。
【0097】
また、リンクは、2つのDBテーブル間のジョイン(join)のためのフィールド(参照項目)間の連結(条件)を意味する。前記
図10の例において、販売(Sales)テーブルのリンク数は5つであり、製品(Product)テーブルのリンク数は3つである。また、製品テーブルと販売テーブルとの間のリンク数は2つであることが確認される。すなわち、製品テーブルと販売テーブルとの間のジョインは、classkeyとprokeyの2つのフィールド(参照項目)により連結(リンク)される。
次に、レポートに使用される参照項目の頻度を計算する(S20)。重要なメタデータの参照項目であるほど頻繁に使用されるであろう。参照項目が使用されたレポートの数及び全体レポートの数を用いて計算する。
【0098】
まず、参照項目のレポートへの使用割合を下記のように求める。
【0100】
すなわち、参照項目のレポートへの使用割合は、全体レポートの数に対する、当該参照項目が使用されたレポートの数の割合を示す。
また、参照項目の重要度は、下記の数学式3のように算出する。
【0102】
すなわち、参照項目の使用割合に、参照項目を含むテーブルの加重値の和を加重し、レポートに使用された全体参照項目の数で除算する。
【0103】
次に、レポートの重要度を算出する(S30)。
【0104】
ピボットテーブルにおけるデータ領域において当該セルに結果がなければ、「−」と表示される。結果がないということは、レポートを間違って配置した場合に該当する。このような場合を最小限にするのが良いレポートであると言える。
【0105】
したがって、データ領域のセルに対する結果を考慮した上、下記の数学式4のように算出する。
【0107】
但し、式中、NAセルは、データ領域のセルのうち値が表示されないセルを示す。セル又はNAセルは、レポートR
kにおいてピボットテーブルのデータ領域のセルを示す。
【0108】
そして、セルの結果がすべてNAであれば、レポートの重要度は0となる。
【0109】
以上、本発明者によってなされた発明を実施例に基づき具体的に説明したが、本発明は前記実施例に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【0110】
本発明は、以下のような国家研究開発事業の支援課題と関連しているものであることを明らかにする。
[この発明を支援した国家研究開発事業]
[課題固有番号]R0113−15−0005
[部処庁]韓国の未来創造科学部
[研究管理専門機関]韓国の情報通信技術振興センター
[研究事業名]情報通信、放送研究開発事業
[研究課題名]大規模なトランザクション処理とリアルタイム複合分析を統合した一体型データエンジニアリング技術開発
[寄与率]1/1
[主管機関]韓国電子通信研究院
[研究期間]2015年10月01日〜2019年09月30日