JP2019144679A - データベース装置、データ管理方法、及びコンピュータ・プログラム - Google Patents

Abstract

【課題】利用者がデータ分析をより効率的に実行することができるデータベース装置などを提供する。【解決手段】データベース装置は、データを記憶するテーブルを有するデータ記憶部に関する問合せを受け付ける問合せ処理部と、問合せ処理部が受け付けた問合せに関連するテーブルへのアクセスの傾向を表すモデルを記憶する傾向記憶部と、問合せ処理部が受け付けた他の問合せに関連するテーブルと、傾向記憶部に記憶されたモデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する傾向判断部と、を備える。【選択図】 図１

Description

本開示は、データベース装置等に関する。

多様なデータを管理するために、データベースなどのデータ管理システムが用いられている。データベースに関連して、例えば、以下のような技術が知られている。

例えば、特許文献１には、複数のテーブルを含むデータベースにおいて、各テーブルからカラムを選択してカラム対を特定し、カラム対のうち、一方のカラムが他方のカラムの外部キーであるか否かを推定する技術が記載されている。特許文献２には、データベースに蓄積されたデータを用いてデータマイニングを実行する際に、データベースへのアクセス処理を解析し、同じアトミックな論理作業単位に関連するカラムの組合せを、分析対象として生成する技術が記載されている。特許文献３には、データベースへの問合せ文におけるカラムの出現位置に得点を付与し、その得点を統計処理することで、予め設定されたルールにとって有用なカラムを特定する技術が記載されている。

特開２０１４−１８６４８８号公報 特開２０１３−１２５４２９号公報 特許第３００６５２５号公報

データベースには、多様なデータが格納されることがあり、データベースに登録されたデータを組み合わせることで新たな知見が得られることがある。一方、複数の利用者がデータベースにデータを格納する場合、各利用者がデータベースに格納されたデータの全容や、データの構造を把握することは難しい可能性がある。この場合、例えば、データベースに登録されたデータやその組合せを利用して、利用者がデータ分析を実行することが容易ではない、という問題がある。

これに対して、特許文献１、特許文献２に記載された技術は、データベースへのアクセスを処理する何らかのプログラムを解析することで、データ間の関係を特定することを企図した技術であり、そのようなプログラムが予め与えられない状況に適用することはできない。また、特許文献３に記載された技術は、データベースに対する問合せに含まれるカラムの位置に基づいて、ドメイン知識としてのカラムを特定することを企図した技術であり、上記問題を解決可能な技術ではない。

本開示にかかる技術は、上記のような事情を鑑みて開発されたものである。即ち、本開示の目的の一つは、利用者がデータ分析をより効率的に実行することを可能とする技術を提供することにある。

上記目的を達成すべく、本開示の１態様にかかるデータベース装置は、以下のように構成される。即ち、本開示の１態様にかかるデータベース装置は、データを記憶するテーブルを有するデータ記憶部に関する問合せを受け付ける問合せ処理部と、問合せ処理部が受け付けた問合せに関連するテーブルへのアクセスの傾向を表すモデルを記憶する傾向記憶部と、問合せ処理部が受け付けた他の問合せに関連するテーブルと、傾向記憶部に記憶されたモデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する傾向判断部と、を備えるよう構成される。

本開示の他の１態様にかかるデータ管理方法は、データを記憶するテーブルを有するデータベースに関する問合せを受け付け、受け付けた問合せに関連するテーブルへのアクセスの傾向を表すモデルを記憶し、他の問合せに関連するテーブルと、記憶されたモデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案することを含む。

また、同目的は、上記構成を有するデータベース装置、データ管理方法等をコンピュータによって実現するコンピュータ・プログラム（データ管理プログラム）、及び、そのコンピュータ・プログラムが格納されているコンピュータ読み取り可能な記録媒体等によっても達成される。

即ち、本開示の更に他の１態様にかかるデータ管理プログラムは、データを記憶するテーブルを有するデータベースに関する問合せを受け付ける問合せ処理と、受け付けた問合せに関連するテーブルへのアクセスの傾向を表すモデルを記憶する記憶処理と、他の問合せに関連するテーブルと、記憶されたモデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する傾向判断処理とを、データベース装置として機能するコンピュータに実行させる。また、本開示の１態様にかかる記録媒体には、上記したコンピュータ・プログラムが記録されてもよい。

本開示によれば、利用者がデータ分析をより効率的に実行することができる。

図１は、本開示の第１実施形態にかかるデータベース装置の機能的な構成を例示するブロック図である。 図２は、本開示の第１実施形態にかかるデータベース装置の動作を例示するフローチャート（その１）である。 図３は、本開示の第１実施形態にかかるデータベース装置の動作を例示するフローチャート（その２）である。 図４は、本開示の第１実施形態にかかるデータベース装置が問合せを処理する動作の具体例を示す説明図（その１）である。 図５は、本開示の第１実施形態にかかるデータベース装置が問合せを処理する動作の具体例を示す説明図（その２）である。 図６は、本開示の第１実施形態にかかるデータベース装置が、利用者に対して提示する提案情報を例示する説明図である。 図７は、本開示の第２実施形態にかかるデータベースシステムの機能的な構成を例示するブロック図である。 図８は、本開示にかかる各実施形態を実現可能なハードウェア装置の構成を例示する説明図である。

＜実施形態の概要＞
各実施形態の詳細な説明に先立って、本開示における技術的な検討事項等について説明する。

ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）という言葉に象徴されるように、多くのデバイスが通信ネットワークに接続されるようになった。典型的には、そのようなデバイスには、データを収集可能な各種センサー（例えば、温度、湿度、振動、重量、人感センサーなど）が設けられる。これらのセンサーは、例えば、定期的にデータを収集して、通信ネットワークを介してデータセンターに送信する。データセンターにおいては、収集したデータをデータベースに記憶することで、後の活用に備えてデータを蓄積する。なお、データセンターは、例えば、データベースなどを用いて、各種のデータを蓄積及び管理するシステム（又は、そのようなシステムが稼働する物理的及び仮想的な施設）である。

このようなデバイスは、今後も増加することが予想される。デバイスの増加に伴い、収集されるデータ量が増加するとともに、そのデータを表す表現形式も増加することが予想される。例えば、センサーのベンダーや、センサーの利用目的によって、温度の表現形式（例えば、華氏又は摂氏）が、センサーごとに異なる状況が想定される。同様に、例えば、重量の表現形式として、ｋｇ単位、ｍｇ単位などが用いられる状況が想定される。即ち、同じ計測対象に関するセンサーデータであっても、表現形式が異なる状況が生じ得る。

また、こうしたセンサーデータを活用する際、センサーデータと、他のデータとを組み合わせることがある。具体例として、生鮮食品を扱う店舗が、気温センサーのデータと、売上データとを組み合わせることで気温ごとの売れ筋の商品を分析し、天気予報に基づいて仕入れを行うことで、欠品による売上ロスや過剰在庫の最小化を図ることが考えられる。

上記した例のように、センサーを搭載したデバイスの増加や、収集されたデータの分析に関する幅広いニーズなどから、様々なデータソース（例えば、センサーや既存システムのデータなどの情報源）からデータを集めて分析を行う基盤としてのデータベース（分析用データベース）が構築されるようになった。

このような分析用データベースについては、（ｉ）データベースの利用者が、蓄積されたデータをすべて把握しているとは限らない、（ｉｉ）データベースに蓄積されたデータの表現形式が統一されているとは限らない、という傾向がある。

上記（ｉ）の具体例として、例えば、複数の利用者（データを活用して分析を行う複数の担当者）が、それぞれ自身の分析に有用と判断したデータソースからデータを収集することにより、各利用者がデータベースに格納されたデータの全容を把握することが困難になる状況が考えられる。このような状況では、例えば、同じ内容のデータが異なる名前（名称）で重複して収集されていることもありえる。

上記（ｉｉ）の具体例としては、例えば、データを収集したセンサーによって、温度の表現形式が異なる（例えば、あるセンサーは「摂氏」を用い、別のセンサーは「華氏」を用いる）状況が考えられる。また、別の具体例として、あるデータベースにおいて、「名前」のデータを格納する列（カラム）が、あるテーブルでは「名前」列であり、別のテーブルでは「氏名」列であり、更に別のテーブルでは「ＮＡＭＥ」列である、という状況が考えられる。上記（ｉｉ）のような状況は、例えば、多様なデータソースからデータを収集した際に、データソースにおける表現形式をそのまま用いて、収集したデータをデータベースに蓄積することにより発生する。

こうした状況は、利用者がデータを活用することを困難にする可能性がある。具体的には、例えば、以下のような課題が生じ得る。即ち、データベースを用いてデータ分析を実行する際、分析の目的に有用なデータがデータベースに格納されているにもかかわらず、利用者がそのデータの存在を認識できない可能性がある。また、仮に、利用者が有用そうなデータを認識したとしても、そのデータを、利用者自身が使おうとしているデータとどのように組み合わせることが適切かわかりにくい可能性がある。

上記したように、多様なデータソースから収集されたデータを組み合わせることで、有用な知見が得られることがある。データベースにおいては、こうしたデータの組合せは、例えば、「結合（ｊｏｉｎ）」と呼ばれる操作（結合操作）により行われる。結合操作では、例えば”顧客．顧客ＩＤ ＝ 売上．購入者”のように２つのデータソース（例えば、リレーショナルデータベースにおけるテーブル）間の関係を結合条件として与える。この例は、顧客表（顧客テーブル）における「顧客ＩＤ」列の値と、売上表（売上テーブル）における「購入者」列の値とが等しいものを関連付ける操作を表す。

例えば、テーブルを構成するデータ形式（例えば、テーブルや列の名前）が体系的に管理されている場合、データベースの利用者は、例えば、おおよそのテーブルの内容を予想して、データを結合する条件を記述することができる。しかし、前述した傾向を持つデータベースでは、ある利用者が（例えば他の利用者が収集した）有用そうなデータを見つけたとしても、例えば同じような値のデータを含む列が複数存在するような状況が想定される。一具体例として、あるテーブルに、顧客を特定する識別子（顧客ＩＤ（Ｉｄｅｎｔｉｆｉｅｒ））がＣＩＤ（Ｃｕｓｔｏｍｅｒ ＩＤ）という名前で格納され、「ＡＩＤ」や「ＢＩＤ」などの名前で、ＣＩＤと同じような値を含む列があるような状況が想定される。そのような場合、分析に有用なデータが存在していても利用者（分析者）がそのデータを活用できないような状況が発生する。

これに対して、本開示においては、対象データベースに格納されているデータや、そのデータの形式に対して十分な知識を有さず、当該データベースを用いた分析が不慣れな利用者を支援可能な技術が提供される。以下において説明する、本開示にかかる技術が実現されたデータベースシステムは、例えば、あるデータベースにおける問合せ（クエリ）の履歴などの情報から、このデータベースにおける分析処理のモデル（分析を行う処理の流れ（過程）を表現したモデル）を構築する。かかるデータベースシステムは、このモデルを利用することで、利用者に対して、そのデータベースに関する問合せを提案する。

具体的には、本開示にかかるデータベースシステムは、例えば、各利用者のデータベースに対するアクセス（問合せ等）の傾向を記憶するよう構成されてよい。ある利用者によって、記憶されている傾向に沿ったアクセスが行われた場合、本開示にかかるデータベースシステムは、その記憶された傾向に従い、その利用者に対して次のステップ（例えば、問合せ）を提案するよう構成されてよい。より具体的には、データベースシステムは、例えば、利用者に対して以下のような提案を提示するよう構成されてよい。即ち、本開示にかかるデータベースシステムは、例えば、同一セッション内でテーブルのアクセス順序を記憶し、同一の順序によるアクセスが行われたときに、次にアクセスするテーブルを提案してもよい。例えば、本開示にかかるデータベースシステムは、ある利用者がテーブルＡ、テーブルＢ、テーブルＣ、テーブルＤの順でテーブルにアクセスした際、そのアクセス順序を記憶する。そして、本開示にかかるデータベースシステムは、例えば、別の利用者がテーブルＡ、テーブルＢの順でテーブルにアクセスした際、その利用者に対して次に確認すべきテーブルとしてテーブルＣを提案してもよい。これにより、例えば、別の利用者がテーブルＣに含まれるデータの存在を認識していない場合であっても、テーブルＣに格納されたデータの利用を、利用者に提案することができる。

また、本開示にかかるデータベースシステムは、例えば、テーブル間の関連性を記憶し、他の利用者にこれを提案するよう構成されてもよい。例えば、本開示にかかるデータベースシステムは、ある利用者が、”Ａ．ＣＩＤ ＝ Ｂ．顧客ＩＤ”（Ａ表とＢ表とにおいて、Ａ表のＣＩＤ列とＢ表の顧客ＩＤ列とに同じ値が設定されている行を関連付ける）を条件として結合操作を行った際、このテーブル間の関連性を記憶してもよい。そして、本開示にかかるデータベースシステムは、例えば、別の利用者がテーブルＡ又はテーブルＢにアクセスした際、その利用者に対して、上記の条件によるもう一方の表との結合を提案してもよい。これにより、例えば、別の利用者に対して、有用なデータの組み合わせ方を提案することができる。上記のように構成された本開示にかかるデータベースシステムを用いることで、利用者は、例えば、その利用者が十分な知識を有さないデータベースにおいても、効率よくデータ分析を行うことが可能になる。

以下、本開示にかかる技術について、具体的な実施形態を用いて更に詳細に説明する。なお、以下の実施形態（及びその変形例）の構成は一つの具体例であり、本開示にかかる技術の範囲は、それらには限定されない。以下に示す各実施形態における構成要素の分割（例えば、機能的な単位による分割）は、その実施形態を実現可能な一例である。各実施形態を実現可能な構成は、以下の例示に限定されず、様々な構成が想定され得る。以下の各実施形態を構成する構成要素は、更に分割されてもよく、また、以下の各実施形態を構成する１以上の構成要素が統合されてもよい。以下に例示する各実施形態が１以上の物理的装置、仮想的装置、及びその組合せを用いて実現される場合、１以上の構成要素が１以上の装置により実現されてもよく、１つの構成要素が複数の装置を用いて実現されてもよい。

なお、本開示に係る技術の一態様であるデータ管理方法は、以下の各実施形態におけるデータベース装置の動作として実現されてもよい。また、本開示に係る技術の一態様であるコンピュータ・プログラムは、以下の各実施形態におけるデータベース装置において、本開示に係る技術の一態様であるデータ管理方法を実行するプログラムとして実装されてもよい。

＜第１実施形態＞
以下、本開示にかかる技術の第１の実施形態について説明する。本実施形態においては、本開示にかかる技術が実現されたデータベース装置を具体例として、本開示にかかる技術について具体的に説明する。なお、本開示におけるデータベース装置は、単体の装置として実現されてもよく、複数の装置を用いたデータベースシステムとして実現されてもよい。なお、本実施形態におけるデータベース装置を実現可能な具体的なハードウェア構成については、後述する。

［構成］
図１は、本実施形態におけるデータベース装置１００の機能的な構成を例示するブロック図である。図１に例示するように、本実施形態におけるデータベース装置１００は、クライアント２００と、通信可能に接続される。

クライアント２００は、利用者がデータベース装置１００に対して問合せ（ＳＱＬなどの問合せ言語を用いたデータの挿入、更新、参照などのクエリ）を発行する装置である。クライアント２００は、例えば、コンピュータなどの通信機能を備えた情報処理装置により構成されてもよい。クライアント２００が発行する問合せは、特定の問合せ言語（例えばＳＱＬ）に限定されず、適切な問合せ言語が用いられてよい。データベース装置１００と、クライアント２００とを接続する通信ネットワークは特に限定されず、適切な通信方法（有線、無線、およびそれらの組み合わせ）を採用することができる。

以下、本実施形態におけるデータベース装置１００を構成する構成要素について説明する。図１に例示するように、データベース装置１００は、問合せ処理部１０１と、データ記憶部１０２と、傾向記憶部１０３と、傾向判断部１０４と、を備える。データベース装置１００を構成するこれらの構成要素は、適切な通信方法を用いて、通信可能に接続されていてよい。また、各構成要素は、例えば、後述するハードウェア装置によって実行されるソフトウェア・プログラムとして実現されてもよく、専用のハードウェア（例えば、演算処理、記憶処理、通信処理などを実行可能な回路要素等）を用いて実現されてもよい。

問合せ処理部１０１（問合せ処理手段）は、クライアント２００から発行された問合せを処理するよう構成される。問合せ処理部１０１は、例えば、クライアント２００から発行されたデータベースに関する問合せ（ＳＱＬ等）を解釈し、その問合せに含まれるデータベース操作の命令を実行してもよい。

データ記憶部１０２（データ記憶手段）は、データベース装置１００に格納されたデータを記憶するよう構成される。データ記憶部１０２がデータを記憶する形式は特に限定されない。例えば、データ記憶部１０２は、リレーショナルデータベースとして、表（テーブル）形式によりデータを記憶してもよく、その他の形式（例えば、ＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ）等）によりデータを記憶してもよい。本位実施形態においては、具体例として、データ記憶部１０２は、表形式を用いてデータを記憶することを想定する。

傾向記憶部１０３（傾向記憶手段）は、クライアント２００が発行した問合せをモデル化して記憶するよう構成される。具体的には、傾向記憶部１０３は、クライアント２００から受け付けた問合せに含まれるテーブルへのアクセスの傾向を表すモデルを記憶してもよい。傾向記憶部１０３の詳細な動作については、後述する。

傾向判断部１０４（傾向判断手段）は、クライアント２００が発行した問合せに応じて、傾向記憶部１０３に記憶されたモデルに基づいて、その問合せに関連した実行可能な他の操作を提案するか否かを判断するよう構成される。傾向判断部１０４は、例えば、クライアント２００から受け付けた問合せに、傾向記憶部１０３に蓄積されたモデルに類似する問合せが含まれるか否かを判断してもよい。傾向判断部１０４は、クライアント２００が発行した問合せに適合するモデルがある場合、そのモデルに基づいて、クライアント２００に対して、別の問合せを提案してもよい。傾向判断部１０４の具体的な動作については、後述する。

［動作］
以下、上記のように構成されたデータベース装置１００の動作について、説明する。データベース装置１００は、大別して、以下の二つの処理（第１の処理、第２の処理）を実行する。即ち、データベース装置１００は、クライアント２００が発行した問合せをモデル化し（モデルを作成し）、記憶する処理（第１の処理）を実行するよう構成される。データベース装置１００は、また、作成したモデルに基づいて、クライアント２００に対して、次に実行する操作（例えば、次に実行する問合せ等）を提案する処理（第２の処理）を実行するよう構成される。データベース装置１００は、これらの処理を必ずしも排他的に実行する必要はなく、両方の処理を並行して実行してもよい。

以下、第１の処理について、図２に例示するフローチャートを用いて説明する。

問合せ処理部１０１は、クライアント２００が発行した問合せを受け付け、その問合せを解析する（ステップＳ２０１）。以下、具体例として、クライアント２００が発行する問合せはリレーショナルデータベースにおいて一般的に用いられるＳＱＬを用いて記述されることを想定する。なお、本開示にかかる技術はこれに限定されず、他の問合せ言語にも適用可能である。

問合せ処理部１０１は、以前の問合せにおいてアクセスしたテーブルの情報を読み出す（ステップＳ２０２）。問合せ処理部１０１は、例えば、前回第１の処理を実行した際に、後述するステップＳ２０３において記憶したテーブルの情報を、傾向記憶部１０３から読み出してもよい。なお、クライアント２００から受け付けた問合せが、あるセッションにおいて最初の問合せである場合、問合せ処理部１０１は、ステップＳ２０２を実行せずともよい。セッションは、例えば、データベース装置１００に対する一連の操作のまとまり（操作のセット）であってよい。例えば、ある利用者がデータベース装置１００に接続した際に一つのセッションが開始され、その利用者がデータベース装置１００から切断した際に、そのセッションが終了してもよい。この場合、そのセッションには、ある利用者がデータベース装置１００に接続してからデータベース装置１００から切断されるまでの間に実行された操作が含まれる。

問合せ処理部１０１は、ステップＳ２０１において受け付けた問合せを処理する際にアクセスするテーブルを、傾向記憶部１０３に記憶する（ステップＳ２０３）。具体的には、問合せ処理部１０１は、クライアント２００から受け付けた問合せが、あるセッションにおいて最初の問合せである場合、その問合せにおいてアクセスされたテーブルを表す情報を傾向記憶部１０３に記憶してよい。クライアント２００から受け付けた問合せが、あるセッションにおいて最初の問合せではなく、ステップＳ２０２において以前にアクセスしたテーブルの情報が読み込まれている場合、問合せ処理部１０１は、以前の問合せにおいてアクセスしたテーブルと、今回の問合せにおいてアクセスしたテーブルとの関係を表す情報を傾向記憶部１０３に記憶してよい。即ち、問合せ処理部１０１は、ある特定のタイミングまでに受け付けた問合せにおいてアクセスされたテーブル間の関係を表す情報を、傾向記憶部１０３に記憶してよい。かかる特定のタイミングは、特に限定されず、例えば、あるセッションにおいて最後に問合せを受け付けたタイミング（最新の問合せを受け付けたタイミング）であってもよく、それ以前の適切なタイミングであってもよい。かかるタイミングは、例えば、予め設定値等として問合せ処理部１０１に設定されていてもよい。

具体例として、問合せ処理部１０１が、ステップＳ２０１において以下のような問合せ（ＳＱＬ）を受け付けたことを想定する。

ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ１ ＷＨＥＲＥ ｃ１ ＝ ４２・・・（問合せ１）．
上記（問合せ１）において、”ｔ１”は、今回の問合せにおいてアクセスされるテーブルを表す（この場合は、テーブル”ｔ１”がアクセスされる）。このとき、問合せ処理部１０１は、傾向記憶部１０３に、「（ｔ＿ｐｒｖ）→ｔ１」という情報を記憶する。”ｔ＿ｐｒｖ”は、ステップＳ２０２において読み出されたテーブルを仮に表している。実際の処理においては、”ｔ＿ｐｒｃ”には、ステップＳ２０２において読み出されたテーブル名などが設定される。また、”→”は、テーブルがアクセスされた順番（順序）を表す。上記具体例においては、”→”は、あるセッションにおいて、テーブル”ｔ＿ｐｒｖ”がアクセスされたのち、テーブル”ｔ１”がアクセスされたことを表す。なお、問合せ処理部１０１は、”→”に限定されず、他の適切な表現方法を用いてもよい。このように、問合せ処理部１０１は、傾向記憶部１０３に、ある特定のタイミング（例えば、今回の問い合わせを受け付けたタイミング）までに受け付けた１以上の問合せに含まれるテーブルのアクセス順序を、テーブルへのアクセスの傾向を表すモデルとして傾向記憶部１０３に記憶することができる。

なお、ステップＳ２０１における問合せが、あるセッションにおける最初の問合せである場合（ステップＳ２０２が実行されていない場合）、問合せ処理部１０１は、傾向記憶部１０３に、「ｔ１」という情報を記憶してよい。

また、他の具体例として、問合せ処理部１０１が、ステップＳ２０１において以下のような問合せ（ＳＱＬ）を受け付けたことを想定する。

ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ１， ｔ２ ＷＨＥＲＥ ｔ１．ｃ１ ＝ ｔ２．ｃ２ ・・・（問合せ２）．
この場合、問合せ処理部１０１は、傾向記憶部１０３に、「（ｔ＿ｐｒｅｖ）→ｔ１，ｔ２」という形式の情報になる。上記（問合せ２）においては、複数のテーブル”ｔ１”、”ｔ２”がアクセスされる。

問合せ処理部１０１は、ステップＳ２０１において受け付けた問合せに、複数のテーブルが含まれるか否か（問合せにおいて複数のテーブルがアクセスされるか否か）を判断する（ステップＳ２０４）。上記の具体例を用いて説明すると、（問合せ１）の場合、アクセスされるテーブルの数は１つ（”ｔ１”）なので、問合せ処理部１０１は、ステップＳ２０４において”Ｎｏ”と判断する。また、上記（問合せ２）の場合、複数のテーブル（”ｔ１”、”ｔ２”）がアクセスされるので、問合せ処理部１０１は、ステップＳ２０４において”Ｙｅｓ”と判断する。

ステップＳ２０４においてＹｅｓの場合、問合せ処理部１０１は、ステップＳ２０１において受け付けた問合せに含まれるテーブル間の関係性を表す情報を傾向記憶部１０３に記憶する（ステップＳ２０５）。問合せ処理部１０１は、例えば、ある問合せに含まれるテーブルを結合する結合条件を、テーブル間の関係性を表す情報として、傾向記憶部１０３に記憶してもよい。これにより、問合せ処理部１０１は、複数のテーブル間を関連付ける結合条件を、テーブルへのアクセスの傾向を表すモデルとして傾向記憶部１０３に記憶することができる。上記（問合せ２）の具体例の場合、問合せ処理部１０１は、例えば、「ｔ１．ｃ１ ＝ ｔ２．ｃ２」を、傾向記憶部１０３に記憶してもよい。

上記説明したステップＳ２０３、Ｓ２０５の処理により、問合せ処理部１０１は、データベースに格納されたテーブルに対するアクセスをモデル化することができる。より具体的には、問合せ処理部１０１は、例えば、データベースに格納されたテーブルに対するアクセスの順番を、モデル化することができる。また、問合せ処理部１０１は、データベースに格納されたテーブル間の関係性をモデル化することができる。より具体的には、問合せ処理部１０１は、あるテーブルと、他のテーブルとの結合関係（それらのテーブルを結合する結合条件）をモデル化することができる。

以下、第２の処理について、図３に例示するフローチャートを用いて説明する。

問合せ処理部１０１は、クライアント２００から問合せを受け付け、その問合せを解析することで、その問合せに関係するテーブルを特定する（ステップＳ３０１）。例えば、クライアント２００から、上記（問合せ２）に例示するような問合せを受け付けた場合、問合せ処理部１０１は、テーブル”ｔ１”、及び”ｔ２”を特定する。

問合せ処理部１０１は、ステップＳ３０１において特定された各テーブルについて、以下において説明するステップＳ３０２からステップＳ３０４を繰り返し実行する（ステップＳ３０２−ステップＳ３０５）。上記した（問合せ２）の例において、テーブル”ｔ１”及びテーブル”ｔ２”のそれぞれについて、以下の各ステップ（ステップＳ３０２−Ｓ３０４）において説明する処理を行う。なお、以下のステップの説明においては、説明の便宜上処理対象とするテーブルを”ｔ”と記載する。

問合せ処理部１０１は、傾向記憶部１０３からテーブル”ｔ”に関連する情報を読み出す（ステップＳ３０２）。問合せ処理部１０１は、読み出した情報を傾向判断部１０４に提供してもよい。この際、読み出される情報は、例えば、上記説明したステップＳ２０３、Ｓ２０５において傾向記憶部１０３に記憶された情報（例えば、テーブルのアクセス順序、テーブル間の結合関係等）であってよい。

傾向判断部１０４は、ステップＳ３０２において”ｔ”に関連する情報が得られたか否かを判定する（ステップＳ３０３）。ステップＳ３０３においてＹｅｓの場合、傾向判断部１０４は、ステップＳ３０２で得られたテーブル”ｔ”に関連する情報に基づいて、利用者に対して次に実行する処理に関する情報を提案する（ステップＳ３０４）。傾向判断部１０４は、次に実行する処理に関する情報をクライアント２００に提供することで、かかる情報を利用者に提案してもよい。ステップＳ３０３においてＮｏの場合、及び、ステップＳ３０４における処理を実行した場合、傾向判断部１０４は、ステップＳ３０１において特定された全てのテーブルについて、上記処理を実行した否かを確認する（ステップＳ３０５）。ステップＳ３０５においてＮｏの場合、傾向判断部１０４は、ステップＳ３０２に戻って処理を続行してよい。また、ステップＳ３０５においてＹｅｓの場合、傾向判断部１０４は、処理を終了してよい。

以下、ステップＳ３０４における処理について具体的に説明する。傾向判断部１０４は、ステップＳ３０２で得られたテーブル”ｔ”に関連する情報に基づいて、利用者に対して、次にアクセスするテーブルを提示してもよい。また、傾向判断部１０４は、利用者に対して、次にアクセスする他のテーブルと、当該他のテーブルとテーブル”ｔ”と結合条件を提示してもよい。

傾向判断部１０４は、傾向記憶部１０３から取得したテーブル”ｔ”に関する情報を、そのまま利用者に提示してもよい。傾向判断部１０４は、傾向記憶部１０３から取得したテーブル”ｔ”に関する情報のうち、ステップＳ３０１において受け付けた問合せに応じて、特定の条件を満たす情報を選択して、利用者に提示してもよい。

以下、図４及び図５に例示する具体例を用いて、データベース装置１００の動作について、更に具体的に説明する。

図４は、同一セッション内で実行される上記第１の処理の具体例を示す説明図である。図４において、符号４００ａ−４００ｄには、傾向記憶部１０３に記憶されている情報（問合せを表すモデル）を表す。符号４００ａ−４００ｄにおいて、”（）”内に示される情報は、ある問合せに関連するテーブルを表す。例えば、符号４００ａにより表される情報の場合、問合せに関連するテーブルは”ｔ１”、”ｔ２”である。また、”＜＞”内に示される情報は、ある問合せに複数のテーブルが含まれる場合に、それらのテーブルの関連性を表す情報（例えば、結合条件等）を表す。例えば、符号４００ａにより表される情報の場合、テーブル”ｔ１”、”ｔ２”の結合条件は、”ｔ１．ｃ１＝ｔ２．ｃ２”である。以下、図４に示す処理の流れについて説明する。

利用者１は、データベース装置１００（問合せ処理部１０１）に対して、図４のＳ４０１に例示する問合せ（
「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ１，ｔ２ ＷＨＥＲＥ ｔ１．ｃ１＝ｔ２．ｃ２」）を実行する。問合せ処理部１０１は、この問合せによりアクセスされるテーブル”ｔ１”、”ｔ２”を特定し、それらを傾向記憶部１０３に記憶する。この際、問合せ処理部１０１は、例えば、傾向記憶部１０３に対して、図４のＳ４０２に例示する命令（「ａｐｐｅｎｄ（ｔ１、ｔ２）」）を通知してもよい。また、問合せ処理部１０１は、テーブル”ｔ１”と、”ｔ２”との間の関係性を表す情報（例えば、結合条件等）を、傾向記憶部１０３に記憶してもよい。これにより、傾向記憶部１０３には、図４の４００ａに例示する情報（モデル）が記憶される。

利用者１は、データベース装置１００（問合せ処理部１０１）に対して、図４のＳ４０３に例示する問合せ（
「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ３」）を実行する。問合せ処理部１０１は、この問合せによりアクセスされるテーブル”ｔ３”を特定し、それを傾向記憶部１０３に記憶する。この際、問合せ処理部１０１は、例えば、傾向記憶部１０３に対して、図４のＳ４０４に例示する命令（「ａｐｐｅｎｄ（ｔ３）」）を通知してもよい。傾向記憶部１０３には、図４の４００ｂに例示する情報が記憶される。これにより、同一セッションにおけるテーブルのアクセス順序（この場合は、テーブル（”ｔ１”，ｔ２”）の後に、テーブル”ｔ３”がアクセスされる）を表す情報（モデル）が、傾向記憶部１０３に記憶される。

利用者１は、データベース装置１００（問合せ処理部１０１）に対して、図４のＳ４０５に例示する問合せ（
「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ３，ｔ４ ＷＨＥＲＥ ｔ３．ｃ３＝ｔ４．ｃ４」）を実行する。問合せ処理部１０１は、この問合せによりアクセスされるテーブル”ｔ３”、”ｔ４”を特定し、それらを傾向記憶部１０３に記憶する。この際、問合せ処理部１０１は、例えば、傾向記憶部１０３に対して、図４のＳ４０６に例示する命令（「ａｐｐｅｎｄ（ｔ３、ｔ４）」）を通知してもよい。また、問合せ処理部１０１は、テーブル”ｔ３”と、”ｔ４”との間の関係性を表す情報（例えば、結合条件等）を、傾向記憶部１０３に記憶してもよい。傾向記憶部１０３には、図４の４００ｃに例示する情報が記憶される。これにより、同一セッションにおけるテーブルのアクセス順序（この場合は、テーブル（”ｔ１”，ｔ２”）、テーブル”ｔ３”、テーブル（”ｔ３”、”ｔ４”）の順にアクセスされる）を表す情報（モデル）が、傾向記憶部１０３に記憶される。

利用者１は、データベース装置１００（問合せ処理部１０１）に対して、図４のＳ４０７に例示する問合せ（
「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ５」）を実行する。問合せ処理部１０１は、この問合せによりアクセスされるテーブル”ｔ５”を特定し、それを傾向記憶部１０３に記憶する。この際、問合せ処理部１０１は、例えば、傾向記憶部１０３に対して、図４のＳ４０４に例示する命令（「ａｐｐｅｎｄ（ｔ５）」）を通知してもよい。傾向記憶部１０３には、図４の４００ｄに例示する情報が記憶される。これにより、同一セッションにおけるテーブルのアクセス順序（この場合は、テーブル（”ｔ１”，ｔ２”）、テーブル”ｔ３”、テーブル（”ｔ３”、”ｔ４”）、テーブル”ｔ５”の順にアクセスされる）を表す情報（モデル）が、傾向記憶部１０３に記憶される。

図５は、第２の処理の具体例を示す説明図である。図５に例示する処理においては、事前に図４に示す処理が実行され、図４における４００ａ−４００ｄに例示する情報を表すモデルが構築されていることを想定する。なお、図４に例示する利用者１と、図５に例示する利用者２とは、異なる利用者であってもよく、同一の利用者であってもよい。

利用者２は、データベース装置１００（問合せ処理部１０１）に対して、図５のＳ５０１に示す問合せ（「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ３」）を実行する。

問合せ処理部１０１は、その問合せを受け付けると、問合せの対象であるテーブル”ｔ３”に関連する情報を、傾向記憶部１０３から読み出す。この際、問合せ処理部１０１は、例えば、傾向記憶部１０３に対して、図５の５０２に示すような命令（「ｇｅｔ＿ｒｅｌａｔｅｄ（ｔ３）」）を送信してもよい。

図４に示す具体例において説明したように、傾向記憶部１０３は以下の情報（モデル）を記憶している。
「［（ｔ１， ｔ２ ＜ｔ１．ｃ１ ＝ ｔ２．ｃ２＞）， （ｔ３）， （ｔ３， ｔ４ ＜ｔ３．ｃ３ ＝ ｔ４．ｃ４＞）， （ｔ５）］」.
問合せ処理部１０１からの要求に対し、傾向記憶部１０３は、例えば、以下の情報（関連情報）を、問合せ処理部１０１に返してもよい。即ち、傾向記憶部１０３は”（ｔ３、ｔ４）”を記憶していることから、テーブル”ｔ３”と同時にアクセスされるテーブルとして、テーブル”ｔ４”を表す情報を、関連情報として問合せ処理部１０１に返してもよい。また、傾向記憶部１０３は、テーブル”ｔ３”と、”ｔ４”との関連性を表す情報として、”ｔ３．ｃ３ ＝ ｔ４．ｃ４”を、関連情報として問合せ処理部１０１に返してもよい。これは、図４のＳ４０５においてテーブル”（ｔ３、ｔ４）”にアクセスする問合せが実行された際、結合条件として、”ｔ３．ｃ３ ＝ ｔ４．ｃ４”が用いられたからである。また、傾向記憶部１０３は、次にアクセスするテーブルの候補として、テーブル”ｔ５”を表す情報を、関連情報として問合せ処理部１０１に返してもよい。これは、図４に例示するＳ４０３−Ｓ４０８の処理において、テーブル”ｔ３”の後に、テーブル”ｔ５”がアクセスされているからである。

問合せ処理部１０１は、傾向記憶部１０３から取得した情報（関連情報）を、傾向判断部１０４に送る。この際、問合せ処理部１０１は、傾向判断部１０４に対して、図５の５０３に例示するような命令（「ｇｅｔ＿ｓｕｇｇｅｓｔｉｏｎ（ｔ３）」）を送信してもよい。

傾向判断部１０４は、問合せ処理部１０１から受け付けた情報を、利用者に提案する操作の候補（提案候補）として用い、特定の判定基準を用いて、提案候補から利用者に提案する情報を決定する。

傾向判断部１０４は、例えば、すべての提案候補を利用者に提案してもよい。

また、傾向判断部１０４は、例えば、特定の判定基準として問合せに関する条件を考慮して、利用者に提案する情報を決定してもよい。即ち、傾向判断部１０４は、例えば、利用者（この場合は「利用者２」）から受け付けた問合せにおいて参照される列が、提案する結合条件に含まれるか否かに基づいて、利用者に提案する情報を判定してもよい。具体例として、例えば、利用者から「ＳＥＬＥＣＴ ｃ１ ＦＲＯＭ ｔ３」という内容の問合せを受け付けた場合を想定する。この場合、傾向記憶部１０３に記憶されている結合条件（”ｔ３．ｃ３＝ｔ４．ｃ４”）に含まれる列”ｔ３．ｃ３”は、問合せにおいて参照される列（”ｔ３．ｃ１”）に含まれない。このため、”ｔ３．ｃ３”は利用者の興味の対象外であると考えられる。したがって、傾向判断部１０４は、提案候補に含まれる「テーブル”ｔ３”に対して、テーブル”ｔ４”を条件”ｔ３．ｃ３ ＝ ｔ４．ｃ４”により結合する」ことを表す情報を提案から除外する。換言すると、傾向判断部１０４は、提案候補のうち、問合せにおいて参照される列を含む結合条件を、利用者に提案する情報とし判断してよい。なお、傾向判断部１０４は、上記に限定されず、他の判定基準を用いて、利用者に提案する情報を決定してもよい。

傾向判断部１０４は、利用者（この場合は利用者２）に対して、図５のＳ５０４に例示するように、提案する情報（提案情報）を提供してもよい。なお、傾向判断部１０４は、問合せ処理部１０１に対して提案情報を提供し、問合せ処理部１０１が、利用者（この場合は利用者２）に対して、提案情報を提供してもよい。

図６は、図５に例示する問合せを実行した利用者に対して、データベース装置１００から提供される提案の具体例と示す説明図である。図６に示す６００は、例えば、クライアント２００に表示される表示画面や、ユーザインタフェースの一部として、利用者に提供されてもよい。

図６の６０１には、利用者が実行した問合せの内容（「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔ３」）が表示されている。利用者は、例えば、クライアント２００に表示されたユーザインタフェースに、図６の６０１に例示する問合せを入力することで、データベース装置１００に対する問合せを実行してもよい。

図６の６０２には、６０１における問合せの処理結果が表示される。この場合、テーブル”ｔ３”の内容が表示されている。

図６の６０３には、利用者に対する提案情報が表示される。図６の６０３において、”ｔ２”、”ｔ３”、”ｔ４”、”ｔ５”、”ｔ６”、”ｔ７”、”ｔ１３”、及び”ｔ１５”はテーブルを表す。テーブル間を接続する矢印は、アクセスする順序を表す。”Ｙｏｕ ａｒｅ ｈｅｒｅ”は、利用者が直近に実行したクエリによりアクセスされたテーブル（この場合はテーブル”ｔ３”）を表す。また、”ＪＯＩＮ”は、二つのテーブルを、特定の結合条件により結合することを表す。結合条件は、図６に例示する具体例の場合、”ＪＯＩＮ”の近傍に文字列として表示されている。

図６に示すように、利用者がテーブル”ｔ３”を”ＳＥＬＥＣＴ”した問合せに対し、データベース装置１００は、次のステップとして（ａ）テーブル”ｔ３”とテーブル”ｔ４”とを、”ｔ３．ｃ３ ＝ ｔ４．ｃ４”という条件で結合すること、及び、（ｂ）テーブル”ｔ５”を参照することを提案している。また、ｍａｐとして、矢印で次のステップを提案する。

なお、図６に示す具体例の場合、データベース装置１００が、更にその次のステップ（例えばテーブル”ｔ５”を参照した後に（矢印で接続された）テーブル”ｔ６”又はテーブル”ｔ７”の参照や、テーブル”ｔ５”とテーブル”ｔ４”とを”ｔ５．ｃ５＝ｔ４．ｃ４”という結合条件により結合することが）を提案可能であることを示している。

上記のように構成されたデータベース装置１００によれば、利用者がデータ分析をより効率的に実行することができる。その理由は以下のとおりである。即ち、データベース装置１００は、あるユーザが実行した問合せを解析し、データベースに対する操作をモデル化する。より具体的には、データベース装置１００は、あるセッションにおけるデータベースのアクセス順序をモデルとして記憶することができる。このため、データベース装置１００は、例えば、利用者がある順序でテーブルをアクセスした際に、次にアクセスするテーブルの候補を提示することができる。これにより、利用者は、例えば、利用者自身が存在を認識していなかったデータを提案されたテーブルの中から発見することが可能であり、他のデータと、提案されたテーブルに含まれるデータとを組み合わせることで、効果的なデータ分析を行えるようになることが期待できる。

また、データベース装置１００は、テーブル間の関連性（例えば、ある二つのテーブルに関する結合条件）をモデルとして記憶することができる。このため、データベース装置１００は、例えば、ある利用者があるテーブルにアクセスした際、モデルとして記憶している結合条件に基づいて他のテーブルとの結合を提案することができる。これより、例えば、結合条件が不明等の理由により、利用者が活用できていなかったデータについても、データベース装置１００からの提案に応じて、利用者がデータの組み合わせ方を発見し、より効果的なデータ分析を行えるようになることが期待できる。

［第１実施形態の変形例１］
本変形例におけるデータベース装置１００の基本的な構成は第１実施形態と同様としてよい。本変形例においては、データベース装置１００を構成する各構成要素の動作の一部が、第１実施形態から拡張されている。

具体的には、データベース装置１００（問合せ処理部１０１）は、第１の処理において、テーブルに関連する情報を傾向記憶部１０３に記憶する際に、そのテーブルへアクセスした時間を記憶する。そして、第２の処理において、データベース装置１００（傾向判断部１０４）は、特定の判定基準として、テーブルにアクセスした時間を考慮して、提案候補から利用者に提案する情報を決定する。

より具体的には、傾向判断部１０４は、提案候補に含まれるテーブルのうち、そのテーブルにアクセスした時間が、ある特定の時間（特定時間）より前のテーブルを利用者に提案しないよう除外する。換言すると、傾向判断部１０４は、提案候補に含まれるテーブルのうち、そのテーブルにアクセスした時間が、ある特定の時間（特定時間）以降のテーブルを利用者に提案してもよい。テーブルに対するアクセスの傾向は時間の経過に応じて変化する可能性あり、古い情報を提案しても有益ではない状況が考えられるからである。

上記のように構成された本変形例によるデータベース装置１００は、比較的新しいアクセスの傾向に基づいて、利用者に対して、処理の候補（例えば、テーブルのアクセス、結合等）を提案することができる。

［第１実施形態の変形例２］
本変形例におけるデータベース装置１００の基本的な構成は第１実施形態と同様としてよい。本変形例においては、データベース装置１００を構成する各構成要素の動作の一部が、第１実施形態から拡張されている。

本変形例におけるデータベース装置１００（傾向判断部１０４）は、第２の処理において、特定の判定基準として、テーブルにアクセスする利用者のアクセス権限を考慮して、提案候補から利用者に提案する情報を決定する。

より具体的には、傾向判断部１０４は、提案候補に含まれるテーブルのうち、各利用者ごとに、その利用者がアクセスする権限を有しないテーブルに関する情報を、その利用者に提案しないよう除外する。換言すると、傾向判断部１０４は、提案候補に含まれるテーブルのうち、各利用者ごとに、その利用者がアクセスする権限を有するテーブルに関する情報を、その利用者に提案する。テーブルごとに利用者に応じたアクセス権限が設定されている場合、アクセス権のないテーブルを提案されても、利用者がその情報を有効に活用できないからである。また、これにより、利用者が無用な混乱をまねく可能性を低減できる。テーブルに対するアクセス権限は、例えば、データベース装置１００を利用者が利用する際に、クライアント２００を介して提供されてもよい。

［第１実施形態の変形例３］
本変形例におけるデータベース装置１００の基本的な構成は第１実施形態と同様としてよい。本変形例においては、データベース装置１００を構成する各構成要素の動作の一部が、第１実施形態から拡張されている。

具体的には、データベース装置１００（問合せ処理部１０１）は、第１の処理において、テーブルに関連する情報を傾向記憶部１０３に記憶する際に、その情報が記録される回数を併せて記憶する。問合せ処理部１０１は、例えば、テーブルごとに、そのテーブルに関連する問合せを受け付けた回数を、傾向記憶部１０３に記憶してもよい。より具体的には、問合せ処理部１０１は、例えば、第１の処理において、あるテーブルに関するアクセスの回数をカウントし、その回数を傾向記憶部１０３に記憶してもよい。問合せ処理部１０１は、例えば、問合せに含まれる結合条件ごとに、その結合条件が用いられた回数をカウントし、その回数を傾向記憶部１０３に記憶してもよい。

第２の処理において、データベース装置１００（傾向判断部１０４）は、特定の判定基準として、提案候補ごとに記憶されている回数を考慮して、提案候補から利用者に提案する情報を決定してよい。より具体的には、傾向判断部１０４は、記憶された回数が特定値を超える提案候補を、利用者に提案する。この特定値は、例えば、利用者が設定可能としてもよい。本変形例におけるデータベース装置１００は、例えば、利用者の多様な分析行動により、第２の処理において利用者に提案される情報が過剰になることを防ぐことができる。具体例として、第１の処理において、テーブル”ｔＡ”の次にテーブル”ｔＢ”にアクセスする問合せが５０回、テーブル”ｔＡ”の次にテーブル”ｔＣ”にアクセスする問合せが１０回記録されたことを想定する。仮に、特定値に”２０”が設定されている場合、第２の処理において、テーブル”ｔＡ”に関する問合せが実行された際、データベース装置１００は、次にテーブル”ｔＢ”を提案する。即ち、データベース装置１００は、比較的アクセス回数が多いテーブル”ｔＢ”を利用者に提案し、比較的アクセス回数が少ないテーブル”ｔＣ”を除外することで、利用者に提案される情報が過剰になることを防ぐことができる。

＜第２実施形態＞
以下、本開示にかかる技術の第２実施形態について説明する。第２実施形態は、第１実施形態及びその変形例にかかるデータベース装置を、複数の離間した物理的又は仮想的な装置により構成されるデータベースシステムとして実現する実施形態である。

図７は、本実施形態におけるデータベースシステム７００の機能的な構成を例示するブロック図である。図７に例示するように、データベースシステム７００は、問合せ処理装置７０１と、データ記憶装置７０２と、傾向記憶装置７０３と、傾向判断装置７０４と、を備える。データベースシステム７００を構成するこれらの構成要素は、適切な通信方法（例えば、無線通信、有線通信、及びそれらの組合せ）を用いて、通信可能に接続されていてよい。また、各構成要素は、例えば、後述する汎用のハードウェア装置及びかかる装置により実行されるソフトウェア・プログラムを用いて単体の装置として実現されてもよく、専用のハードウェア（例えば、演算処理、記憶処理、通信処理などを実行可能な回路要素等）を用いて実現されてもよい。

問合せ処理装置７０１は、上記第１実施形態及びその変形例における問合せ処理部１０１と同様に、データ記憶装置に記憶されるテーブルに関する問合せを受け付ける。問合せ処理装置７０１は、例えば、上記第１実施形態及びその変形例における問合せ処理部１０１と同様の機能を実現するよう構成されてもよい。

データ記憶装置７０２は、上記第１実施形態及びその変形例におけるデータ記憶部１０２と同様に、データが格納されたテーブルを記憶する。データ記憶装置７０２は、例えば、上記第１実施形態及びその変形例におけるデータ記憶部１０２と同様の機能を実現するよう構成されてもよい。

傾向記憶装置７０３は、上記第１実施形態及びその変形例における傾向記憶部１０３と同様に、テーブルへのアクセスの傾向を表すモデルを記憶する。傾向記憶装置７０３は、例えば、上記第１実施形態及びその変形例における傾向記憶部１０３と同様の機能を実現するよう構成されてもよい。

傾向判断装置７０４は、上記第１実施形態及びその変形例における傾向判断部１０４と同様に、問合せ処理装置７０１が受け付けた他の問合せに含まれるテーブルに応じて、傾向記憶装置７０３に記憶されたモデルに基づいて、他の問合せに関連して実行可能な他の操作を提案する情報を提供する。傾向判断装置７０４は、例えば、上記第１実施形態及びその変形例における傾向判断部１０４と同様の機能を実現するように構成されてもよい。このように構成された本実施形態におけるデータベースシステム７００によれば、上記第１実施形態におけるデータベース装置１００と同様、利用者がデータ分析をより効率的に実行することができる。

＜ハードウェア及びソフトウェア・プログラム（コンピュータ・プログラム）の構成＞
以下、上記説明した各実施形態を実現可能なハードウェア構成について説明する。以下の説明においては、上記各実施形態において説明した各データベース装置１００を、単にデータベース装置と記載する。

上記各実施形態において説明したデータベース装置は、１つ又は複数の専用のハードウェア装置により構成されてもよい。その場合、上記図１に示した各構成要素は、一部又は全部を統合したハードウェア（処理ロジックを実装した集積回路等）として実現してもよい。例えば、データベース装置をハードウェア装置により実現する場合、データベース装置の構成要素は、それぞれの機能を提供可能な集積回路（例えば、ＳｏＣ（Ｓｙｓｔｅｍ ｏｎ ａ Ｃｈｉｐ）等）として実装されてもよい。この場合、例えば、データベース装置の構成要素が有するデータは、ＳｏＣに統合されたＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）領域やフラッシュメモリ領域に記憶されてもよい。

この場合、データベース装置は、例えば、問合せ処理部１０１、データ記憶部１０２、傾向記憶部１０３、及び傾向判断部１０４の機能を実現可能な１以上の処理回路（ｐｒｏｃｅｓｓｉｎｇ ｃｉｒｃｕｉｔｒｙ）、通信回路、及び記憶回路等を用いて実現されてよい。なお、データベース装置を実現する回路構成の実装においては、様々なバリエーションが想定される。データベース装置を複数のハードウェア装置により構成する場合、それぞれのハードウェア装置の間は、適切な通信方法（有線、無線、またはそれらの組み合わせ）により通信可能に接続されていてもよい。

また、上述したデータベース装置は、図８に例示するような汎用のハードウェア装置８００と、ハードウェア装置８００によって実行される各種ソフトウェア・プログラム（コンピュータ・プログラム）とによって構成されてもよい。この場合、データベース装置は、１以上の適切な数のハードウェア装置８００及びソフトウェア・プログラムにより構成されてもよい。

図８におけるプロセッサ８０１は、例えば、汎用のＣＰＵ（中央処理装置：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やマイクロプロセッサである。プロセッサ８０１は、例えば、後述する不揮発性記憶装置８０３に記憶された各種ソフトウェア・プログラムをメモリ８０２に読み出し、そのソフトウェア・プログラムに従って処理を実行してもよい。この場合、上記各実施形態におけるデータベース装置の構成要素は、例えば、プロセッサ８０１により実行されるソフトウェア・プログラムとして実現可能である。

この場合、上記各実施形態におけるデータベース装置は、例えば、問合せ処理部１０１、データ記憶部１０２、傾向記憶部１０３、及び傾向判断部１０４の機能を実現可能な１以上のプログラムにより実現されてよい。なお、かかるプログラムの実装においては、様々なバリエーションが想定される。

メモリ８０２は、プロセッサ８０１から参照可能な、ＲＡＭ等のメモリデバイスであり、ソフトウェア・プログラムや各種データ等を記憶する。なお、メモリ８０２は、揮発性のメモリデバイスであってもよい。

不揮発性記憶装置８０３は、例えば磁気ディスクドライブや、半導体記憶装置（フラッシュメモリ等）のような、不揮発性の記憶装置である。不揮発性記憶装置８０３は、各種ソフトウェア・プログラムやデータ等を記憶可能である。上記データベース装置における各種テーブル及びモデルは、例えば、不揮発性記憶装置８０３に記憶されてもよい。

リーダライタ８０４は、例えば、後述する記録媒体８０５に対するデータの読み込みや書き込みを処理する装置である。データベース装置は、例えば、リーダライタ８０４を介して、記録媒体８０５に記録されたデータを読み込んでもよい。

記録媒体８０５は、例えば光ディスク、光磁気ディスク、半導体フラッシュメモリ等、データを記録可能な記録媒体である。本開示において、記録媒体の種類及び記録方法（フォーマット）は、特に限定されず、適宜選択されてよい。

ネットワークインタフェース８０６は、通信ネットワークに接続するインタフェース装置であり、例えば有線及び無線のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）接続用インタフェース装置等を採用してもよい。データベース装置は、例えば、ネットワークインタフェース８０６を介して、クライアント２００と通信可能に接続されていてよい。

入出力インタフェース８０７は、外部装置との間の入出力を制御する装置である。外部装置は、例えば、ユーザからの入力を受け付け可能な入力機器（例えば、キーボード、マウス、タッチパネル等）であってもよい。また、外部装置は、例えばユーザに対して各種出力を提示可能な出力機器（例えば、モニタ画面、プリンタ等）であってもよい。例えば、入出力インタフェースを介して各種データを出力してよい。

本開示にかかる技術は、例えば、ハードウェア装置８００に対して供給されたソフトウェア・プログラムを、プロセッサ８０１が実行することによって実現されてもよい。この場合、ハードウェア装置８００で稼働しているオペレーティングシステムや、データベース管理ソフト、ネットワークソフト等のミドルウェアなどが、各処理の一部を実行してもよい。

上述した各実施形態において、上記各図に示した各部は、上述したハードウェアにより実行されるソフトウェア・プログラムの機能（処理）の単位である、ソフトウェアモジュールとして実現されてもよい。例えば、上記各部をソフトウェアモジュールとして実現する場合、これらのソフトウェアモジュールは、不揮発性記憶装置８０３に記憶されてもよい。そして、プロセッサ８０１が、それぞれの処理を実行する際に、これらのソフトウェアモジュールをメモリ８０２に読み出してもよい。また、これらのソフトウェアモジュールは、共有メモリやプロセス間通信等の適宜の方法により、相互に各種データを伝達できるように構成されてもよい。

更に、上記各ソフトウェア・プログラムは、記録媒体８０５に記録されてもよい。この場合、上記各ソフトウェア・プログラムは、適当な治具（ツール）を利用してハードウェア装置８００内にインストールされてもよい。また、各種ソフトウェア・プログラムは、インターネット等の通信回線を介して外部からダウンロードされてもよい。ソフトウェア・プログラムを供給する方法として、各種の一般的な手順を採用することができる。

このような場合において、本開示にかかる技術は、ソフトウェア・プログラムを構成するコード、あるいはコードが記録されたところの、コンピュータ読み取り可能な記録媒体によって構成されてもよい。この場合、記録媒体は、ハードウェア装置８００と独立した非一時的な記録媒体であってもよく、ＬＡＮやインターネットなどにより伝送されたソフトウェア・プログラムをダウンロードして記憶又は一時記憶した記録媒体であってもよい。

また、上述したデータベース装置、あるいは、当該データベース装置の構成要素は、図８に例示するハードウェア装置８００を仮想化した仮想環境と、その仮想環境において実行されるソフトウェア・プログラム（コンピュータ・プログラム）とによって構成されてもよい。この場合、図８に例示するハードウェア装置８００の構成要素は、仮想環境における仮想デバイスとして提供される。

以上、上述した実施形態を模範的な例として本発明を説明した。しかしながら、本発明は、上述した実施形態には限定されない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができ、上記各実施形態の変形例や、その組合せも、本発明の技術的範囲に含まれる。

１００ データベース装置
１０１ 問合せ処理部
１０２ データ記憶部
１０３ 傾向記憶部
１０４ 傾向判断部
７００ データベースシステム
７０１ 問合せ処理装置
７０２ データ記憶装置
７０３ 傾向記憶装置
７０４ 傾向判断装置

Claims (10)

1. データを記憶するテーブルを有するデータ記憶手段に関する問合せを受け付ける問合せ処理手段と、
   前記問合せ処理手段が受け付けた問合せに関連する前記テーブルへのアクセスの傾向を表すモデルを記憶する傾向記憶手段と、
   前記問合せ処理手段が受け付けた他の問合せに関連する前記テーブルと、前記傾向記憶手段に記憶された前記モデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する傾向判断手段と、を備える
   データベース装置。
2. 前記問合せ処理手段は、ある特定のタイミングまでに受け付けた１以上の問合せによる前記テーブルのアクセス順序を、前記モデルとして前記傾向記憶手段に記憶し、
   前記傾向判断手段は、前記モデルとして記憶された前記テーブルのアクセス順序に基づいて、前記問合せ処理手段が受け付けた他の問合せに関連する前記テーブルへのアクセスの後にアクセス可能な１以上の前記テーブルへのアクセスを含む操作を、提案する操作の候補である提案候補として選択し、前記提案候補の中から１以上の操作を提案する
   請求項１に記載のデータベース装置。
3. 前記問合せ処理手段は、受け付けた問合せに含まれる複数の前記テーブルを関連付ける結合条件を、前記モデルとして前記傾向記憶手段に記憶し、
   前記傾向判断手段は、前記モデルとして記憶された１以上の前記結合条件に基づいて、前記問合せ処理手段が受け付けた他の問合せに含まれる前記テーブルと、他の前記テーブルとを関連付ける操作を、提案する操作の候補である提案候補として選択し、前記提案候補の中から１以上の操作を提案する
   請求項１又は請求項２に記載のデータベース装置。
4. 前記傾向判断手段は、前記問合せ処理手段が他の問合せを受け付けた際、前記問合せ処理手段が受け付けた他の問合せに含まれる前記テーブルと、他の前記テーブルとを関連付ける前記結合条件のうち、当該他の問合せにおいて参照される前記テーブルの列を含む前記結合条件により前記テーブルを関連付ける操作を提案する
   請求項３に記載のデータベース装置。
5. 前記問合せ処理手段は、問合せを受け付けた際、その問合せを受け付けた時間を前記傾向記憶手段に記憶し、
   前記傾向判断手段は、前記問合せ処理手段が他の問合せを受け付けた際、前記提案候補のうち、ある特定時間以降に受け付けた問合せに関連して記憶された前記モデルに基づいて選択された前記提案候補から、１以上の操作を提案する
   請求項２から請求項４のいずれかに記載のデータベース装置。
6. 前記傾向判断手段は、前記問合せ処理手段が受け付けた他の問合せを実行した利用者の、前記テーブルに対するアクセス権に応じて、その利用者がアクセス可能な前記テーブルに関連する前記提案候補から１以上の操作を提案する
   請求項２から請求項５のいずれかに記載のデータベース装置。
7. 前記問合せ処理手段は、問合せを受け付けた際、
   その問合せに含まれる前記テーブルについて、当該テーブルに関する問合せが実行された回数と、
   複数の前記テーブルの間を関連付ける前記結合条件がその問合せに含まれる場合、当該結合条件を含む問合せが実行された回数と、の少なくとも一方を前記傾向記憶手段に記憶し、
   前記傾向判断手段は、前記問合せ処理手段が他の問合せを受け付けた際、前記提案候補のうち、ある特定回数以上問合せが実行された前記テーブルと、前記結合条件との少なくとも一方を含む操作を提案する
   請求項３に記載のデータベース装置。
8. データを記憶するテーブルを有するデータ記憶装置に関する問合せを受け付ける問合せ処理装置と、
   前記問合せ処理装置が受け付けた問合せに関連する前記テーブルへのアクセスの傾向を表すモデルを記憶する傾向記憶装置と、
   前記問合せ処理装置が受け付けた他の問合せに関連する前記テーブルと、前記傾向記憶装置に記憶された前記モデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する傾向判断装置と、を備え、
   前記問合せ処理装置と、前記傾向記憶装置と、前記傾向判断装置とが通信ネットワークを介して相互に通信可能に接続されている
   データベースシステム。
9. データを記憶するテーブルを有するデータベースに関する問合せを受け付け、
   受け付けた問合せに関連する前記テーブルへのアクセスの傾向を表すモデルを記憶し、
   他の問合せに関連する前記テーブルと、記憶された前記モデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する
   データ管理方法。
10. データを記憶するテーブルを有するデータベースに関する問合せを受け付ける問合せ処理と、
    受け付けた問合せに関連する前記テーブルへのアクセスの傾向を表すモデルを記憶する記憶処理と、
    他の問合せに関連する前記テーブルと、記憶された前記モデルとに基づいて、当該他の問合せに関連して実行可能な操作を提案する傾向判断処理とを、データベース装置として機能するコンピュータに実行させる
    コンピュータ・プログラム。

Images