(57)【特許請求の範囲】
【請求項１】
設定最大数及び設定最小数の範囲で使用頻度の高いデータが格納される活用データベースと、使用頻度の低いデータが格納される倉庫データベースと、要求元からデータの検索要求、新規登録要求及び削除要求のいずれかを受け付ける問い合わせ要求処理部と、いずれかの前記要求に応じて前記活用データベース及び倉庫データベースを管理するデータ管理部とを備えるデータベース管理システムにおいて、
前記データ管理部は、
前記検索要求に対し前記活用データベースを検索し、該当するデータが存在すると該データを前記要求元に送信し、該当するデータが不存在であると次に前記倉庫データベースを検索し、該当するデータが存在すると該データを前記要求元に送信すると共に、送信したデータを前記倉庫データベースから前記活用データベースへ移動させ、かつ該移動で前記活用データベースのデータ数が前記設定最大数を越えると該活用データベース中の最も使用頻度の低いデータを前記倉庫データベースに移動させ、
前記新規登録要求に対し新規データを前記活用データベースに登録し、該登録で該活用データベースのデータ数が前記設定最大数を越えると該活用データベース中の最も使用頻度の低いデータを前記倉庫データベースに移動させ、
前記削除要求に対し前記活用データベース中の該当するデータを削除すると共に、該削除で前記活用データベースのデータ数が前記設定最小数以下になると前記倉庫データベース中の最も使用頻度の高いデータを前記活用データベースに移動させる、
ことを特徴とするデータベース管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、多量のデータを効率よく高速アクセスすることのできるデータベース管理システムに関する。
【０００２】
【従来の技術】
ＣＡＤシステムは、コンピュータを用いた図面作成用のソフトウェアとして、様々な分野で利用されている。例えば、プリント回路基板等の設計にこのＣＡＤシステムを利用する場合、設計時に部品ライブラリを格納したデータベースが参照され、必要な部品の図形や特性等を入手する。このデータベースには数万から数十万件の回路部品に関する結線用イメージデータや電気的特性データ等が格納されている。設計者はＣＡＤワークステーションを操作しながら必要な部品のデータをこのデータベースに問い合わせ、設計や作図編集等に利用している。
【０００３】
プリント回路基板の設計には、極めて多数の部品データを必要とする。しかしながら、多量のデータを格納したデータベースには、個々の部品データを取り出すために必要なアクセス時間が比較的長時間かかるものがある。その場合、設計者は、必要な部品データのリストを作成して問い合わせ要求を編集しバッチ処理とする。データベース側では問い合せ要求を満たす全てのデータについて検索等の処理が終了した後で、その結果を設計者に通知するようにしている。
【０００４】
【発明が解決しようとする課題】
ところで、上記のような従来の技術には次のような解決すべき課題があった。回路設計等を行う場合、上記のようにバッチ処理で必要なデータの問い合わせを行えばよい場合と、可能な限りリアルタイムで必要な部品データを取り出したい場合とがある。必要な部品データが速やかに入手できることで、設計作業時間の短縮化が図られ、製品開発速度を速めることが可能になる。
ところが、こうした設計に必要なデータのデータ量はますます増加し、従来システムでは、データベースを管理するコンピュータの性能を向上させない限り、検索速度のスピードアップを図ることができなかった。
【０００５】
【課題を解決するための手段】
本発明は以上の点を解決するため次の構成を採用する。
〈構成１〉
本発明は、設定最大数及び設定最小数の範囲で使用頻度の高いデータが格納される活用データベースと、使用頻度の低いデータが格納される倉庫データベースと、要求元からデータの検索要求、新規登録要求及び削除要求のいずれかを受け付ける問い合わせ要求処理部と、いずれかの前記要求に応じて前記活用データベース及び倉庫データベースを管理するデータ管理部とを備えるデータベース管理システムにおいて、前記データ管理部は、前記検索要求に対し前記活用データベースを検索し、該当するデータが存在すると該データを前記要求元に送信し、該当するデータが不存在であると次に前記倉庫データベースを検索し、該当するデータが存在すると該データを前記要求元に送信すると共に、送信したデータを前記倉庫データベースから前記活用データベースへ移動させ、かつ該移動で前記活用データベースのデータ数が前記設定最大数を越えると該活用データベース中の最も使用頻度の低いデータを前記倉庫データベースに移動させ、前記新規登録要求に対し新規データを前記活用データベースに登録し、該登録で該活用データベースのデータ数が前記設定最大数を越えると該活用データベース中の最も使用頻度の低いデータを前記倉庫データベースに移動させ、前記削除要求に対し前記活用データベース中の該当するデータを削除すると共に、該削除で前記活用データベースのデータ数が前記設定最小数以下になると前記倉庫データベース中の最も使用頻度の高いデータを前記活用データベースに移動させる、ことを特徴とするデータベース管理システム。
【０００９】
【発明の実施の形態】
以下、本発明の実施の形態を具体例を用いて説明する。
〈具体例〉
図１は、本発明によるデータベース管理システムのブロック図である。
このシステムは、例えばＣＡＤの設計に使用する部品ライブラリデータを格納するために使用される。図に示すＣＡＤワークステーション１は、ＣＡＤシステムを用いた集積回路の設計等に利用されるワークステーションである。ここでは、例えば図に示すように、部品ライブラリの設計、回路設計、基板設計、集積回路（ＬＳＩ）の設計等が行われる。そして、これらの作業の間、部品に関するデータの検索、登録、削除といった問い合わせ要求を行う。
【００１０】
こうした問い合わせ要求に必要なデータを蓄積し、アクセスを可能にするために、図に示すような構成のシステムが用意される。
このシステムは、問い合わせ要求処理部３と、データ管理部５と、コンフィグレーションファイル６と、活用データベース７及び倉庫データベース８により構成される。データは、この図に示すように、活用データベース７と倉庫データベース８とに分けて格納される。活用データベース７には使用頻度の高いデータが、例えば約５０００件〜１００００件格納される。
【００１１】
一方、倉庫データベース８には、そのデータ以外の使用頻度の比較的低いデータが格納される。倉庫データベース８に格納されるべきデータ量は、例えば数十万件となる。なお、このデータ量には特に制限がない。
【００１２】
問い合わせ要求処理部３は、データベースに格納されたデータの検索、新たな登録、あるいはデータの削除等に関する問い合わせ要求を受け付ける部分である。このために、問い合わせ要求処理部３には、検索部３−１、登録部３−２及び削除部３−３が設けられている。データ管理部５は、問い合わせ要求処理部３に依頼を受けて、活用データベース７や倉庫データベース８に格納されたデータをアクセスするとともに、そのアクセスの結果データの状態が変化したとき、データの入れ替え処理を実行する部分である。データの入れ替え処理のための基準は、コンフィグレーションファイル６に格納されている。
【００１３】
例えば、ＣＡＤ設計においては、蓄積された十数万件以上の部品データのうち、実際に使われている部品データは数千件である。そこで、例えば過去１年間以上の間、１度もアクセスされていないようなデータは倉庫データベース８に格納し、１年以内にアクセスされたデータを活用データベース７に格納しておく。もし、活用データベース７に５０００件から１万件程度のデータを格納しておいた場合、一般的なデータベース管理システム用コンピュータによって、十分高速にこの種の部品データをアクセスすることが可能になる。即ち、設計者がストレスを感じない程度にリアルタイムに高速に問い合わせ処理に対する回答を行うことが可能になる。
【００１４】
データが数十万件あって、これらを全て検索の対象にすると、１件ずつの検索に比較的長時間の処理時間が必要となり、事実上リアルタイム処理では設計者に与えるストレスが大きく、バッチ処理に頼らざるを得ないケースが多かった。ここでは、このように活用データベース７に格納するデータ量を十分に少なくし、問い合わせ処理に対する速度を実用上問題ない程度に向上させている。こうすれば、設計作業の高速化が図られる。
【００１５】
こうした目的のために、コンフィグレーションファイル６には、例えばこの図１の下側に示すように、活用データベースのサイズＳＡを最大１万件、最小５０００件程度のデータが格納できる大きさに設定している。また、倉庫データベースのサイズＳＳは、必要に応じて記憶容量を増やせばよいから、最大値を無限大とする。更に、コンフィグレーションファイル６には、活用データベース７と倉庫データベース８とのデータ入れ替えのための基準を設ける。入れ替え期間ＳＴはこの基準であって、例えば１年以上使用されていないデータは活用データベース７から倉庫データベース８に移される。１年以上使用されていないデータが無ければ９ヶ月以上といった基準も設けられる。
【００１６】
一方、活用データベースに格納されているデータ量がその最大値以下であって、まだデータを格納する余裕がある場合には、倉庫データベース８からデータを活用データベース７に移す。そのほうがより広範囲でデータ検索ができるからである。この場合には、倉庫データベースに格納されたデータのうち、比較的使用頻度の高いものを移動させればよい。
【００１７】
更に、倉庫データベース８に格納されたデータのうち、検索要求等があったものについては、これを活用データベース７に移す。
こうした基準をコンフィグレーションファイル６に設定しておく。なお、この他にこうした入れ替え処理をリアルタイムに行うか、あるいはバッチで行うかの設定をする。
各データには、このために、登録日時や前回アクセスされた日時等を含む属性データ１１が付加されている。
【００１８】
図２に、コンフィグレーションファイルの記述内容説明図を示す。
ここでは、図１に示したコンフィグレーションファイルの内容を一般化して図示した。活用データベースのサイズＳＡは、実用上十分に高速にアクセスすることができる範囲で自由に設定してよい。これはデータベース管理装置の性能や記憶装置のアクセス速度等によって実験的に決められる。また、アクセスされるデータサイズによっても大きく変わってくる。倉庫データベースのサイズＳＳはシステムにより定まる。入れ替え期間ＳＴは、活用データベース７に格納されたデータと倉庫データベース８に格納されたデータの使用頻度の比較によって設定される。従って、データ毎の使用頻度を比較した結果、例えば入れ替え期間が数ヶ月になったり、数年になることもあり得る。
【００１９】
実行形式とは、入れ替えを必要と判断するタイミングと実際に入れ替えを実行するタイミングの取り決めを言う。リアルタイムであることが望ましいが、活用データベースに格納できるデータ数は厳密に１万件というように設定されるわけではなく、多少の変動は可能である。従って、データ入れ替えに伴うシステムの負荷を軽減したり、検索処理の妨げになることを防止するためにバッチ処理とするのもよい。
【００２０】
図３には、問い合わせ要求処理動作フローチャートを示す。
以下、本発明のシステムの動作を順に説明する。
まず、ワークステーション等からの問い合わせ要求があった場合には、ステップＳ１において、その問い合わせ要求を読み込み、ステップＳ２以降で、要求の内容に応じた処理を実行する。要求が検索要求の場合には、ステップＳ２において、検索要求フラグをセットし、そのデータ管理指示を実行する。データ管理指示は図１に示したデータ管理部５へ送られる。
【００２１】
ステップＳ３において、登録要求があった場合には、登録要求フラグをセットし、ステップＳ４において、削除要求があった場合には、削除要求フラグをセットし、それぞれ必要なデータ管理要求をデータ管理部５に渡す。コンフィグレーションファイルは、既に説明したような内容でテキストエディタ等を用いて作成される。図１に示すデータ管理部５は、データのアクセスその他の処理とともに、このコンフィグレーションファイル６の内容を読み込んで、テーブルデータとしてセットし、その設定通りに動作を行う。
【００２２】
図４には、データ管理工程の動作フローチャートを示す。
図のステップＳ１において、まずデータ管理部５がコンフィグレーションファイル６の内容を読み込む。そして、ステップＳ２において、そのデータの内容が有効と判断すると、検索登録あるいは削除処理に移る。一方、そのデータの内容が無効あるいは存在しない場合には、予め用意したデフォルト値を読み込み、処理が行われる（ステップＳ３）。なお、図１に示したコンフィグレーションデータ中、入れ替え期間ＳＴの中に９ヶ月、６ヶ月、３ヶ月と記入したのは次の理由による。
【００２３】
活用データベース７がいっぱいになった場合には、いずれかのデータを倉庫データベース８に移す必要がある。このとき、アクセスのない期間が１年以上のデータが優先的に移される。しかしながら、１年以上アクセスのないデータが存在しないような場合でもデータを移さなければならないことがある。このとき、９ヶ月、６ヶ月、３ヶ月といった段階的な基準を設けておく。これによって、より使用頻度の低いデータが倉庫データベース８に移されることになる。
【００２４】
図４において、コンフィグレーションデータの設定が終了すると、ステップＳ４の検索データ処理あるいはステップＳ５の登録データ処理、ステップＳ６の削除データ処理のいずれかが実行されて、最終的にステップＳ７に進み、要求元に対して検索結果が出力される。図５、図６、図７に、この検索データ処理、登録データ処理及び削除データ処理の具体的なフローチャートを図示した。
【００２５】
図５は、検索データ処理の動作フローチャートである。
まず、ステップＳ１０において、データ管理部５は、検索要求を受けたとき、まず活用データベース７から検索キーに合致したデータの検索を行う。使用頻度の高いデータの場合、活用データベース７に格納されている確率が高いからである。また、より高速に検索処理を行うためである。ここで、ステップＳ１１で、データがあったかどうかの判断がされる。データがあった場合には、ステップＳ１５に進み、検索データの内容を返す。これによって、リアルタイムにデータ検索が可能になる。
【００２６】
一方、データが活用データベース７に存在しない場合には、ステップＳ１１からステップＳ１２に進む。そして、倉庫データベース８から検索キーに合致したデータの検索を行う。この場合には、倉庫データベース８に大量のデータが格納されているため、従来同様、比較的時間のかかる検索が行われる。その結果、ステップＳ１３において、データがあると判断されると、ステップＳ１６に進み、その結果を問い合わせもとに返す。また、データが存在しないと判断されると、ステップＳ１４に進み、登録されたデータはないという回答を問い合わせ元に返す。
【００２７】
なお、倉庫データベースから検索キーに合致したデータを検索し、ステップＳ６でその検索データの内容を返した場合には、ステップＳ１７に進み、データの入れ替え処理が実行される。即ち、倉庫データベースで検索されたデータは、最新に検索をされたデータであるから、これを活用データベース７に移す。そして、活用データベース７に格納されたデータ量が１万件を越えない場合には、これで処理を終了する。しかしながら、活用データベースのサイズである１万件を越える場合には、活用データベースから入れ替え期間で指定された期間を越えた使用頻度の低いデータを倉庫データベースに移す。こうした入れ替え処理を実行して、処理を終了する。
【００２８】
図６には、登録データ処理動作フローチャートを示す。
登録要求があった場合には、データ管理部５は、ステップＳ２１において、その登録要求データを活用データベースに登録する。登録要求があったデータは直ちに使用される確率が高いため、活用データベース７への登録を実行する。そして、ステップＳ２２において、要求元に対し登録終了メッセージを返す。
【００２９】
次に、ステップＳ２３において、活用データベース７の件数をチェックする。登録されたデータ件数が１万件を越えているかどうかを次のステップＳ２４において判断する。もし１万件を越えている場合には、既に説明した通りの要領で、活用データベース７と倉庫データベース８のデータについて入れ替え処理を実行する（ステップＳ２５）。こうして、より使用頻度の高いデータが活用データベース側に蓄積される。
【００３０】
図７には、削除データ処理フローチャートを示す。
まず、問い合わせ要求処理部３からデータ削除のための要求が受け付けられた場合、データ管理部５は活用データベース７から最初に削除キーに合致したデータの検索を行う（ステップＳ３１）。ここで、ステップＳ３２において、データがあったかどうかの判断をする。データがなければステップＳ３３に進み、倉庫データベース８から削除キーに合致したデータの検索を行う。そして、ステップＳ３４において、再びデータがあったかどうかの判断をする。データがなければステップＳ３５に進み、データ無しの回答を返す。即ち、削除対象となるデータがないという回答を要求元に返すことになる。
【００３１】
一方、データが存在すれば、ステップＳ３６において、倉庫データベース８から該当するデータの削除を行う。倉庫データベースに該当するデータがある場合は、このようにして処理が終了する。なお、データの削除処理は、活用データベース７から先に検索を行っても、倉庫データベース８から先に検索を行っても機能的に大きな差はない。
【００３２】
一方、ステップＳ３２において、活用データベースに削除すべきデータがあると判断された場合には、ステップＳ３７に進み、そのデータを削除し、削除終了通知を行う。そして、ステップＳ３８に進み、削除後の活用データベースの件数をチェックする。ここで、ステップＳ３９において、そのデータ量が５０００件以下かどうかの判断をする。５０００件以下であればステップＳ４０に進み、倉庫データベース８から活用データベース７に対しデータを移す。
【００３３】
各データには、既に説明したように、登録日時や前回アクセスされた日時等を含む属性データ１１が付加されている。これを参照することによって、倉庫データベース８に格納したデータのうち、比較的使用頻度の高いものを活用データベース７に移し、活用データベースにおけるデータ検索の効率を高める。
【００３４】
【発明の効果】
以上説明した本発明によれば、頻繁に使用されるデータをデータベースに格納し、比較的使用頻度の低いデータを倉庫データベースに格納するようにして、検索、登録、削除処理等を実行した際、コンフィグレーションファイルを参照し、データの入れ替えを行うようにしたので、実質的なデータ検索を活用データベース７に絞って、検索速度を高めることができる。これによって、リアルタイムアクセスが可能になり、例えばＣＡＤ設計等の業務を高速化高能率化できる。
【００３５】
また、新たなデータの登録作業は、データを検索し表示する処理よりも遥かに時間がかかる。こうした処理をリアルタイムで高速に行うことができれば、そのデータの登録を待って新たな設計を行おうとする場合に、設計担当者の待ち時間が減少する。これによって、トータル的な設計作業期間の短縮を図ることができる。
【００３６】
また、データベースの各データに登録日時や前回アクセスされた日時のような属性データを付加することによって、データの使用状況を正確に把握し、データの整理や管理、削除等を容易にかつ正確に行うことが可能になる。
【図面の簡単な説明】
【図１】本発明によるデータベース管理システムブロック図である。
【図２】コンフィグレーションファイルの記述内容説明図である。
【図３】問い合わせ要求処理動作フローチャートである。
【図４】データ管理工程の動作フローチャートである。
【図５】検索データ処理フローチャートである。
【図６】登録データ処理フローチャートである。
【図７】削除データ処理フローチャートである。
【符号の説明】
１  ワークステーション
３  問い合わせ要求処理部
５  データ管理部
６  コンフィグレーションファイル
７  活用データベース
８  倉庫データベース
１１  属性データ
【図１】
0003623873.tif 000002
【図２】
0003623873.tif 000003
【図３】
0003623873.tif 000004
【図４】
0003623873.tif 000005
【図５】
0003623873.tif 000006
【図６】
0003623873.tif 000007
【図７】
0003623873.tif 000008