JP2005284432A - データベースシステムとデータベース設計方法およびデータベースとデータベースの検索方法ならびにプログラム - Google Patents

Abstract

【課題】 情報取得する場合に出力項目が同じ内容になるテーブル構成のデータベースにおけるリソースの消費を抑える。
【解決手段】 データベース２５に格納した情報を、入力された検索条件に対応して出力するデータベースシステムであって、データベース２５における情報検索用の入力条件項目がビット型からなり、検索に入力された入力条件をビット値に変換し、このビット値とデータベース２５における当該入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立とする手段（ＤＡ２４）を設けた構成とする。このＤＡ２４では、検索に入力された入力条件をビット値に変換し、このビット値とデータベースにおける当該入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立とする条件式を生成する。
【選択図】 図１

Description

本発明は、データベースにおけるデータの格納技術に係わり、特に、情報取得する場合に出力項目が同じ内容になるテーブル構成のデータベースにおけるリソースの消費を抑えるのに好適なデータ管理技術に関するものである。

従来のデータベースのリソースの消費を抑えるための技術として、例えば、特許文献１に記載のように、データベースに登録されたデータに対する重複チェックを行う技術がある。この技術では、特定の項目データの重複を検出すると、当該ファイルデータを一覧表示し、指示に応じて重複データを削除している。

また、特許文献２においては、データベースファイルを所定の記憶容量を単位とするブロックに分割し、各ブロック毎の使用・未使用情報を格納しておき、使用されているブロック数からデータベースファイルのレコードの格納率を求める技術が記載されている。

また、特許文献３では、データベースにおいては、「文字データ値」が記憶領域を消費することに着目して、データベースにおける文字データを統合管理することにより、記憶領域を大きく減少させる技術が記載されている。

この技術においては、一般のデータベースにおけるデータファイルでは、レコードのフィールドの属性の形でデータ値がそれぞれ格納されており、そのため文字データ値が多いと記憶領域を多く占有しているとの問題点、また、インデックスファイルは、データファイルにおけるレコードのフィールド毎に作成され、そのインデックスと定められたフィールドのデータ値毎に、データファイルのそのデータ値へとポインタを指定することにより定義しており、そのためフィールドの属性が文字であった場合、２重に記憶領域を確保せねばならず、同じ文字データ値が繰り返し利用されるファイルにおいては、同じデータ値にも関わらず記憶領域を数重に確保せねばならないとの問題点、また、複数のファイルで同じ文字データ値が使用されている場合、その文字データ値の変更が起きた時に、ファイル毎にそれぞれ同じ変更処理を行わねばならないという問題点を解決することを目的としている。

具体的には、文字データ値毎に文字データ値を一意に定めるコードと、そのデータ値が使用されているレコード件数である参照アカウントと、そのデータ値を有するファイルとレコードと、フィールドのポインタ値とを持つ文字コードファイルと、データ値が格納される文字データのフィールドに文字データ値を変換したコードを持つデータファイルとを含む構成としている。このように、特許文献３の技術は、データベースのテーブル項目に工夫を入れることにより、文字データ値による記憶領域の消費を抑えている。

しかし、これらの従来の技術では、出力項目におけるデータの重複に関しての考慮がなされていない。例えばＳＱＬ（Structured Query Language）サーバ等の動作するデータベースを参照する際、通常、入力条件項目をキャラクタコード型で指定している。そのため、データベースのレコード内容によっては、出力項目内容が同じとなるテーブル構成となるパターンがあり、重複するようなレコードが多数発生してしまうケースが度々ある。その場合、同じ内容のレコードにより、データベースのリソースを無駄に使用する結果となる。

特開平７−２９６００２号公報 特開平５−２４１９１８号公報 特開平７−２９６００２号公報

解決しようとする問題点は、従来の技術では、参照する際に指定される入力条件項目がキャラクタコード型である場合に、出力項目内容が同じとなるテーブル構成のデータベースにおけるリソースの消費を効率的に回避することができない点である。

本発明の目的は、上記課題を解決して、キャラクタコード型の入力条件項目で発生する出力項目内容の重複によるデータベースのリソースの無駄な使用を回避し、データベースのリソースの有効利用を可能とすることである。

上記目的を達成するため、本発明では、重複するレコードをまとめることにより、データベースのリソースを少なくする技術として、入力条件となる項目をキャラクタ型ではなく、ビット型にし、データベースの入力条件に対応する項目のビットをたてる。そして、参照する際、その項目（ビット）の論理積を条件とすることにより、共有化した同一のレコードを抽出することが可能となる。

本発明によれば、情報取得する場合に出力項目が同じ内容になるテーブル構成のデータベースにおけるリソースを大幅に削減することが可能となる。

以下、図を用いて本発明を実施するための最良の形態例を説明する。

図１は、本発明に係わるデータベースシステムの詳細構成例を示すブロック図であり、図２は、本発明に係わるデータベースシステムの概要構成例を示すブロック図、図３は、従来のテーブル構成例を示す説明図、図４は、図３におけるテーブルでのデータ格納構成例を示す説明図、図５は、図１におけるデータベースシステムのテーブル構成例を示す説明図、図６は、図５におけるテーブルでのデータ格納構成例を図３におけるテーブルでのデータ格納構成例との比較で示す説明図、図７は、図１におけるデータベースシステムでの第１のデータ共有例を示す説明図、図８は、図１におけるデータベースシステムでの第２のデータ共有例を示す説明図、図９は、図１におけるデータベースシステムでの第３のデータ共有例を示す説明図、図１０は、図１におけるデータベースシステムでの情報取得要求のためのＳＱＬ文の一例を示す説明図である。

図１および図２において、１はクライアント側コンピュータにインストールされているＷｅｂブラウザ、２〜４はサーバ側コンピュータにインストールされているＷｅｂサーバ（２）とアプリケーションサーバ（３）およびデータベースサーバ（４）であり、Ｗｅｂブラウザ１は情報の抽出要求１１，２１を行う機能と情報の抽出結果１７，２７を表示する機能を有し、図１に示すように、Ｗｅｂサーバ２はＷｅｂブラウザ１からの情報の抽出要求２１を受信するデータ要求受信機能（ＦＣ２２）、出力用画面を生成する機能（ＰＬ２６）を有し、アプリケーションサーバ３はデータ加工を行う処理機能（ＢＬ２３）とＳＱＬ文を生成する処理機能（ＤＡ２４）を有し、データベース（ＤＢ）サーバ４はデータベース２５を有している。

クライアント側コンピュータとサーバ側コンピュータのそれぞれは、ＣＰＵ（Central Processing Unit）や主メモリ、表示装置、入力装置、外部記憶装置からなるコンピュータ構成からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、各処理部の機能を実行する。

本例のデータベースシステムは、ＣＯＭ＋（Component Object Model plus、登録商標）を使用したＷｅｂオンラインシステムであり、図１のような構成で動作するものである。サーバ側コンピュータにおいて、ＩＩＳ（Internet Information Server／Internet Information Services）を有するＷｅｂサーバ２、ＣＯＭ＋が動作するアプリケーションサーバ３、ＳＱＬサーバでＤＢを管理しているＤＢサーバ４を最小構成として動作するシステムである。

図２において、クライアント側コンピュータでは、操作者が、Ｗｅｂブラウザ１の画面上での対話的操作で情報の抽出要求を行い、例えばインターネット等のネットワークを通してＷｅｂサーバ２に送り、Ｗｅｂサーバ２から、ＣＯＭ＋で制御しているアプリケーションサーバ３へ送る。

アプリケーションサーバ３においては、当該要求情報を抽出するためのＳＱＬ文を生成し、ＤＢサーバ４内ＳＱＬサーバ５に渡し、ＳＱＬサーバ５において実際にＳＱＬ７を発行する。そして、このＳＱＬ７によりデータベース６からデータ（レコード６ａ）を抽出し、抽出したデータ（レコード６ａ）をサーバ側でＨＴＭＬとして加工し、クライアント側へ情報の抽出結果画面１７として送信する。

図１に示すように、サーバ側の詳細な構成はＣＯＭ＋の概念である、ＦＣ（〜２２）、ＰＬ（〜２６）、ＢＬ（〜２３）、ＤＡ（〜２４）というレイヤに分けられたシステム構成となっている。

Ｗｅｂサーバ２内には、Ｗｅｂブラウザ１からのデータ要求２１を受け、下位層のＢＬを制御するためのＦＣ２２と、Ｗｅｂブラウザ１へ送信するための、データの抽出結果表示用画面を生成するＰＬ２６が設けられている。

また、アプリケーションサーバ３には、情報の加工及びＤＡ２４を制御するためのＢＬ２３と、ＤＢサーバ４のデータベース２５にアクセスするためのＳＱＬ文を生成制御するためのＤＡ２４が設けられている。

このサーバ側システムにおいて本発明に関連があるのは、ＤＢサーバ４のデータベース２５とそれにアクセスするためのＤＡ２４の部分である。

このような構成からなる本例のデータベースシステムでは、データベース２５における情報検索用の入力条件項目がビット型からなり、ＤＡ２４において、検索に入力された入力条件をビット値に変換し、このビット値とデータベースにおける当該入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立とする条件式を生成する。

すなわち、本例では、データベース２５内のレコード数を削減したデータベース設計方法として、データベース２５において格納された情報の検索抽出に用いる入力条件項目をビット型とし、この入力条件項目のビット値を、検索時に当該入力条件項目として入力される入力条件のビット値との論理積がこの入力条件のビット値となる値に定めている。

このように、本例のデータベース２５においては、格納された情報の検索抽出に用いる入力条件項目をビット型としており、この入力条件項目のビット値を、検索時に当該入力条件項目として入力される入力条件のビット値との論理積が、この入力条件のビット値となる値に定めている。

そして、データベース２５の検索方法として、検索に入力された入力条件のビット値とデータベース２５に登録された入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立としている。

これにより、従来は、データベースを参照する際、入力条件項目をキャラクタコード型で指定する場合が多く、レコード内容によっては、重複するようなレコードが多数発生してしまうケースが度々あったが、このようなレコード構成になった場合の問題を解決でき、データベースのリソースの消費を抑えることができる。

以下、このような本例のデータベースシステムの処理動作を、図３〜図１０に示す具体的な例を用いて説明する。まず、図３を用いて従来のデータベースシステムに関する説明を行う。ある情報を抽出する際に、図３のように種類３１、バージョン番号３２、グループ番号３３、コード（１）３４を主キーとして、情報（Ａ）３５を抽出できるテーブルを例として示す。

図３に示すテーブルでは、例えば入力条件項目であるバージョン番号とグループ番号をＣＲ（キャラクタ）型としており、このようなデータ型とした場合、図４に示すように、バージョン番号が「０１」（：Ｖｅｒ１．０）で、グループ番号が「０１」（：グループＡ）のレコード４１と、バージョン番号が「０２」（：Ｖｅｒ２．０）で、グループ番号が「０１」（：グループＡ）のレコード４１の情報Ａの内容が同じであり、また、バージョン番号が「０２」（：Ｖｅｒ２．０）で、グループ番号が「０２」（：グループＢ）のレコード４２と、バージョン番号が「０２」（：Ｖｅｒ２．０）で、グループ番号が「０３」（：グループＣ）のレコード４２の情報Ｄの内容が同じであった場合、同じデータ（レコード）を、データベース内に持たなければならず、合計６件のデータ（レコード）が必要となってしまう。

このように抽出する情報が同じになるレコードが多く存在する仕様になっているデータのため、データベースのリソースを無駄に消費している。

そこで、本例では、図５に示すように、入力条件項目であるバージョン番号とグループ番号をＣＲ（キャラクタ型）からＳＩ（スモールイント型）に変更し、ビット型で管理する。すなわち、入力条件項目５２のバージョン番号「Ｖｅｒ１．０」を「１＝（００００ ００００ ００００ ０００１）_２」、同バージョン番号「Ｖｅｒ２．０」を２＝（００００ ００００ ００００ ００１０）_２」とする。

また、入力条件項目５３のグループ番号「グループＡ」を「１＝（００００ ００００ ００００ ０００１）_２」、同グループ番号「グループＢ」および「グループＣ」を「２＝（００００ ００００ ００００ ００１０）_２」、「４＝（００００ ００００ ００００ ０１００）_２」に決める。

そして、例えば、図６に示すように、入力条件項目のバージョン番号（入力）が異なるが、情報内容が同じ情報Ａ６１，６２の場合、データベースの項目のバージョン番号（ＤＢ）にバージョン番号（入力）とバージョン番号（ＤＢ）の論理積を算術した値がバージョン番号（入力）と同じ値になるようにデータベースにおける入力条件項目のバージョン番号（ＤＢ）の値を設定する。

これにより、入力条件項目のバージョン番号（入力）が「（０１）_２」と「（１０）_２」であっても、同じレコード（情報Ａ６１，６２）を抽出することが可能となる。さらに、グループ番号の項目も同様にできる。すなわち、入力条件項目のグループ番号（入力）が異なるが、情報内容が同じ情報Ｄ６３，６４の場合、データベースにおける項目のグループ番号（ＤＢ）にグループ番号（入力）とグループ番号（ＤＢ）の論理積を算術した値がグループ番号（入力）と同じ値になるようにデータベースにおける入力条件項目のグループ番号（ＤＢ）の値を設定する。これにより、検索時に検索条件として入力されたグループ番号（入力）が「（０１０）_２」と「（１００）_２」であっても、同じレコード（情報Ｄ６３，６４）を抽出することが可能となる。

この結果として、図４の従来技術におけるテーブルが６レコードであったのに対し、図６に示す例では、４レコードのテーブルとなり、データベースのリソースの無駄な消費が回避されている。

より詳細には、図７に示すように、バージョン番号の入力条件項目が異なり（「０１」、「１０」）、他の入力条件項目（グループ番号、コード）が同じレコード７１，７２の場合、１つのレコード７３にまとめられ、全体のレコード数が４件から３件へと削減される。

また、図８に示すように、グループ番号の入力条件項目が異なり（「００１」、「０１０」、「１００」）、他の入力条件項目（バージョン番号、コード）が同じレコード８１〜８３の場合、それぞれが１つのレコード８４にまとめられ、全体のレコード数が４件から２件に削減される。

さらに、図９に示すように、バージョン番号とグループ番号のそれぞれの入力条件項目が異なっているパターンに関しても同じことがいえる。すなわち、３つのレコード８１〜８３，８５が１つのレコード８６にまとめられ、全体のレコード数が５件から２件に削減される。

このようの情報Ａを抽出する場合には、図１０で示すようなＳＱＬとなる。図１０に示すＳＱＬは、情報Ａを取得要求するためのものであり、所望の情報を取得するための入力情報としては、「種類」、「バージョン番号」、「グループ番号」、「コード（１）」が定義され、取得結果の出力情報としては、「コード（１）」と「情報Ａ」が定義され、そして、情報取得のための条件として、「種類（入力）＝種類（データ） ＡＮＤ コード１（入力）＝コード１（データ） ＡＮＤ バージョン番号（入力）＆バージョン番号（データ）＝バージョン番号（入力） ＡＮＤ グループ番号（入力）＆グループ番号（データ）＝グループ番号（入力）」からなる。

ＳＱＬにおける行１０１，１０２のように、ＳＱＬの条件文にバージョン番号（入力）とバージョン番号（ＤＢ）の論理積をとり、その結果がバージョン番号（入力）と同じになれば、条件が成立し、共有化されたレコードを抽出できる。さらに、この条件をグループ番号でも適応させることにより、この２つのビット化された条件を指定することにより、共有化したレコードを取得できるようになる。

以上、図１〜図１０を用いて説明したように、本例では、データベース２５における情報検索用の入力条件項目がビット型からなる。そして、検索に入力された入力条件をビット値に変換し、このビット値とデータベース６，２５における当該入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立とする手段（ＤＡ２４）を設けた構成とする。このＤＡ２４では、検索に入力された入力条件をビット値に変換し、このビット値とデータベース６，２５における当該入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立とする条件式を生成する。

このように本例では、データベース６，２５内のレコード数を削減したデータベース設計方法として、データベース６，２５において格納された情報６ａの検索抽出に用いる入力条件項目をビット型とし、この入力条件項目のビット値を、検索時に当該入力条件項目として入力される入力条件のビット値との論理積がこの入力条件のビット値となる値に定めている。

すなわち、本例のデータベース６，２５では、データベース６，２５において格納された情報６ａの検索抽出に用いる入力条件項目がビット型であり、この入力条件項目のビット値を、検索時に当該入力条件項目として入力される入力条件のビット値との論理積が、この入力条件のビット値となる値に定めている。

そして、データベース６，２５の検索方法として、検索に入力された入力条件のビット値とデータベースに登録された入力条件項目のビット値との論理積が、入力された入力条件のビット値と同じとなれば条件の成立としている。

これにより、従来は、データベースを参照する際、入力条件項目をキャラクタコード型で指定しているので、レコード内容によっては、重複するようなレコードが多数発生してしまうケースが度々あったが、このようなレコード構成になった場合の問題を解決でき、データベース６，２５のリソースの消費を抑えることができる。

尚、本発明は、図１〜図１０を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、ＳＱＬサーバの動作するデータベースを例として説明したが、本発明は、特にＳＱＬサーバに特化したものではなく、データベースから情報取得する場合において、出力項目が同じ内容になるテーブルに適応できる。すなわち、本発明は、データベース内レコードにおいて、入力条件項目が異なり、同じ出力内容が多数存在するレコード構成の場合に有効で、入力条件項目をビット化し、同じ出力レコードをまとめることにより、データベース内レコード数を削減可能とするものである。

また、本例のサーバ側コンピュータやクライアント側コンピュータのコンピュータ構成例に関しても、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良い。また、本例では、光ディスクを記録媒体として用いているが、ＦＤ（Flexible Disk）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。

本発明に係わるデータベースシステムの詳細構成例を示すブロック図である。 本発明に係わるデータベースシステムの概要構成例を示すブロック図である。 従来のテーブル構成例を示す説明図である。 図３におけるテーブルでのデータ格納構成例を示す説明図である。 図１におけるデータベースシステムのテーブル構成例を示す説明図である。 図５におけるテーブルでのデータ格納構成例を図３におけるテーブルでのデータ格納構成例との比較で示す説明図である。 図１におけるデータベースシステムでの第１のデータ共有例を示す説明図である。 図１におけるデータベースシステムでの第２のデータ共有例を示す説明図である。 図１におけるデータベースシステムでの第３のデータ共有例を示す説明図である。 図１におけるデータベースシステムでの情報取得要求のためのＳＱＬ文の一例を示す説明図である。

符号の説明

１：Ｗｅｂブラウザ、２：Ｗｅｂサーバ、３：アプリケーションサーバ、４：ＤＢサーバ、５：ＳＱＬサーバ、６：データベース、６ａ：レコード、７：ＳＱＬ、１１，２１：情報の抽出要求、１７，２７：情報の抽出結果、２２：ＦＣ、２３：ＢＬ、２４：ＤＡ、２５：データベース、２６：ＰＬ、３１：種類、３２：バージョン番号、３３：グループ番号、３４：コード（１）、３５：情報（Ａ）、４１，４２：レコード、５１：入力条件項目（種類）、５２：入力条件項目（バージョン番号）、５３：入力条件項目（グループ番号）、５４：入力条件項目（コード１）、５５：検索対象項目（情報Ａ）、６１，６２：情報Ａ、６３，６４：情報Ｄ、７１〜７３：レコード、８１〜８６：レコード、１０１，１０２：ＳＱＬにおける行。

Claims (5)

1. データベースに格納した情報を、入力された検索条件に対応して出力するデータベースシステムであって、
   上記データベースにおける情報検索用の入力条件項目がビット型からなり、
   検索に入力された入力条件をビット値に変換し、該ビット値と上記データベースにおける当該入力条件項目のビット値との論理積が、上記入力された入力条件のビット値と同じとなれば条件の成立とする手段を設けることを特徴とするデータベースシステム。
2. データベース内のレコード数を削減したデータベース設計方法であって、
   データベースにおいて格納された情報の検索抽出に用いる入力条件項目をビット型とし、該入力条件項目のビット値を、検索時に当該入力条件項目として入力される入力条件のビット値との論理積が該入力条件のビット値となる値に定めることを特徴とするデータベース設計方法。
3. データベースにおいて格納された情報の検索抽出に用いる入力条件項目がビット型であり、
   該入力条件項目のビット値を、検索時に当該入力条件項目として入力される入力条件のビット値との論理積が該入力条件のビット値となる値に定めたことを特徴とするデータベース。
4. 請求項３に記載のデータベースの検索方法であって、
   検索に入力された入力条件のビット値と上記データベースに登録された入力条件項目のビット値との論理積が、上記入力された入力条件のビット値と同じとなれば条件の成立とすることを特徴とするデータベースの検索方法。
5. コンピュータに、請求項４に記載のデータベースの検索方法における処理手順を実行させるためのプログラム。

Images