(57)【要約】      （修正有）【課題】テーブルの参照関係が階層化されている場合であっても、リレーションを自動的に作成することが可能なデータベース管理方法を提供する。【解決手段】データベース管理方法は、複数のテーブルによって構成されるデータベースからデータを検索するためのものであり、データが格納された目的カラムを含むテーブルを特定するステップＳ２と、データを抽出する際に利用される条件カラムの全てが、特定されたテーブルに含まれているか否かを判断するステップＳ３と、特定されたテーブルに含まれていない条件カラムがある場合に、その条件カラムが全て現れるまで、特定されたテーブルから参照関係にあるテーブルを辿るステップＳ４と、特定されたテーブルから、最後の条件カラムを含むテーブルまでを関連付けするステップＳ７と、を備える。【選択図】図３
2020177483.tif 000002
【特許請求の範囲】
【請求項１】
複数のテーブルによって構成されるデータベースからデータを検索するためのデータベース管理方法であって、
前記データが格納された目的カラムを含むテーブルを特定するステップと、
前記データを抽出する際に利用される条件カラムの全てが、特定されたテーブルに含まれているか否かを判断するステップと、
前記特定されたテーブルに含まれていない条件カラムがある場合に、その条件カラムが全て現れるまで、前記特定されたテーブルから参照関係にあるテーブルを辿るステップと、
前記特定されたテーブルから、最後の条件カラムを含むテーブルまでを関連付けするステップとを備えることを特徴とするデータベース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理方法に関する。
【背景技術】
【０００２】
従来、複数のテーブルによって構成されるデータベースからデータを検索するためのデータベースシステムが知られている（たとえば、特許文献１参照）。
【０００３】
特許文献１のデータベースシステムでは、複数の実テーブルの間にリレーションを設定して１つのビューが構築されている。このデータベースシステムは、複数の実テーブルから必要なカラムだけを抽出して仮想的に新たなテーブルを作成する機能を有する。具体的には、検索対象のカラム数が最も多い実テーブルを抽出する処理と、抽出した実テーブルのカラムと同じデータが入っているカラムを残りの実テーブルから除外する処理とが繰り返し行われ、順次抽出された実テーブルが結合されて１つの結合テーブルが作成される。これにより、ユーザがデータベースの検索を行うときに、不要な実テーブルがジョインの対象とはされずに、必要最小限の実テーブルだけで１つの結合テーブルを作ることが可能である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２０９０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、上記した従来のデータベースシステムでは、必要最小限の実テーブルだけで１つの結合テーブルを作ることが可能であるが、テーブルの参照関係が階層化されている場合については何ら考慮されていない。
【０００６】
本発明は、上記の課題を解決するためになされたものであり、本発明の目的は、テーブルの参照関係が階層化されている場合であっても、リレーションを自動的に作成することが可能なデータベース管理方法を提供することである。
【課題を解決するための手段】
【０００７】
本発明によるデータベース管理方法は、複数のテーブルによって構成されるデータベースからデータを検索するためのものであり、データが格納された目的カラムを含むテーブルを特定するステップと、データを抽出する際に利用される条件カラムの全てが、特定されたテーブルに含まれているか否かを判断するステップと、特定されたテーブルに含まれていない条件カラムがある場合に、その条件カラムが全て現れるまで、特定されたテーブルから参照関係にあるテーブルを辿るステップと、特定されたテーブルから、最後の条件カラムを含むテーブルまでを関連付けするステップとを備える。
【０００８】
このように構成することによって、データ（検索対象のデータ）が格納された目的カラムを含むテーブルから、最後の条件カラムを含むテーブルまでを関連付けることにより、テーブルの参照関係が階層化されている場合であっても、リレーション（新しいテーブル）を自動的に作成することができる。
【発明の効果】
【０００９】
本発明のデータベース管理方法によれば、テーブルの参照関係が階層化されている場合であっても、リレーションを自動的に作成することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態による情報処理システムの概略構成を示したブロック図である。
【図２】図１の情報処理システムのデータベースを説明するための図である。
【図３】図１の情報処理システムによるリレーションの自動作成時の動作例を説明するためのフローチャートである。
【図４】本実施形態の変形例において直列的な参照関係で全ての条件カラムが現れない場合を説明するための図である。
【発明を実施するための形態】
【００１１】
以下、本発明の一実施形態を説明する。
【００１２】
まず、図１を参照して、本発明の一実施形態によるデータベース管理方法を実行可能な情報処理システム１００の概略構成について説明する。
【００１３】
情報処理システム１００は、図１に示すように、サーバ装置１およびクライアント装置２を備える。サーバ装置１およびクライアント装置２は、ネットワーク１５０を介して接続され、通信可能に設けられている。
【００１４】
サーバ装置１は、クライアント装置２からのリクエストに基づいて情報処理を行い、そのリクエストに応じたレスポンスをクライアント装置２に返すように構成されている。このサーバ装置１は、データベース（以下、「ＤＢ」という）１１と、ＤＢ管理部１２と、複数のＡｐｐ部１３とを含んでいる。
【００１５】
ＤＢ１１は、整理されたデータの集合であり、そのデータが格納（記憶）されている。ＤＢ１１は複数のテーブルによって構成され、各テーブルでは属性（カラム）が設定され、各テーブルのタプル（ロウ）が格納されるデータに相当する。
【００１６】
ＤＢ管理部１２は、ＤＢ１１を管理および操作する機能を有する。ＤＢ管理部１２は、Ａｐｐ部１３からの要求に応じてＤＢ１１からデータを検索し、その検索結果をＡｐｐ部１３に返すように構成されている。
【００１７】
Ａｐｐ部１３は、ＤＢ１１を利用可能であり、クライアント装置２からのリクエストに応じてレスポンスを返すように構成されている。すなわち、Ａｐｐ部１３は、クライアント装置２からのリクエストに基づいてＤＢ管理部１２への要求を生成するとともに、ＤＢ管理部１２からの検索結果に基づいてクライアント装置２へのレスポンスを生成する機能を有する。たとえば、複数のＡｐｐ部１３はそれぞれ異なるアプリケーションである。
【００１８】
ここで、ＤＢ管理部１２は、ＤＢ１１の複数のテーブルからリレーション（新しいテーブル）を自動的に作成可能に構成されている。このリレーションの自動作成は、たとえば、ＤＢ１１のテーブルや属性が変更された場合に行われる。なお、テーブルや属性の変更には、テーブルや属性の追加、および、テーブルや属性の削除が含まれる。そして、ＤＢ管理部１２は、リレーションの自動作成後においては、その自動作成されたリレーションを用いてＤＢ１１からデータを検索するように構成されている。すなわち、ＤＢ管理部１２は、ＤＢ１１のテーブルや属性が変更された場合に、リレーションを自動作成することにより、ＤＢ１１から所望のデータを検索することが可能になる。
【００１９】
−ＤＢの一例−
次に、リレーションの自動作成の説明前に、図２を参照して、ＤＢ１１の一例について説明する。
【００２０】
たとえば、ＤＢ１１は、図２に示すように、「テーブルＡ」、「テーブルＢ」、「テーブルＣ」、「テーブルＤ」、「テーブルＥ」および「テーブルＦ」によって構成されている。
【００２１】
「テーブルＡ」では、属性（カラム）として、「属性１」、「属性２」、「属性３」、「属性４」、「属性５」、「属性６」、「属性７」、「属性８」、「属性９」および「属性１０」が設定されている。「テーブルＢ」では、属性として、「属性３」、「属性３１」、「属性３２」および「属性３３」が設定されている。「テーブルＣ」では、属性として、「属性３１」、「属性３１１」、「属性３１２」および「属性３１３」が設定されている。「テーブルＤ」では、属性として、「属性３」、「属性３４」、「属性３５」、「属性３６」および「属性３１」が設定されている。「テーブルＥ」では、属性として、「属性３４」、「属性３４１」および「属性３４２」が設定されている。「テーブルＦ」では、属性として、「属性３４１」、「属性３４１１」および「属性３４１２」が設定されている。
【００２２】
なお、「テーブルＡ」の「属性３」、「テーブルＢ」の「属性３１」、「テーブルＤ」の「属性３４」、「テーブルＤ」の「属性３１」、および、「テーブルＥ」の「属性３４１」は、他のテーブルから参照している属性であり、その他の属性は、数値または文字列が直接入力される属性、または、他の属性を引用した計算結果（数式）が入力される属性である。このため、「テーブルＡ」および「テーブルＢ」が参照関係にあり、「テーブルＢ」および「テーブルＣ」が参照関係にあり、「テーブルＡ」および「テーブルＤ」が参照関係にあり、「テーブルＤ」および「テーブルＣ」が参照関係にあり、「テーブルＤ」および「テーブルＥ」が参照関係にあり、「テーブルＥ」および「テーブルＦ」が参照関係にある。
【００２３】
−リレーションの自動作成−
次に、図２を参照して、リレーションの自動作成について説明する。このリレーションの自動作成は、たとえば、ＤＢ１１のテーブルや属性が変更された場合に行われる。また、リレーションの自動作成は、検索設定毎（検索対象のデータが格納された目的カラムと、検索対象のデータを抽出する際に利用されるデータが格納された条件カラムとの組み合わせ毎）に行われる。
【００２４】
まず、検索設定（目的カラムおよび条件カラム）が確認される。図２の例では、目的カラムが「属性５」であり、条件カラムが「属性１」、「属性３４２」および「属性３４１１」である。
【００２５】
次に、目的カラムを含むテーブルが特定され、その特定されたテーブルに全ての条件カラムが含まれているか否かが判断される。図２の例では、「属性５」を含む「テーブルＡ」が特定され、その「テーブルＡ」に「属性１」が含まれているものの、「テーブルＡ」には「属性３４２」および「属性３４１１」が含まれていない。
【００２６】
次に、特定されたテーブル（目的カラムを含むテーブル）に含まれていない条件カラムがある場合には、目的カラムを含むテーブルから参照関係にあるテーブルが辿られ、全ての条件カラムが現れるか否かが判断される。すなわち、参照関係にあるテーブルを辿ることにより、条件カラムが探索される。そして、参照関係にあるテーブルを辿ることにより全ての条件カラムが現れた場合には、目的カラムを含むテーブルから、最後の条件カラムを含むテーブルまでをリレーション案として認定する。なお、参照関係にあるテーブルを辿っても条件カラムが全て現れなかった場合には、リレーション案として認定されない。この条件カラムの探索は、たとえば全ての経路について行われる。
【００２７】
図２の例では、「テーブルＡ」に「属性３４２」および「属性３４１１」が含まれていないことから、「テーブルＡ」を起点として「属性３４２」および「属性３４１１」が探索される。
【００２８】
具体的には、「テーブルＡ」の「属性３」が「テーブルＢ」の「属性３」を参照しているため、「テーブルＢ」に「属性３４２」および「属性３４１１」が含まれているか否かが判断される。「テーブルＢ」には「属性３４２」および「属性３４１１」が含まれていないことから、「テーブルＡ」から「テーブルＢ」に至る経路はリレーション案として認定されない。また、「テーブルＢ」が参照するテーブルの有無が判断される。「テーブルＢ」の「属性３１」が「テーブルＣ」の「属性３１」を参照しているため、「テーブルＣ」に「属性３４２」および「属性３４１１」が含まれているか否かが判断される。「テーブルＣ」には「属性３４２」および「属性３４１１」が含まれていないことから、「テーブルＡ」から「テーブルＢ」を介して「テーブルＣ」に至る経路はリレーション案として認定されない。また、「テーブルＣ」が参照するテーブルの有無が判断される。「テーブルＣ」が参照するテーブルが無いので、「テーブルＢ」を経由する経路の探索が終了される。
【００２９】
また、「テーブルＡ」の「属性３」が「テーブルＤ」の「属性３」を参照しているため、「テーブルＤ」に「属性３４２」および「属性３４１１」が含まれているか否かが判断される。「テーブルＤ」には「属性３４２」および「属性３４１１」が含まれていないことから、「テーブルＡ」から「テーブルＤ」に至る経路はリレーション案として認定されない。また、「テーブルＤ」が参照するテーブルの有無が判断される。
【００３０】
「テーブルＤ」の「属性３１」が「テーブルＣ」の「属性３１」を参照しているが、「テーブルＣ」は既に探索され、「属性３４２」および「属性３４１１」が無いことが確認されている。このため、「テーブルＡ」から「テーブルＤ」を介して「テーブルＣ」に至る経路はリレーション案として認定されない。
【００３１】
「テーブルＤ」の「属性３４」が「テーブルＥ」の「属性３４」を参照しているため、「テーブルＥ」に「属性３４２」および「属性３４１１」が含まれているか否かが判断される。「テーブルＥ」には、「属性３４２」が含まれているが、「属性３４１１」が含まれていない。したがって、「テーブルＡ」から「テーブルＤ」を介して「テーブルＥ」に至る経路はリレーション案として認定されない。また、「テーブルＥ」が参照するテーブルの有無が判断される。「テーブルＥ」の「属性３４１」が「テーブルＦ」の「属性３４１」を参照しているため、「テーブルＦ」に「属性３４１１」が含まれているか否かが判断される。そして、「テーブルＦ」には「属性３４１１」が含まれており、この経路がリレーション案として認定される。つまり、「テーブルＡ」から「テーブルＤ」および「テーブルＥ」を介して「テーブルＦ」に至る経路では、全ての条件カラムが発見されることから、リレーション案として認定される。この場合、「テーブルＦ」の「属性３４１１」が本発明の「最後の条件カラム」に相当する。
【００３２】
なお、図２の例ではリレーション案が１つであるが、全ての経路を探索して複数のリレーション案が認定された場合には、各リレーション案が評価され、いずれかのリレーション案がリレーションとして決定される。
【００３３】
［ＤＢ管理部の動作例］
次に、図３を参照して、上記のようなリレーションの自動作成を行うＤＢ管理部１２の動作例について説明する。なお、以下のフローは、たとえば、ＤＢ１１のテーブルや属性が変更された場合に、検索設定毎（目的カラムおよび条件カラムの組み合わせ毎）に行われる。また、以下の各ステップは、ＤＢ管理部１２により実行される。
【００３４】
まず、図３のステップＳ１において、検索設定（目的カラムおよび条件カラム）が確認される。なお、目的カラムは、検索対象のデータが格納されたカラムであり、条件カラムは、検索対象のデータを抽出する際に利用されるデータが格納されたカラムである。そして、ステップＳ２において、目的カラムを含むテーブルが特定される。
【００３５】
次に、ステップＳ３において、目的カラムを含むテーブル（特定されたテーブル）に、全ての条件カラムが含まれているか否かが判断される。そして、目的カラムを含むテーブルに、含まれていない条件カラムがある場合（特定されたテーブルに含まれていない条件カラムが１つ以上ある場合）には、ステップＳ４に移る。なお、目的カラムを含むテーブルに、全ての条件カラムが含まれている場合には、そのテーブルだけでデータを検索可能であることから、リレーションを作成する必要がないので、エンドに移る。
【００３６】
そして、ステップＳ４において、目的カラムを含むテーブルから参照関係にあるテーブルが辿られる。次に、ステップＳ５において、全ての条件カラムが現れたか否かが判断される。そして、全ての条件カラムが現れたと判断された場合には、ステップＳ６において、その経路がリレーション案として認定され、ステップＳ７に移る。その一方、未発見の条件カラムがあると判断された場合（条件カラムが揃っていない場合）には、その経路がリレーション案として認定されることなく、ステップＳ７に移る。
【００３７】
次に、ステップＳ７において、全ての経路が探索されたか否かが判断される。そして、全ての経路が探索されたと判断された場合には、ステップＳ８に移る。その一方、探索していない経路があると判断された場合には、ステップＳ４に戻り、その残りの経路が探索される。
【００３８】
このため、図２の例では、「テーブルＡ」から「テーブルＢ」に至る経路、「テーブルＡ」から「テーブルＢ」を介して「テーブルＣ」に至る経路、「テーブルＡ」から「テーブルＤ」に至る経路、「テーブルＡ」から「テーブルＤ」を介して「テーブルＣ」に至る経路、「テーブルＡ」から「テーブルＤ」を介して「テーブルＥ」に至る経路、および、「テーブルＡ」から「テーブルＤ」および「テーブルＥ」を介して「テーブルＦ」に至る経路が探索される。なお、「テーブルＡ」から「テーブルＤ」および「テーブルＥ」を介して「テーブルＦ」に至る経路はリレーション案として認定され、その他の経路はリレーション案として認定されない。また、「テーブルＡ」から「テーブルＤ」を介して「テーブルＣ」に至る経路については、「テーブルＡ」から「テーブルＢ」を介して「テーブルＣ」に至る経路の探索で条件カラムが無いことが判明している場合には、探索を行わないようにしてもよい。
【００３９】
次に、ステップＳ８において、リレーション案が複数あるか否かが判断される。そして、リレーション案が複数あると判断された場合には、ステップＳ９において、リレーション案が評価される。このリレーション案の評価では、たとえば、各リレーション案を用いて実際に検索を行い、その検索に要した時間を計測する。次に、ステップＳ１０において、検索に要した時間が最も短いリレーション案がリレーションとして決定され、エンドに移る。なお、リレーション案が１つであると判断された場合（ステップＳ８：No）には、ステップＳ１０において、そのリレーション案がリレーションとして決定され、エンドに移る。
【００４０】
−効果−
本実施形態では、上記のように、ＤＢ１１のテーブルや属性が変更された場合にリレーションを自動作成することによって、テーブルや属性の変更に容易に対応することができる。したがって、１つのＤＢ１１を複数のＡｐｐ部１３で共用しながら、Ａｐｐ部１３の変更や追加などに柔軟に対応することができる。
【００４１】
また、本実施形態では、条件カラムが全て現れるまで参照関係にあるテーブルを辿り、目的カラムを含むテーブルから最後の条件カラムを含むテーブルまでを関連付けしてリレーション案とすることによって、テーブルの参照関係が階層化されている場合であっても、リレーションを自動的に作成することができる。
【００４２】
また、本実施形態では、リレーション案が複数ある場合に各リレーション案を評価することによって、最適なリレーション案をリレーションとして採用することができる。
【００４３】
−他の実施形態−
なお、今回開示した実施形態は、すべての点で例示であって、限定的な解釈の根拠となるものではない。したがって、本発明の技術的範囲は、上記した実施形態のみによって解釈されるものではなく、特許請求の範囲の記載に基づいて画定される。また、本発明の技術的範囲には、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれる。
【００４４】
たとえば、上記実施形態では、目的カラムが単数であり、条件カラムが複数である例を示したが、これに限らず、目的カラムが複数であってもよいし、条件カラムが単数であってもよい。
【００４５】
また、上記実施形態では、直列的な参照関係で全ての条件カラムが発見されてリレーション案とされる例を示したが、これに限らず、並列的な参照関係で全ての条件カラムが発見される場合に、その並列的な参照関係がリレーション案とされるようにしてもよい。たとえば、図４に示す変形例のように、目的カラムが「属性５」であり、条件カラムが「属性１」、「属性３３」、「属性３６」および「属性３４２」である場合には、「テーブルＡ」から「テーブルＤ」を介して「テーブルＥ」に至る経路と、「テーブルＡ」から「テーブルＢ」に至る経路とにより、リレーション案が構成されていてもよい。
【００４６】
また、上記実施形態では、全ての条件カラムが発見される例を示したが、これに限らず、全ての条件カラムが発見されない場合には、より多くの条件カラムが発見された経路をリレーション案とするようにしてもよい。
【００４７】
また、上記実施形態では、各リレーション案を用いて実際に検索を行うことにより各リレーション案を評価する例を示したが、これに限らず、各リレーション案におけるテーブル数およびテーブルサイズなどに基づいて、各リレーション案を評価するようにしてもよい。
【産業上の利用可能性】
【００４８】
本発明は、複数のテーブルによって構成されるデータベースからデータを検索するためのデータベース管理方法に利用可能である。
【符号の説明】
【００４９】
１      サーバ装置
２      クライアント装置
１１    ＤＢ
１２    ＤＢ管理部
１３    Ａｐｐ部
１００  情報処理システム
１５０  ネットワーク
【図１】
2020177483.tif 000003
【図２】
2020177483.tif 000004
【図３】
2020177483.tif 000005
【図４】
2020177483.tif 000006