JP5597623B2 - データベース処理方法 - Google Patents

Description

本発明は、データベース処理システムにおけるデータ処理技術に関し、特に、複数テーブルを結合してデータを検索する際に処理効率を向上させるデータベース処理方法に適用して有効な技術に関するものである。

一般に、データベースを利用する情報処理システムにおいて、オンライン処理でトランザクションテーブル同士を結合（ジョイン）してデータを検索する場合、まず、駆動表についての索引（インデックス）テーブルを参照して対象データを絞り込み、インデックステーブルに格納されている対象データの格納場所情報（例えば、格納アドレス情報や行番号情報など）に基づいて駆動表にアクセスし、検索条件と駆動表の保持する情報に基づいて対象データを絞り込む。その後、駆動表の絞り込まれたデータについて、駆動表の保持する結合キーと外部表の保持する結合キーとを条件に外部表を結合し、外部表の保持する情報に基づいて対象データをさらに絞り込むという処理によって検索結果を得ることが多い。

このような処理方法では、例えば、駆動表と外部表にデータの絞り込み条件が分散し、駆動表だけでは十分にデータが絞り込めないような場合、駆動表と外部表のレコード件数の増加に伴い、駆動表と外部表に対する物理読込量の増大や、駆動表の絞り込み結果と外部表との結合処理の回数が増大することにより、検索処理の処理時間が急激に増大してしまう。

これに対して、複数テーブルを結合してデータを検索する際の処理効率を向上させる技術として、例えば、特開２００４−１１０２１９号公報（特許文献１）には、いわゆるスタースキーマにおいて、ファクト表のカラム値から対応するレコードを引くインデックスの一つと、ディメンジョン表のカラム値から対応するレコードを引くインデックスの一つを少なくとも含む複数インデックスの組合せを定義する仮想連結インデックスをデータベース中に記憶し、表のジョインを要する問合せの処理の際に対応する仮想連結インデックスが示すインデックスを順次アクセスしてジョイン処理を実行することで、スタースキーマのジョインを効率よく実行し、処理性能とデータベースメンテナンスコストとのバランスを制御する技術が記載されている。

特開２００４−１１０２１９号公報

複数のテーブルを結合してデータを検索する場合、レコード件数の増加に伴う処理効率の低下を回避するためには、例えば上記の特許文献１などの従来技術のように、検索対象表のインデックスを活用することが考えられる。このとき、特許文献１に記載されたようなスタースキーマにおけるファクト表と複数のディメンジョン表の結合の場合だけではなく、対象データの絞り込み条件が複数テーブルに分散しているようなトランザクションテーブル同士の結合の場合においても有効に処理効率を向上させることができる手法が望まれる。

そこで本発明の目的は、複数のテーブルを結合して対象データを絞り込み、検索結果を得るデータベース処理において、対象データの絞り込み条件が複数テーブルに分散している場合も、テーブル構成を修正せずに検索処理効率を向上させることができるデータベース処理方法を提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるデータベース処理方法は、コンピュータにより、指定された検索条件に基づいて、検索対象の複数のテーブルを結合して対象データを絞り込み、検索結果を得るデータベース処理方法であって、前記検索条件における結合条件に基づいて前記複数のテーブルを結合した情報について、前記検索条件において指定された第１のカラム、各レコードの前記各テーブルにおける格納場所の情報を保持する第２のカラム、および前記結合条件に係る第３のカラムとを少なくとも有するマテリアライズドビューを作成する第１のステップと、前記マテリアライズドビューについて、前記第１のカラム、および前記第２のカラムを有するインデックスを作成する第２のステップとを実行することを特徴とするものである。

また、本発明の代表的な実施の形態によるデータベース処理方法は、さらに、前記マテリアライズドビューの前記第１のカラムを含むカラムの指定によって前記検索条件の指定を受け付ける第３のステップと、前記検索条件に基づいて前記インデックスによってデータの絞り込みを行う第４のステップと、前記第４のステップにおいて絞り込まれたデータと、検索対象の前記各テーブルとを、前記第２のカラムの情報に基づいてそれぞれ結合する第５のステップと、前記第５のステップにおいて得られたデータを検索結果として出力する第６のステップとを実行することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、複数のテーブルを結合して対象データを絞り込み、検索結果を得るデータベース処理において、対象データの絞り込み条件が複数テーブルに分散している場合も、テーブル構成を修正せずに検索処理効率を向上させることが可能となる。

本発明の一実施の形態におけるインデックスの作成処理およびこれを利用した検索処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における検索処理を行う際の処理の流れの例について概要を示した図である。 本発明の一実施の形態におけるデータベース処理システムの構成例について概要を示した図である。 本発明の一実施の形態におけるインデックスを作成する際の処理の流れと各テーブルの具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるインデックスを使用して検索処理を実行する際の処理の流れと各テーブルの具体的なデータの例について概要を示した図である。 従来技術における検索処理を行う際の処理の流れの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
図６は、対象データの絞り込み条件が複数テーブルに分散している場合に、従来の手法により検索処理を行う際の処理の流れの例について概要を示した図である。ここでは、複数のテーブルとして、テーブルＡ（１２ａ）とテーブルＢ（１２ｂ）を対象とし、これらを結合した上で検索条件に従って対象データを絞り込むものとする。このとき、対象データの絞り込み条件がテーブルＡ（１２ａ）とテーブルＢ（１２ｂ）の両者に分散しているものとする。例えば、図示しないが、テーブルＡ（１２ａ）についての絞り込み条件が“ユーザＩＤ＝○○”（“ユーザＩＤ”はテーブルＡ（１２ａ）のカラム）であり、テーブルＢ（１２ｂ）についての絞り込み条件が“完了フラグ＝△”（“完了フラグ”はテーブルＢ（１２ｂ）が有するカラム）である、というようなケースである。

まず、データベース管理システム（ＤＢＭＳ）は、例えば、アプリケーションプログラムやユーザの操作等により発行されるＳＱＬ（Structured Query Language）文において検索条件として指定された複数のテーブルのうち、駆動表（図６の例ではテーブルＡ（１２ａ）とする）のインデックスにアクセスして、テーブルＡ（１２ａ）についての絞り込み条件（“ユーザＩＤ＝○○”）に合致するレコードを絞り込み、インデックスに格納されている対象レコードの格納場所情報（例えば、格納アドレス情報や行番号情報など）に基づいてテーブルＡ（１２ａ）にアクセスして、該当データ（図６の例では中間データａ）を得る。この中間データａは、テーブルＡ（１２ａ）における対象のレコード（“ユーザＩＤ＝○○”のレコード）がトランザクション処理等によって増加すると、これに伴って増加する。

中間データａを取得後、中間データａにおける結合キーと、テーブルＢ（１２ｂ）の結合キーを条件に、中間データａとテーブルＢ（１２ｂ）とを、例えば、テーブルＢ（１２ｂ）のインデックスを利用して、ネステッドループ結合によって結合し、中間データａｂを得る。この中間データａｂに対して、テーブルＢ（１２ｂ）についての絞り込み条件（“完了フラグ＝△”）に合致するレコードを絞り込み、検索結果を得る。このとき、データ量の増加に伴い中間データａの件数が増加すると、これに伴って、中間データａとテーブルＢ（１２ｂ）とを結合する際に、テーブルＡ（１２ａ）に対するデータ読み込みのためのアクセス量、および結合件数が増加するため、結合処理のコストが上昇して処理時間の伸長が発生してしまう。

そこで、本発明の一実施の形態であるデータベース処理方法を実装したデータベース処理システムでは、検索処理の際のテーブルの結合条件によって検索対象の複数のテーブルを結合したビューを作成する。このビューは、ＤＢＭＳの機能によりマテリアライズド（実体化）ビューとして作成する。マテリアライズドビューは、検索結果のデータについて実体をキャッシュとして保持することができるビューであり、参照元となる検索対象のテーブルにおいてカラムの値の更新が行われた場合、これと同期してマテリアライズドビューの対応するレコードのカラム（キャッシュ）の値に更新が反映されることで、検索対象のテーブルへの実アクセスの量を低減させることができる。また、マテリアライズドビュー自体にインデックスを作成することが可能である。

本実施の形態では、このマテリアライズドビューに、カラム（項目）として、検索処理の際に検索条件として指定する項目のカラムと、各レコードについての各検索対象テーブルでの格納場所情報（例えば、格納アドレス情報や行番号情報など）を保持するカラムを有するものとする。また、作成したマテリアライズドビューから、検索処理の際に検索条件として指定するカラムの情報と、各レコードについての各検索対象テーブルでの格納場所情報を保持するインデックスを作成する。

図２は、対象データの絞り込み条件が複数テーブルに分散している場合に、本実施の形態のデータベース処理方法により検索処理を行う際の処理の流れの例について概要を示した図である。ここでも、図６の例と同様に、複数のテーブルとして、テーブルＡ（１２ａ）とテーブルＢ（１２ｂ）を対象とし、これらを結合した上で検索条件に従って対象データを絞り込むものとする。

このとき、検索処理を行うＳＱＬは、テーブルＡ（１２ａ）とテーブルＢ（１２ｂ）とを結合して作成したマテリアライズドビューのカラムを対象として検索処理を行うように指定する。もしくは、上記の図６の例と同様に、複数のテーブルを結合して検索処理を行うＳＱＬを指定し、データベース管理システム（ＤＢＭＳ）が最適化処理の結果として内部的にマテリアライズドビューを対象として検索処理を行うＳＱＬに変換して実行するようにしてもよい。

まず、データベース管理システム（ＤＢＭＳ）は、検索条件として指定されたマテリアライズドビューのカラムの情報に基づいて、マテリアライズドビューのインデックス１４にアクセスし、絞り込み条件（例えば、“ユーザＩＤ＝○○”かつ“完了フラグ＝△”）に合致するレコードを絞り込み、インデックス１４についての中間データｍを得る。この中間データｍは、ほぼ最終的な検索結果の件数まで絞り込まれた件数となる。中間データｍを取得後、インデックス１４に保持している、検索対象の各テーブルの格納場所情報に基づいて、検索対象の各テーブル（テーブルＡ（１２ａ）、テーブルＢ（１２ｂ））を順次ネステッドループ結合によって結合し、検索結果を得る。

本実施の形態では、検索対象の各テーブルのデータ量の増加に伴うアクセス量の増加がインデックス１４についての分のみとなる。また、結合処理の件数も中間データｍの件数となり、最終的な検索件数で一定となる。このように、結合処理の前に対象データを十分に絞り込むことで、データ量の増加に伴う検索処理の処理時間の伸長を抑制することができ、上記の図６の例におけるような、インデックス１４を使用しない従来の検索処理の場合と比較して、検索処理時間を向上させることが可能となる。

＜システム構成＞
図３は、本発明の一実施の形態におけるデータベース処理システムの構成例について概要を示した図である。データベース処理システムは、例えば、コンピュータシステムにより実装されるサーバ機器からなるデータベースサーバ１を有し、データベースサーバ１に対して、インターネット等のネットワーク４を介して、１つ以上のアプリケーションサーバ２やクライアント端末３が接続可能な構成を有する。

アプリケーションサーバ２やクライアント端末３は、アプリケーションプログラムやミドルウェア、もしくはユーザによる操作等により、データベースサーバ１上のデータベースにアクセスするためのＳＱＬ文を発行する機能を有するサーバ機器もしくはＰＣ（Personal Computer）等の情報処理装置である。これらのアプリケーションサーバ２やクライアント端末３の機能をデータベースサーバ１の筐体と同じ筐体上に構成することも可能である。

データベースサーバ１は、アプリケーションサーバ２上のアプリケーションプログラムや、クライアント端末３上でのユーザの操作等によりアクセスされるデータベースを保持・管理する機能を有し、例えば、データベース管理システム（ＤＢＭＳ）等のミドルウェアからなるデータベース管理部１０を有する。

また、データベース管理部１０によって管理されるテーブルとして、アプリケーションプログラム等からの検索や更新の対象となる複数のユーザテーブルであるテーブルＡ（１２ａ）、テーブルＢ（１２ｂ）、…と、これらを検索条件に従って結合した情報についてのマテリアライズド（実体化）ビュー１３およびマテリアライズドビュー１３についてのインデックス１４とを有する。なお、各テーブルに対するＳＱＬによるアクセスは、一般的に、例えば、データベース管理部１０が有する最適化部１１等の機能により、処理コストが低くなるよう、複数テーブルへのアクセスの順序や方法などが最適化される。

本実施の形態では、テーブルＡ（１２ａ）やテーブルＢ（１２ｂ）等の各ユーザテーブルは、例えば、オンライン処理によりレコードの挿入や削除、更新等の操作が行われるトランザクションテーブル（例えば、それぞれのテーブルで１年あたり約４００万件のレコードが増加し、データの保持期限は最短で５年間など）であるものとする。また、これらのユーザテーブルからのデータの検索処理には、ユーザテーブル同士を結合してデータの抽出を行う処理があり、かつ、複数のテーブルに絞り込みの条件が分散しているものとする。この場合、上述したように、単一のテーブルに対する検索条件では対象データの件数が十分に絞り込めず、結合処理のコストが上昇してしまい、トランザクション処理に影響を与えてしまう場合が生じ得る。

そのため、本実施の形態では、上述したように、これらのテーブルの結合についてのマテリアライズドビュー１３およびマテリアライズドビュー１３についてのインデックス１４を作成して保持する。マテリアライズドビュー１３は、検索対象のユーザテーブルを検索処理時の結合条件で結合した結果から得られる情報をキャッシュ等により実体として保持する。また、インデックス１４は、マテリアライズドビュー１３のカラム情報に基づいて作成される。これらのテーブルのデータ構成等については後述する。

＜検索処理の流れ＞
図１は、本実施の形態における、インデックス１４の作成処理およびこれを利用した検索処理の流れの例について概要を示したフローチャートである。まず、管理者等のユーザは、例えば、データベースサーバ１のデータベース管理部１０を介して、検索対象の複数のユーザテーブルを結合するための情報として、対象のテーブル、これらの結合条件、および検索において絞り込みを行う際のカラムの情報を指定する（Ｓ０１）。これらの情報を個別に指定してもよいし、複数のユーザテーブルを結合して検索する処理を行うＳＱＬ文の形で指定してもよい。

その後、例えば、データベース管理部１０の最適化部１１等により、ステップＳ０１で指定された条件に基づくユーザテーブルの結合についてマテリアライズドビュー１３を作成する（Ｓ０２）。ユーザが手動でマテリアライズドビュー１３を作成してもよい。さらに、最適化部１１等により、ステップＳ０２で作成したマテリアライズドビュー１３についてのインデックス１４を作成する（Ｓ０３）。これも同様に、ユーザが手動でインデックス１４を作成してもよい。

その後、アプリケーションサーバ２上のアプリケーションプログラムや、クライアント端末３上でのユーザの操作等により、検索対象のテーブルのデータを検索するためのＳＱＬ文を発行することで、データベースサーバ１のデータベース管理部１０は検索条件の指定を受け付ける（Ｓ０４）。ここでの検索条件は、上述したように、ステップＳ０２で作成したマテリアライズドビュー１３のカラムによって指定する。もしくは、検索対象のユーザテーブルを結合して検索処理を行うＳＱＬを指定し、最適化部１１等が内部的にマテリアライズドビュー１３のカラムを対象とした処理に変換するようにしてもよい。

検索条件が指定されると、データベース管理部１０は、指定された検索条件に基づいてインデックス１４によってデータの絞り込みを行う（Ｓ０５）。本実施の形態では、後述するように、インデックス１４は、検索対象の複数のテーブルに分散している検索条件のカラムを全て参照することができるよう作成されているため、インデックス１４のみのアクセスで、マテリアライズドビュー１３自体へのアクセスを行わずに対象データの絞り込みを行うことができる。

その後、ステップＳ０５で絞り込んだインデックス１４のデータ（図２の例における中間データｍに相当）と検索対象の各ユーザテーブルとを、インデックス１４に保持している、検索対象の各テーブルの格納場所情報に基づいてそれぞれ結合し（Ｓ０６）、得られたデータを検索結果として出力して（Ｓ０７）、処理を終了する。

＜インデックス作成処理とデータ構成＞
図４は、インデックス１４を作成する際の処理の流れと各テーブルの具体的なデータの例について概要を示した図である。図４の例では、アプリケーションサーバ２上のアプリケーションプログラムや、クライアント端末３上でのユーザの操作等により、検索対象のテーブル（テーブルＡ（１２ａ）および／またはテーブルＢ（１２ｂ））のデータの更新処理が実行された結果、マテリアライズドビュー１３に保持するデータが変更されるような場合、すなわち、検索対象のテーブルに対するレコードの挿入、削除、マテリアライズドビュー１３の保持するカラムに対応するカラムの値の更新等が行われた場合に、データベース管理部１０は、検索対象のテーブルの更新と同期して、リアルタイムでマテリアライズドビュー１３のデータ（キャッシュ）の更新と、これに伴うインデックス１４の更新を行って、検索対象のテーブルの更新内容を反映させる。

図４の例において、検索対象のユーザテーブルであるテーブルＡ（１２ａ）は、カラムとして、例えば、各レコードの格納場所の情報である“アドレスＡ”と、他のテーブル（図４の例ではテーブルＢ（１２ｂ））と結合する際のキーとなる“結合キー”と、検索条件として指定される“ユーザＩＤ”、およびその他のカラムを有している。同様に、テーブルＢ（１２ｂ）は、カラムとして、例えば、各レコードの格納場所の情報である“アドレスＢ”と、他のテーブル（図４の例ではテーブルＡ（１２ａ））と結合する際のキーとなる“結合キー”と、検索条件として指定される“完了フラグ”、およびその他のカラムを有している。

マテリアライズドビュー１３は、検索処理で指定される結合条件によって検索対象のユーザテーブル同士（テーブルＡ（１２ａ）とテーブルＢ（１２ｂ））を結合した情報から、結合条件のカラム（図４の例では“結合キー”）と、検索処理で検索条件（絞り込みの条件）に指定されるカラム（図４の例では“ユーザＩＤ”、“完了フラグ”）と、検索対象のテーブルのレコードについての格納アドレス情報や行番号情報などの格納場所情報を保持するカラム（図４の例では“アドレスＡ”、“アドレスＢ”）を少なくとも有する。

また、インデックス１４は、マテリアライズドビュー１３に対して作成され、検索処理で検索条件（絞り込みの条件）に指定されるカラム（図４の例では“ユーザＩＤ”、“完了フラグ”）と、検索対象のテーブルのレコードについての格納アドレス情報や行番号情報などの格納場所情報を保持するカラム（図４の例では“アドレスＡ”、“アドレスＢ”）を有する。

＜インデックス使用処理とデータ構成＞
図５は、インデックス１４を使用して検索処理を実行する際の処理の流れと各テーブルの具体的なデータの例について概要を示した図である。アプリケーションサーバ２上のアプリケーションプログラムや、クライアント端末３上でのユーザの操作等により、検索対象のテーブル（テーブルＡ（１２ａ）、テーブルＢ（１２ｂ））のデータを検索する際、検索条件として、マテリアライズドビュー１３のカラムを指定して対象データを絞り込む（例えば、図５の例では、“ユーザＩＤ＝ｕｓｅｒ０１”かつ“完了フラグ＝０”など）。このとき、図５に示すように、マテリアライズドビュー１３についてのインデックス１４が使用され、対象データが絞り込まれる。

対象データを絞り込んだ後、インデックス１４に保持する格納場所情報（格納アドレス情報や行番号情報など）を保持するカラム（図５の例では、“アドレスＡ”、“アドレスＢ”）の情報を使用して検索対象のテーブル（テーブルＡ（１２ａ）、テーブルＢ（１２ｂ））の対象レコードのデータを抽出して結合し、結果テーブルを得てこれを検索結果として出力する。これにより、マテリアライズドビュー１３へのアクセスに対して、実際のデータへのアクセスはインデックス１４のみとし、マテリアライズドビュー１３自体へのアクセスが行われないようにすることができる。なお、結果テーブルには、検索対象の各テーブルを結合する際に他のカラムの情報（図５の例では、“スコア”や“評価”などのカラム）を追加取得して含めてもよいことは当然である。

このように、マテリアライズドビュー１３についてのインデックス１４によって、検索対象の複数のテーブル（テーブルＡ（１２ａ）、テーブルＢ（１２ｂ））に分散している検索条件を全て参照することが可能となる。従って、検索処理の最初にインデックス１４によって対象データの絞り込みを行うことで、検索対象の各テーブルの結合処理を行う前に対象データを十分に絞り込んだ上で結合処理を行うことができる。これにより、対象データの絞り込み条件が複数のテーブルに分散している場合の検索処理において、リソースへのアクセス量と結合処理回数を低減させることができ、検索処理の性能を向上させることが可能となる。

以上に説明したように、本発明の一実施の形態であるデータベース処理方法によれば、検索処理の際のテーブルの結合条件によって検索対象の複数のテーブルを結合したマテリアライズドビュー１３、およびこれについてのインデックス１４を作成する。検索処理の際は、検索条件としてマテリアライズドビュー１３のカラムを指定することで、インデックス１４によって対象データの絞り込みを行い、インデックス１４に保持された格納場所情報に基づいて各検索対象のテーブルを検索して結合することで検索結果を得る。これにより、検索対象のテーブルの結合処理の前に対象データを十分に絞り込むことができ、結合処理のコストを抑えて検索処理時間を向上させることが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、複数テーブルを結合してデータを検索する際に処理効率を向上させるデータベース処理方法に利用可能である。

１…データベースサーバ、２…アプリケーションサーバ、３…クライアント端末、４…ネットワーク、
１０…データベース管理部、１１…最適化部、１２ａ、ｂ…テーブルＡ、Ｂ、１３…マテリアライズドビュー、１４…インデックス。

Claims (3)

1. コンピュータにより、指定された検索条件に基づいて、検索対象の複数のテーブルを結合して対象データを絞り込み、検索結果を得るデータベース処理方法であって、
   前記コンピュータは、
   前記検索条件において指定可能なカラムに基づく結合条件に基づいて前記複数のテーブルを結合した情報について、前記検索条件において指定可能な第１のカラム、各レコードの前記各テーブルにおける格納場所の情報を保持する第２のカラム、および前記結合条件に係る第３のカラムとを少なくとも有するマテリアライズドビューを作成する第１のステップと、
   前記マテリアライズドビューについて、前記第１のカラム、および前記第２のカラムを有するインデックスを作成する第２のステップとを実行することを特徴とするデータベース処理方法。
2. 請求項１に記載のデータベース処理方法において、
   前記コンピュータは、さらに、
   前記マテリアライズドビューの前記第１のカラムを含むカラムの指定によって前記検索条件の指定を受け付ける第３のステップと、
   前記検索条件に基づいて前記インデックスによってデータの絞り込みを行う第４のステップと、
   前記第４のステップにおいて絞り込まれたデータと、検索対象の前記各テーブルとを、前記第２のカラムの情報に基づいてそれぞれ結合する第５のステップと、
   前記第５のステップにおいて得られたデータを検索結果として出力する第６のステップとを実行することを特徴とするデータベース処理方法。
3. 請求項２に記載のデータベース処理方法において、
   前記第４のステップでは、前記インデックスのデータへのアクセスのみで絞り込みを行い、前記マテリアライズドビューへのアクセスを行わないことを特徴とするデータベース処理方法。

Images