JPH1115711A

JPH1115711A - データ管理装置

Info

Publication number: JPH1115711A
Application number: JP9169941A
Authority: JP
Inventors: Yoshinori Sato; 嘉則佐藤; Katsumi Omori; 勝美大森; Toyohisa Morita; 豊久森田; Akira Maeda; 章前田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-06-26
Filing date: 1997-06-26
Publication date: 1999-01-22

Abstract

(57)【要約】【課題】蓄積された属性情報から典型的なデータアクセ
スパターンを抽出し、データベース管理で利用者が用い
るための情報を提供することを課題とする。【解決手段】クライアント装置１０１からデータベース
サーバ装置１０２に格納されたデータへの参照が発生す
ると、クライアント装置１０１から発行された参照命令
はデータベースサーバ装置１０２と、データ管理装置４
００の両方に渡す。データベース装置１０２は受け取っ
た命令を処理し、結果をクライアント装置１０１へ返
す。データ管理装置４００が受け取った命令は、まずＳ
ＱＬ解析装置によって命令中の属性参照情報が抽出さ
れ、次に抽出された情報が属性参照情報蓄積装置１０９
に格納される。利用者が着目したい１個以上の属性、依
存関係の強さの最小値等のパラメータを入力装置１０７
により指定すると、属性依存関係解析装置１０６によ
り、パラメータを満たす属性間の依存関係が抽出され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベースシス
テムののアクセス記録を用いて、データ定義構造を作成
するための有益な情報を利用者に提供方法と、データ定
義構造を自動的に再編成する方法に係わり、データベー
スシステム管理の自動化、データベースへのアクセス効
率向上に関する。

【０００２】

【従来の技術】近年の計算機技術の発達、ＬＡＮ、ＷＡ
Ｎ等ネットワークインフラストラクチャの整備に従い、
これまで以上に大量、多種のデータを蓄積、利用する動
きが活発化しており、単にデータを蓄積して定型的な業
務に利用するだけでなく、分析業務などの非定型な業務
にデータベースを利用するケースが現れてきた。

【０００３】従来はＤＢ（ＤataＢase）システムに備わ
った検索機能を利用して、データの集計、加工を行って
きた。現在はＤＢシステムはＲＤＢ（Ｒelational Ｄa
tabase）を用いたものが最も普及しており、ＲＤＢでは
ＳＱＬと呼ばれる言語をベースに機能が提供される。Ｓ
ＱＬにより、複数の表形式のデータに対する演算操作と
して各種集計機能が提供される。ＲＤＢ，ＳＱＬに関し
ては「データベースシステム概論、Ｃ．Ｊ．Ｄate著、
藤原譲訳、丸善株式会社」に詳しい。以下ＲＤＢを従来
技術１と呼ぶ。

【０００４】また、現在、非定型業務に関わるデータ利
用形態として、データウェアハウス（Ｄata Ｗarehous
e）と呼ばれるデータ利用システムが着目されている。
データウェアハウスとは、情報検索、意志決定支援など
ユーザのニーズに合わせて作られるデータベースのこと
である。複数のサーバ上に目的別に重複を許されたデー
タ群があり、原則として更新は夜間等に定期的行われる
だけで、逐次的な更新処理はされず、データの元は基幹
系システム上のデータベースから抜き出されたデータ群
（スナップショット）である。現在データウェアハウ関
連製品は多数発売されている。以下、データウェアハウ
ス構築、支援技術を従来技術２と呼ぶ。データウェアハ
ウスの記述に関しては、「初めてのデータウェアハウス
構築、Ｗ．Ｈ．Ｉnmon著、藤本康英、小畑喜一監訳、オ
ーム社」に詳しい。

【０００５】

【発明が解決しようとする課題】分析業務などの非定型
業務にデータベースを活用する場合、高いレスポンス性
能が要求されるため、ユーザ数の増加、データの更新、
データの使われ方の変化に従って、データの蓄積構造を
変えていく必要があり、システム全体のメインテナンス
は不可欠である。

【０００６】従来技術１は、データをテーブルとして定
義して管理する機能と、テーブルを検索するための機能
を提供する。またデータを効率的に蓄積するため、実際
にはデータが重複しないようにテーブルを分割して蓄積
し、ユーザがデータを参照する際に、分割したテーブル
を仮想的な１個のテーブルへ結合し、出力する機能が利
用される。しかし大規模なデータベースの場合、アクセ
スの度に複数テーブルへの結合が発生すると、結果が得
られるまでのレスポンスタイムが低下するため、現実に
は非定型業務での運用が難しくなる。そこで、アクセス
頻度が高いデータに関しては重複を許して蓄積するか、
元データのコピーである、スナップショットを持ったデ
ータベースを別途構築しておく。

【０００７】ところが、顧客購買パターン分析などの非
定型業務の場合、設計時に予めアクセスパターンを全て
予測することは困難であり、またユーザ数の増加、使い
方の変化が生じると、テーブル構造を変更したり、スナ
ップショットを追加する必要が出てくる。従来技術１に
は、蓄積されているデータの蓄積構造自体を自動で更新
する機能はない。またデータベースサーバが受け付けた
要求をログとして保存する機能はあるが、ログを分析
し、データ構造を変更するための情報を抽出する作業は
データベース管理者の手作業によるしかなく、従ってデ
ータベースのレスポンス低下を防ぐための管理負荷が増
大する。また、データベースが大規模化すると、手作業
のみでは適切なデータ構造を決定することが困難になる
ため、エンドユーザに対してレスポンス性能を保証する
ことが難しくなる。

【０００８】従来技術２は、スナップショットや、複数
のデータベースシステムを一括管理するためのデータ管
理ツールを提供する。しかしシステムの運用自体はシス
テム管理者の手作業により行われ、データ構造の変更を
自動化する手段を提供できないため、管理負荷の増加を
招く。また大規模データベースのデータ構造を適切に決
定することは困難である。

【０００９】

【課題を解決するための手段】本発明の望ましい第１の
実施形態においては、互いに依存関係を持つ１個以上の
属性からなる属性組をデータ参照命令から抽出する手段
と、前記抽出された属性組を蓄積する手段と、着目する
１個以上の属性を利用者が入力する手段と、上記蓄積し
たデータから、上記入力された属性を含む属性間の依存
関係の強さを算出する手段と、前記算出した依存関係の
強さを出力する手段を有する。

【００１０】第１の実施形態では、同時に用いられた属
性情報を蓄積、分析し、依存関係を抽出し、出力するこ
とが可能なため、どの様なテーブルを新たに作る際に必
要となる情報を利用者に提供することができる。

【００１１】本発明の望ましい第２の実施形態において
は、互いに依存関係を持つ１個以上の属性からなる属性
組をＳＱＬ文から抽出する手段と、前記抽出された属性
組を蓄積する手段と、着目する１個以上の属性を利用者
が入力する手段と、上記蓄積したデータから、上記入力
された属性を含む属性間の依存関係の強さを算出する手
段と、前記算出した依存関係の強さを用いて新たなテー
ブルを定義するＳＱＬ文を発行する手段を有する。

【００１２】第２の実施形態では、算出された属性間の
依存関係を用いて自動的に新しいテーブルを作成するこ
とができる。

【００１３】

【発明の実施の形態】以下、図面を用いて本発明の第１
の実施形態を説明する。図１はデータ管理装置１００の
構成とデータの流れを示している。図１において、１０
１、１０３はクライアント装置、１０２はデータベース
サーバ装置、１０４はデータ管理装置、１０５はＳＱＬ
解析装置、１０６は属性依存関係解析装置、１０７は入
力装置、１０８は解析結果出力装置、１０９は属性参照
情報蓄積装置であり、装置１０５、１０６、１０７、１
０８、１０９はデータ管理装置１０４に内包されてい
る。また１１０は各装置を接続するネットワークであ
る。

【００１４】またデータ管理装置が必要とする手段は、
クライアント装置、サーバ装置に分散して構築されてい
ても構わない。図２はクライアント装置とサーバ装置に
それぞれ実装したデータ管理装置２００の構成を示して
いる。図２において、２１１はサーバ装置、２０１、２
０２はクライアント装置、２０３、２０４はクライアン
ト装置に構築されたＳＱＬ解析装置、２０５はデータ管
理装置、２０６属性参照情報蓄積装置、２０７は属性依
存関係解析装置、２０８は入力装置、２０９は解析結果
出力装置である。装置２０６、２０７、２０８、２０９
はデータ管理装置２０５に内包されている。２１０は各
装置を接続するネットワークである。

【００１５】図３はデータベースサーバ装置に各手段が
構築されているデータ管理装置３００を示している。図
３において、３０１、３０２はクライアント装置、３０
３はデータベースサーバ装置、３０４はデータ管理装
置、３０５はＳＱＬ解析装置、３０６は属性依存関係解
析装置、３０７は入力装置、３０８は属性参照情報蓄積
装置、３０９は解析結果出力装置である。装置３０５、
３０６、３０７、３０８、３０９、３０９はデータ管理
装置３０４に内包されている。３１０は各装置を接続す
るネットワークである。

【００１６】各装置が提供する機能、装置間のデータの
流れは原理的に、装置１００、２００、３００に共通で
あるため、便宜上、本実施形態では図１を説明に用い
る。以下、図１に従って本実施形態の概要を説明する。

【００１７】クライアント装置１０１からデータベース
サーバ装置１０２に格納されたデータへの参照が発生す
ると、クライアント装置１０１から発行された参照命令
はデータベースサーバ装置１０２と、データ管理装置１
０４の両方に渡される。データベース装置１０２は受け
取った命令を処理し、結果をクライアント装置１０１へ
返す。データ管理装置１０４が受け取った命令は、まず
ＳＱＬ解析装置１０５によって命令中の属性参照情報が
抽出され、次に抽出された情報が属性参照情報蓄積装置
１０９に格納される。データが蓄積された時点で、利用
者が着目したい１個以上の属性、依存関係の強さの最小
値等のパラメータを入力装置１０７により指定すると、
属性依存関係解析装置１０６により、パラメータを満た
す属性間の依存関係が抽出される。

【００１８】図４はデータ管理装置１０４と接続された
データ表示装置４００を示している。

【００１９】図４００において、４０１はデータ管理装
置であり、図１中の装置１０４と同じものである。４０
２はデータ表示装置、４０３はしきい値入力装置、４０
４は解析結果表示装置、４０５は解析結果表示制御装
置、４０６は出力合成装置、４０７はメタデータ表示装
置、４０８はデータベースサーバ装置であり、図１中の
装置１０２と同じものである。なお、ここで言うメタデ
ータとは、データベースサーバ装置内の、データ構造の
定義情報を意味する。

【００２０】図６はデータベース装置１０２に蓄積され
ているデータ６００を示している。図６において、６０
１は部品名と、部品の値段、供給元の関係を示すテーブ
ル、６０２は供給元の所在地を表すテーブルを示してい
る。６０３は部品名と供給元の関係を表すテーブルを示
しているが、テーブル６０３の実体はデータベースサー
バ装置１０２にはなく、テーブル６０２とテーブル６０
３から仮想的に作ったものがユーザに提供される。ここ
では、テーブル６０１、６０２の様に実体があるものを
ベーステーブル、テーブル６０３のような仮想的なテー
ブルをビューと呼ぶ。通常、ユーザからはベーステーブ
ルとビューの違いを意識する必要はなく、クライアント
装置からは等価に見える仕組みになっている。

【００２１】以下の説明では、単にテーブルとした場
合、ベーステーブルもしくはビューのどちらかを指すこ
ととする。

【００２２】図７はクライアント装置１０１からデータ
ベースサーバ装置１０２に渡される１回分の命令７００
を示している。７００は、データ６００にあるテーブル
６０１、６０２を参照し、供給元が東京にある部品の名
前を検索するための命令である。

【００２３】図８はクライアント装置１０１からデータ
ベースサーバ装置１０２に渡される命令８００を示して
いる。命令８００は命令７００と同様の意味を持つが、
参照するのはビュー６０３である点が異なる。以下の説
明では、６０１、６０２、６０３をそれぞれテーブル
Ｓ、Ｐ、ＳＰと呼ぶ。

【００２４】図１５はＳＱＬ解析装置１０５がクライア
ント装置１０１からの命令を解析した結果であるデータ
１５００を示しており、属性参照情報蓄積装置１０９に
蓄積されている。５０１は解析を行った際、属性参照情
報蓄積装置１０９が命令に割り振った識別子、５０２は
解析した命令が含んでいた属性名称を示している。属性
名称は、テーブル名と属性名の組からなり、例えばＳ．
ＣＩＴＹはテーブルＳにある属性ＣＩＴＹを意味する。
データ１５００は過去同時に参照された属性の組を表し
ており、例えば同じ識別子を持つＳ．ＣＩＴＹとＰ．Ｐ
ＡＲＴが一回の命令で同時に参照されたことを意味す
る。

【００２５】図９は属性依存関係解析装置１０６の解析
結果である、データ９００を表している。ここで１個以
上の属性組Ｘに着目したとき、同時に１個以上の属性組
Ｙが参照されるという属性間の依存関係はルールＸ→Ｙ
で表され、Ｘを条件部、Ｙを結論部と呼ぶことにする。
データ９００の各行は１個のルールであり、９０１は条
件部、９０２は結論部、９０３は条件部と結論部の依存
関係の強さを示している。

【００２６】図１１はデータ表示装置４００の出力１１
００を示している。出力１１００は、データ９００中の
ルールと、データベースサーバ装置１０２に格納されて
いるテーブル定義情報との関連性を表している。１１０
１はテーブルＰの定義情報で、属性Ｐ．Ｐ＃、Ｐ．ＰＡ
ＲＴ、Ｐ．ＣＯＳＴ、Ｐ．ＳＵＰＰＬＩＥＲが一つのベ
ーステーブルとして定義されていることを意味する。１
１０２はテーブルＳの定義情報であり、属性Ｓ．Ｓ＃、
Ｓ．ＳＵＰＰＬＩＥＲ、Ｓ．ＣＩＴＹが一つのベーステ
ーブルとして定義されていることを意味する。１１０
３、１１０４はそれぞれデータ９００にあるルールを表
している。１１０３、１１０４のそれぞれの左側は条件
部、右側は結論部である。上下段を結ぶ矢印は、ルール
に現れる各属性がどのベーステーブル中の属性を参照し
ているかを表している。

【００２７】図１３はデータ９００中のルールがビュー
を参照している場合の、データ表示装置４００の出力１
３００を示している。出力１３００は、データ９００と
して格納されている属性間の依存関係と、データベース
サーバ装置１０２に格納されているテーブル、及びビュ
ー定義情報との関連性を表している。１３０１、１３０
２はベーステーブルの定義情報であり、出力１１００中
の１１０１、１１０２と同じものである。１３０３はビ
ューの定義情報、１３０４、１３０５はデータ９００に
あるルールを表している。例えば、１３０５はＳＰ．Ｐ
ＡＲＴ→ＳＰ．ＣＩＴＹの関係なり、ＳＰ．ＰＡＲＴと
ＳＰ．ＣＩＴＹは１個のビュー、１３０３を参照してい
るが、ビュー１３０３の実体はベーステーブル１３０
１、１３０２のデータを抜き出し、統合したものである
ことが分かる。

【００２８】出力１１００、１３００により、参照頻度
が高く、その際に同時に参照されるような複数の属性が
別々のベーステーブルにあることが分かる。そのため、
データベースのレスポンスを向上させたい場合、どの属
性を抜き出して新たなベーステーブルを作成すれば良い
のかを、データベース管理者は容易に知ることができ
る。

【００２９】このように、データ管理装置１０４に、Ｓ
ＱＬ解析装置１０５、属性依存関係解析装置１０６、属
性参照情報蓄積装置１０９を設けることにより、ベース
テーブル、ビューへの参照パターン調べ、データベース
管理に必要な情報を利用者へ提供する点に本実施形態の
特徴がある。

【００３０】以下図１６に従い、本実施形態の処理の詳
細を説明する。

【００３１】図１６は属性の参照情報を蓄積する処理の
流れを示したものである。処理１６０１で、クライアン
ト装置からデータベースサーバ装置へ渡されたデータ参
照命令と同じものが、データ管理装置に渡される。また
データ参照命令はＳＱＬで記述されている。

【００３２】処理１６０２によりデータ参照命令中のＳ
ＥＬＥＣＴ節から、属性情報を抽出する。なお、ここで
言う属性情報とは、テーブル名、属性名から一意に定ま
る属性の名称である。ＳＥＬＥＣＴ節にはどのテーブル
中の、どの属性を結果として受け取るかが「ＳＥＬＥＣ
Ｔテーブル名．属性名」という形式で記述される。ま
たテーブル名が明らかなときは単に「ＳＥＬＥＣＴ属
性名」という形式で記述される。

【００３３】処理１６０３ではデータ参照命令中のＦＲ
ＯＭ節からテーブル名を抽出する。

【００３４】ＦＲＯＭ節にはどのテーブルを用いて検索
を行うかが、「ＦＲＯＭテーブル名」という形式で記
述される。

【００３５】処理１６０４ではＷＨＥＲＥ節から属性情
報を抽出するための条件判定を行う。

【００３６】通常ＷＨＥＲＥ節には検索条件が記述さ
れ、テーブル名、属性名のどちらも含まれうるが、また
ＷＨＥＲＥ節がＳＥＬＥＣＴ〜ＦＲＯＭ〜ＷＨＥＲＥ等
の一連の命令を含む、入れ子構造も許されているので、
処理１６０４では入れ子構造の判定を行う。

【００３７】処理１６０４で入れ子構造が検出された場
合、内側のブロックに含まれる命令の解析をするため処
理１６０２に戻る。処理１６０５で入れ子構造が検出さ
れない場合、処理１６０５で属性情報の抽出を行う。

【００３８】なお、ＳＱＬはこの他のコマンドを扱うこ
とが可能だが、説明の便宜上、本実施形態ではＳＥＬＥ
ＣＴ、ＷＨＥＲＥ、ＦＲＯＭ節をのみを解析対象とす
る。

【００３９】処理１６０６では抽出した属性名称と、Ｓ
ＥＬＥＣＴ、ＦＲＯＭ、ＷＨＥＲＥ節の位置関係から、
属性の指定でテーブル名が省略されている場合に、テー
ブル名と属性名を対応づけ、さらに重複する属性を削除
する。

【００４０】処理１６０７ではデータ１５００の形式で
蓄積する。

【００４１】データベースシステムの運用を続けると、
処理１６００によりデータ管理装置１０４内に属性参照
に関する情報が蓄積されていく。利用者は任意の時点
で、蓄積された属性参照情報の解析を行うことができ
る。また蓄積データ量に応じて属性依存関係の解析処理
を自動的に起動することもできる。

【００４２】図１７は処理１６００で蓄積されたデータ
から、属性間の依存関係が強いものをルールとして抽出
する、解析処理１７００を示している。依存関係の強さ
は、条件部が、クライアントから発行されるデータベー
ス参照命令１回あたりに出現する確率と、条件部の条件
付きで結論部が出現する確率の関数で評価されるものと
する。ここでは説明の便宜上、前者の確率をカバー率、
後者をヒット率と呼ぶ。

【００４３】処理１７０１では、解析処理で利用者が着
目する１個以上の属性が入力される。

【００４４】着目する属性は利用者が与えても良いし、
例えば出現頻度が大きい属性組を自動的に与えても良
い。

【００４５】処理１７０２では、抽出される依存関係が
必ず満たすべき条件として、カバー率の最小値が入力さ
れる。また必要ならば、条件部が含みうる属性数の最大
値を指定する。

【００４６】処理１７０３から処理１７１０のループで
実際の依存関係の探索処理が行われる。まずどの様な属
性が存在するかを調べ、次にその属性の組合せについて
調べる。終了条件は、最小カバー率を満たす条件部の候
補が無くなった場合か、条件部が含む属性数が最大値を
超えた場合である。

【００４７】まず、処理１７０３では前回の探索で、指
定された条件を満たす属性組があったかを判定する。残
っている場合は処理１７０４に、そうでない場合には処
理１７１０に移る。処理１７０２から移ってきた最初の
判定では、無条件で次の処理１７０４に移る。

【００４８】処理１７０４では、前回の探索結果を元に
次の条件部の候補を作成する。なお、処理１７０１で指
定された属性が、条件部になるのか、結論部になるのか
により条件部の候補の作り方は異なる。条件部を指定し
た場合は、指定された属性を含む全ての属性組が条件部
の候補となり、このとき結論部となるべき１個の属性の
候補も同時に探索される。

【００４９】例えば着目する条件部として｛Ａ｝が指定
されていて、探索の結果｛Ｂ｝，｛Ｃ｝，｛Ｄ｝という
３つの属性が最小カバー率を満たしているものとする。
またヒット率の大きさを考慮して、この｛Ａ｝→Ｂ、
｛Ａ｝→Ｃを依存関係として採択したとする。このと
き、｛Ａ，Ｂ｝→Ｄ，｛Ａ，Ｃ｝→Ｄが次の探索の候補
となる。

【００５０】結論部が指定された場合は、結論部は固定
して、これにつながる条件部を探索する。

【００５１】例えば結論部として｛Ａ｝が指定されてい
て、探索の結果｛Ｂ｝，｛Ｃ｝，｛Ｄ｝が最小カバー率
を満たしていたものとする。このときは、｛Ｂ，Ｃ｝，
｛Ｃ，Ｄ｝，｛Ｂ，Ｄ｝が次の条件部の候補となる。

【００５２】処理１７０５では探索候補のカバー率を見
て、実際に探索すべきかどうかを決定する。今、ルール
Ｘ→Ｙが見つかっていて、Ｘの生起確率（カバー率）Ｐ
（Ｘ）、Ｙの生起確率Ｐ（Ｙ）、ＸとＹの同時生起確率
Ｐ（Ｘ＆Ｙ）が与えられているものとする。このとき、
Ｘに新たな属性を１個加えた、条件部の条件部の候補
Ｘ’のカバー率の最大値は、Ｐ（Ｘ＆Ｙ）／Ｐ（Ｙ）で
算出することができる。Ｐ（Ｙ）は蓄積データから、簡
単に見つけることができ、またＰ（Ｘ＆Ｙ）はヒット率
を算出するため、前回の探索で常に探索されるので、こ
れを利用することができる。また条件部カバー率は、組
合わせる属性の数が多くなるほど単調に減少する。従っ
て、もし、ある条件部の候補のカバー率の最大値が、予
め指定されている最小カバー率よりも小さければ、この
候補の探索を省略することができる。処理１７０６で
は探索を行い、探索候補のカバー率、ヒット率を算出す
る。

【００５３】処理１７０７では探索した結果を元に評価
し、ルールとして出力するべきかどうかを決定する。例
えば、カバー率は最小カバー率以上あり、かつルールＸ
→Ｙのヒット率Ｐ（Ｙ｜Ｘ）が、Ｙ単独の生起確率Ｐ
（Ｙ）以上である場合は、有益な情報を含む属性の関係
であると見なす。

【００５４】処理１７０８では算出されたルールを蓄積
する。

【００５５】処理１７０９では、条件部が含む属性の数
が、利用者の指定した最大値に達したかどうかを判定
し、達していないならば処理１７０３に移る。ただし何
も指定されていない場合は、無条件で処理１７０３に移
る。それ以外の場合は探索を終了する。

【００５６】次に、表示装置４００の処理の詳細を図１
８に従って説明する。

【００５７】図１８はルールを表示する処理１８００を
示している。処理１８０１で利用者が表示したいルール
の条件を入力する。ここではルール評価値の最低値、ル
ールの重複削除処理を制御するパラメータ、及び表示す
るルールの最大数が入力される。処理１８０２では処理
１７００で抽出、蓄積しておいたルールを読み込む。処
理１８０３では重複するルールを省略する。処理の例と
しては、結論部が同じルール群の条件部に含まれている
属性組の包含関係を調べ、あるルールの条件部中の属性
組Ｘと、別のルールの属性組Ｘ’が、Ｘ⊂Ｘ’の関係に
あるとき、ルールの評価値が低い方を省略するといった
方法がある。ただし、ルール評価値の最低値が評価値が
低くなっても良いから、できるだけ多くの属性を条件組
に含むルールが欲しい場合は、処理１８０１の重複削除
処理制御パラメータの入力で指定しておく。処理１８０
４ではデータベースサーバ装置１０２からテーブル定義
情報を表す、メタデータを読み込む。処理１８０５では
メタデータのテーブル定義情報と、重複省略処理後のル
ール群を関連付けて、出力１１００、１３００の形式で
表示する。

【００５８】このように、頻繁に使われる属性組と、デ
ータベースサーバ中に定義されているテーブルの関係を
用いて、新たなテーブルを作成する上で有用な情報を利
用者に提示できる点に本実施例の特徴がある。

【００５９】次に、本発明の第２の実施形態を説明す
る。図５は本実施形態で説明する、データ管理装置５０
０の構成とデータの流れを示している。５０１はデータ
管理装置、５０２はテーブル作成装置、５０３はパラメ
ータ入力装置、５０４はテーブル作成制御装置、５０５
はテーブル間依存関係解析装置、５０７はデータベース
サーバ装置である。装置５０１は図１中のデータ管理装
置１０４と、装置５０７はデータベースサーバ装置１０
２と同じものである。

【００６０】図１０はデータ管理装置５００の出力の結
果、データベースサーバ装置５０７に新たに作成された
テーブルを示している。

【００６１】以下、図５に従って本実施形態の概要を説
明する。パラメータ入力装置５０３から、新規テーブル
を作成するための基準値を利用者が入力する。テーブル
作成制御装置５０４は、装置５０３で入力された値を用
いてテーブル間依存関係解析装置５０６を制御する。ま
た、テーブル間依存関係解析装置５０６には、データ管
理装置５０１から属性間の依存関係を表すルールが、デ
ータベースサーバ装置５０７からメタデータが渡され
る。テーブル間依存関係解析装置５０６は、現在あるテ
ーブルに対して、過去どの様なパターンでアクセスされ
ていたかを解析し、結果をテーブル定義変更装置５０２
に渡す。テーブル定義変更装置５０２はテーブル定義を
変更するためのＳＱＬ命令をデータベースサーバ装置５
０７に対して発行する。

【００６２】データ管理装置５０１とデータベースサー
バ装置５０７から与えられるメタデータとルールから、
図１１に示すような関係が得られる場合の、装置５００
の実行結果を図１２に示す。図１１は、別々のベーステ
ーブルにある属性Ｐ．ＰＡＲＴとＰ．ＣＩＴＹが同時に
参照されることが多い、というアクセスパターンを表し
ている。装置５００はアクセスパターンから、Ｐ．ＰＡ
ＲＴとＳ．ＣＩＴＹを持つベーステーブルを作成するた
めの命令をデータベースサーバ装置５０７へ発行する。
図１２中、１２０１、１２０２は既存のベーステーブル
定義、１２０３、１２０４は同時に参照されることが多
い属性組を表すルール、矢印はルールが含む属性がどの
ベーステーブルにあるのかを示すリンク情報、１２０５
は新しく作られたベーステーブルである。

【００６３】データ管理装置５０１とデータベースサー
バ装置５０７からえられるメタデータとルールから、図
１３に示すような関係が得られる場合の、装置５００の
実行結果を図１４に示す。図１３はビューに関する定義
を含んでおり、この場合は新しいテーブルが作成される
だけでなくビューの定義が変更される。１４０１、１４
０２は既存のベーステーブル定義、１４０３は変更され
たビュー定義、１４０４、１４０５は同時に参照される
ことが多い属性組を表すルール、矢印はルールビュー、
ベーステーブルに含まれる属性間の関係を示すリンク情
報、１４０６は新しく作られたベーステーブルである。
図１３では、ビュー１３０３は二つのベーステーブルを
参照していたが、装置５００の実行結果、ビュー１４０
４は新たに作られた一つのテーブルを参照するように変
更されている。

【００６４】以下図１９に従って、本実施形態の処理の
詳細を説明する。

【００６５】処理１９０１では装置５０３より、ルール
評価値の最低値が、テーブル定義変更のしきい値、ルー
ル重複削除処理の方法の指定が入力される。処理１９０
２では装置５０１よりルールが入力される。処理１９０
３では、入力されたしきい値以上の評価値を持つルール
を対象として、重複するルールの削除処理が行われる。

【００６６】この削除処理は、処理１８００中の１８０
３と同様である。処理処理１９０４では装置５０７より
メタデータが入力される。処理１９０５ではルールとメ
タデータに含まれる属性を調べ、図１１、１３に示す関
係を算出する。処理１９０６では、処理１９０５で算出
した結果から、追加定義すべきテーブルを決定し、その
ための命令をデータベース装置５０７に発行する。ただ
し、作成に用いたルールが既存のビュー定義に関係があ
る場合、処理１９０８においてこのビュー定義を変更す
る命令をサーバ装置に発行する。

【００６７】このように、頻繁に使われる属性組と、デ
ータベースサーバ中に定義されているテーブルの関係を
用いて、利用者のデータへのアクセスパターンに適した
テーブル定義を自動生成する点に本実施形態の特徴があ
る。

【００６８】

【発明の効果】以上、本発明ではデータ参照命令解析装
置、属性参照情報蓄積装置、属性依存関係解析装置を設
けることにより、データ参照パターンを調べ、データベ
ース管理に必要な情報を利用者へ提供すると共に、エン
ドユーザのアクセスパターンに適したデータ構造を自動
生成する。これによりシステム管理者の負荷を低減、ア
クセススピードの向上を図ることができる。

【図面の簡単な説明】

【図１】データ管理装置の全体構成である。

【図２】データ管理装置の全体構成である。

【図３】データ管理装置の全体構成である。

【図４】データ表示装置の構成である。

【図５】テーブル作成装置の構成である。

【図６】データベースサーバ装置に蓄積されているデー
タである。

【図７】クライアント装置から発行されるデータ参照命
令である。

【図８】クライアント装置から発行されるデータ参照命
令である。

【図９】データ管理装置によるデータ参照パターン解析
結果である。

【図１０】テーブル作成装置により定義されたデータで
ある。

【図１１】データ表示装置の出力である。

【図１２】データ表示装置の出力である。

【図１３】データ表示装置の出力である。

【図１４】データ表示装置の出力である。

【図１５】データ管理装置により蓄積されるデータ参照
ログである。

【図１６】データ参照パターン蓄積処理である。

【図１７】蓄積されたデータ参照パターンの解析処理で
ある。

【図１８】データ表示装置の表示処理である。

【図１９】テーブル作成装置のテーブル定義処理であ
る。

フロントページの続き (72)発明者前田章神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内

Claims

【特許請求の範囲】

【請求項１】データ参照命令を発行する１個以上のクラ
イアント装置と、参照命令を解釈し実行する１個以上の
データベースサーバ装置からなり、前記クライアント装
置と前記サーバ装置がネットワークで接続されているデ
ータベースシステムにおいて、互いに依存関係を持つ１
個以上の属性からなる属性組を参照命令から抽出する手
段と、前記抽出された属性組をネットワークに接続され
たデータベース管理装置に蓄積する手段と、着目する１
個以上の属性を利用者が入力する手段と、上記蓄積した
データから、上記入力された属性を含む属性間の依存関
係の強さを算出する手段と、前記算出した依存関係の強
さをに対して出力する手段からなることを特徴とするデ
ータ管理装置。
【請求項２】請求項１に記載のデータ管理装置におい
て、互いに依存関係を持つ１個以上の属性からなる属性
組をデータ参照命令から抽出する手段と、前記抽出され
た属性組を蓄積する手段と、着目する１個以上の属性を
利用者が入力する手段と、上記蓄積したデータから、上
記入力された属性を含む属性間の依存関係の強さを算出
する手段と、前記算出した依存関係の強さを出力する手
段は、ネットワークに接続されたデータベース管理装置
に構築されていて、前記データベース管理装置は上記ク
ライアント装置と上記サーバ装置の間の通信内容を中継
する手段を備えることを特徴とするデータ管理装置。
【請求項３】請求項１に記載のデータ管理装置におい
て、上記互いに依存関係を持つ１個以上の属性からなる
属性組をデータ参照命令から抽出する手段は上記クライ
アント装置上にあり、前記抽出された属性組を蓄積する
手段と、上記着目する１個以上の属性を利用者が入力す
る手段と、上記蓄積したデータから、上記入力された属
性を含む属性間の依存関係の強さを算出する手段と、前
記算出した依存関係の強さを出力する手段は、ネットワ
ークに接続されたデータベース管理装置に構築されてい
ることを特徴とするデータ管理装置。
【請求項４】請求項１に記載のデータ管理装置におい
て、互いに依存関係を持つ１個以上の属性からなる属性
組をデータ参照命令から抽出する手段と、前記抽出され
た属性組を蓄積する手段と、着目する１個以上の属性を
利用者が入力する手段と、上記蓄積したデータから、上
記入力された属性を含む属性間の依存関係の強さを算出
する手段と、前記算出した依存関係の強さを出力する手
段は、データベースサーバ装置に含まれていることを特
徴とするデータ管理装置。
【請求項５】データ参照命令を発行する１個以上のクラ
イアント装置と、参照命令を解釈し実行する１個以上の
データベースサーバ装置からなり、前記クライアント装
置と前記サーバ装置がネットワークで接続されているデ
ータベースシステムにおいて、互いに依存関係を持つ１
個以上の属性からなる属性組を参照命令から抽出する手
段と、前記抽出された属性組を蓄積する手段と、着目す
る１個以上の属性を利用者が入力する手段と、上記蓄積
したデータから、上記入力された属性を含む属性間の依
存関係の強さを算出する手段と、前記算出した依存関係
の強さを用いて新たなテーブルを定義するデータ参照命
令を発行する手段とからなることを特徴とするデータ管
理装置。