(57)【要約】【課題】  データベースシステムにおいて、データの検索時間を短縮することができる技術を提供する。【解決手段】  データベースにおけるデータ検索時間はレコード数に比例し、レコードは縦方向に増えるので、従来、縦方向へ格納していたデータを、本発明では横方向に格納してレコード数を削減し、データ検索の高速化を図る。さらに、１フィールド（検査データフィールド３４）内に複数のデータを格納してレコード数を削減し、データ検索の高速化を図る。【選択図】  図３
2006004236.tif 000002
【特許請求の範囲】
【請求項１】
複数のフィールドで構成されるレコードにデータが蓄積され検索されるデータベースシステムであって、
前記レコードは、第１の項目のデータが格納される第１のフィールドと、
前記第１のフィールド内のデータに対応する、第２の項目のデータが格納される複数の第２のフィールドとを有することを特徴とするデータベースシステム。
【請求項２】
複数のフィールドで構成されるレコードにデータが蓄積され検索されるデータベースシステムであって、
前記レコードは、第１の項目のデータが格納される第１のフィールドと、
前記第１のフィールド内のデータに対応する、第２の項目の複数のデータが格納される第２のフィールドとを有することを特徴とするデータベースシステム。
【請求項３】
請求項２記載のデータベースシステムにおいて、
前記第２のフィールド内の各データは、区切り記号により区切られていることを特徴とするデータベースシステム。
【請求項４】
請求項１〜３のいずれか１項に記載のデータベースシステムにおいて、
前記第１の項目は検査対象を示すものであり、前記第２の項目は検査データであることを特徴とするデータベースシステム。
【請求項５】
請求項４記載のデータベースシステムにおいて、
前記検査対象は半導体ウエハであることを特徴とするデータベースシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースシステムに関し、特に複数のフィールドによって構成されるレコードの集合体であるデータベースの構造に適用して有効な技術に関する。
【背景技術】
【０００２】
例えば、本発明者が検討した技術として、データベースシステムにおいては、以下の技術が考えられる。
【０００３】
データベースは、例えば表形式で構成され、行と列からなる。行はレコード、列はカラムまたはフィールドと呼ばれる。フィールドは、データベースにデータを入力する基本的な単位である。例えば、住所、名前、電話番号を管理するデータベースは、住所フィールド、名前フィールド、電話番号フィールドで構成される。データベースは、複数のフィールドを持つレコードの集合体として構成される。
【０００４】
データは、レコード単位で蓄積されていくため、データ量が増えると、それに比例してレコード数も増加していく。
【０００５】
データの検索方法としては、大きく分けて、全表走査（フルスキャン）と、索引を用いた索引走査（インデックススキャン）の２通りの方法がある。
【０００６】
全表走査は、全てのレコードを読み込み、検索条件と一致するレコードを見つけ出して検索を行うものである。
【０００７】
索引走査は、まず、索引ブロックにアクセスして、レコードを一意に識別する行アドレスを取得し、選択的にレコードを読み込み、検索を行う方法である。索引ブロックには、索引キー（値）と実データの場所を指し示すポインタまたはアドレスが格納されていて、索引キーはソートされた状態で格納されている。したがって、大規模データベースの場合は、索引を用いると検索速度が向上する。
【０００８】
また、特許文献１には、フィールド番号で引用する論理式を記述した制約テンプレートの和集合として検索テンプレートを作成し、この検索テンプレートを使ってデータベースに対する検索を行い、フィールドの追加・変更が制約テンプレードに反映されることにより、検索式の変更・追加が容易になるデータベースの検索方法が開示されている。
【０００９】
また、特許文献２には、各文字データを構成する複数の項目名を表現する文字列を、区切り記号によって各項目名ごとに区切った状態で、単一の項目名フィールドにリンク情報と対応付けて記憶し、各文字データを構成する複数の項目内容を表現する文字列を、単一の項目内容フィールドにリンク情報と対応付けて記憶し、各項目内容フィールドの文字列を構成する複数の項目内容の中で、その文字列にリンク情報を介し関連付けられた項目名フィールドの文字列の中で検索条件に対応する項目名の順番に対応する項目内容を、検索条件の項目内容と比較することで、文字データを検索するデータ処理装置が開示されている。
【００１０】
また、特許文献３には、ＤＢＭＳ（ＤａｔａＢａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）を利用してコンテンツデータベースにて各コンテンツを管理するためのレコードを格納するとともに、各レコードのフィールドデータに応じたディレクトリ構造をファイルシステムに構築してそのディレクトリ配下で画像データなどのコンテンツデータを管理し、コンテンツデータの読み出し時にはディレクトリ構造における所在を検索して対応する所在からコンテンツデータを読み出し、コンテンツデータベース内のレコードとディレクトリ構造のいずれか一方が破壊された場合には、他方のデータに基づいて破壊されたデータを復元するようにしたデータ管理装置が開示されている。
【特許文献１】特開平６−６８１５５号公報
【特許文献２】特開平８−２７８９７７号公報
【特許文献３】特開２０００−８２００１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、前記のようなデータベースシステムの技術について、本発明者が検討した結果、以下のようなことが明らかとなった。
【００１２】
例えば、大規模データベースになると、レコード単位でデータが書き込まれるため、蓄積されるデータ量が増えると、それに比例してレコード数も増える。そして、データの検索は、レコード単位で実行されるので、レコード数の増加によりデータの検索速度が遅くなる。
【００１３】
前記索引走査による検索の場合も、レコード数の増加により索引キーの数が増えるため、同様にデータの検索速度が遅くなる。
【００１４】
そこで、本発明の目的は、データベースシステムにおいて、データの検索時間を短縮することができる技術を提供することにある。
【００１５】
本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１６】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。
【００１７】
すなわち、データベースにおけるデータ検索時間はレコード数に比例し、レコードは縦方向に増えるので、従来、縦方向へ格納していたデータを、本発明によるデータベースシステムでは、横方向に格納してレコード数を削減し、データ検索の高速化を図るものである。
【００１８】
また、本発明によるデータベースシステムは、１フィールド内に複数のデータを格納してレコード数を削減し、データ検索の高速化を図るものである。
【発明の効果】
【００１９】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
【００２０】
データベースのデータ検索はレコード単位で行われるため、レコード数が削減されることにより、データ検索が高速化される。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２２】
図１は本発明の一実施の形態のデータベースシステムの概略構成を示す図、図２は本実施の形態のデータベースシステムにおいて、データベース１１の構成の一例を示す図、図３はデータベース１１の構成の他の一例を示す図、図４はデータ検索のフローを示すフローチャート、図５は従来のデータベースの構成の一例を示す図である。
【００２３】
まず、図１により、本実施の形態によるデータベースシステムの構成の一例を説明する。本実施の形態のデータベースシステムは、例えばコンピュータを利用したクライアントサーバシステムとされ、データベース１１とＤＢＭＳ（データベース管理システム）１２を含むデータベースサーバ１３、パーソナルコンピュータなどのクライアントマシン１４ａ〜１４ｆなどから構成される。データベースサーバ１３とクライアントマシン１４ａ〜１４ｆは、それぞれ、ＬＡＮなどのネットワークで接続されている。
【００２４】
データベースサーバ１３は、クライアントマシン１４ａ〜１４ｆからのデータベース１１に対する処理（検索、更新、追加、削除など）の依頼を受け、データベース１１を直接操作し、その処理結果をクライアントマシン１４ａ〜１４ｆへ返す機能を有する。例えば、ネットワークを介してクライアントマシン１４ａ〜１４ｆからデータベースサーバ１３に対し、検索や追加、削除、編集、更新などの要求が「ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ；構造化照会言語）」というデータベースアクセス言語による命令文として送られ、データベースサーバ１３で処理された結果が再びＳＱＬ文で送り返され、クライアントマシン１４ａ〜１４ｆの画面に表示される。
【００２５】
ＤＢＭＳ１２は、データベース１１の維持・運用を行う専用のソフトウエアであり、情報をデータに加工・編集して蓄積し、これを整列・統合して共有するツールである。
【００２６】
次に、図１に示したデータベース１１の構成の一例を説明する。
【００２７】
図５に、従来のデータベースの構成の一例を示す。図５に示すデータベースは、半導体装置の製造工程における半導体ウエハの検査（測定）データを蓄積したデータベースである。図５に示すデータベースは、１行が１レコードに相当し、各レコードは、ロット番号フィールド５１、日付フィールド５２、ウエハ番号フィールド５３、検査データフィールド５４で構成されている。例えば、一番上のレコードには、ロット番号「ＡＡＡ」、ウエハ番号「１」の検査対象ウエハについて、２００４年１月１０日に検査した結果の検査データとして「１」が格納されている。次の行のレコードには、同じ日に同一ウエハの異なる位置で検査したデータとして「２」が格納されている。図５のデータベースには、ロット番号「ＡＡＡ」、ウエハ番号「１」のウエハについて、ウエハ内を５点測定した場合の検査データと、ロット番号「ＢＢＢ」、ウエハ番号「３」のウエハについて、ウエハ内を８点測定した場合の検査データが格納されている。このようなデータベースの構成の場合、蓄積されるデータ量が増えると、縦方向にレコード数が増えることになる。
【００２８】
図５に示すように、１つの検査データは、１つのレコード内の検査データフィールド５４に格納されているため、ｎ個の検査データがあると、ｎレコードが作成される。レコード数が少ないうちは検索時間に影響がないが、データ量が増加し、縦方向にレコード数が増えると、データ検索はレコード単位で行われるため、データの検索時間が遅くなる。
【００２９】
そこで、本実施の形態においては図２に示すように、レコード数を縦方向へ増やさないように、横方向にフィールドを拡張して、データの意味が同じであるデータの塊を１つのレコードとして格納する。データの意味が同じであるデータとは、１つのレコードに２つ以上の意味を格納しないようにすることである。例えば、ウエハ内を多点測定したロット番号「ＡＡＡ」、ウエハ番号「１」の２０００４年１月１２日の検査データ（寸法、膜厚など）である。
【００３０】
すなわち、ウエハ番号という第１の項目のデータが格納される第１のフィールド（ウエハ番号フィールド２３）と、第１のフィールド内のデータに対応する検査データという第２の項目のデータが格納される複数の第２のフィールド（検査データフィールド２４ａ〜２４ｈ）を、１つのレコード内に設けて、意味の同じ第２の項目のデータ（検査データ）を検査データフィールド２４ａ〜２４ｈに格納する。データベース１１の構造をこのようにすることにより、レコード数の増加が低減される。
【００３１】
しかし、用意していたフィールド数を上回るデータ数が発生した場合、格納できないデータが発生する。この場合、データ数が増えるごとに、フィールドの追加が必要になるため、データベース１１の構造変更作業が発生する。
【００３２】
そこで、本実施の形態においては図３に示すように、複数あるが意味の同じデータ（寸法データ、膜厚データ等のように測定単位に得られるデータで各データの意味が一致しているデータ）を１つのフィールドに格納する。
【００３３】
すなわち、ウエハ番号という第１の項目のデータが格納される第１のフィールド（ウエハ番号フィールド３３）と、第１のフィールド内のデータに対応する検査データという第２の項目のデータが格納される第２のフィールド（検査データフィールド３４）を、１つのレコード内に設けて、意味の同じ複数の第２の項目のデータ（検査データ）を検査データフィールド３４に格納する。このように、データ数の異なる検査データを１フィールド内に収めることにより、データの格納漏れを防ぐことができ、データベース１１の構造が簡素化され、データベース１１の構造変更作業が不要になる。
【００３４】
また、図３に示したデータベース構造の場合、１つの検査データフィールド３４内に格納された複数の検査データの区切りは”，””｜”等の区切り記号（区切り子、デリミタ）を各データの間に入れることで、１つ１つの検査データを分離する（区切る）ことができる。１つのフィールドに格納された複数のデータを区別する方法は、上記の区切り記号で行うほかに、どこからデータが始まり、どこで終了するのかというアドレス（カラム）にて表現してもよい。アドレスは、データベース内に格納してもよい。
【００３５】
よって、従来においては図５に示したように、１つのデータを１つのフィールドに格納する場合、データがｎ個あると、ｎレコードの更新処理が必要になっていたが、本実施の形態においては図２または図３に示したように、ｎ個あるデータを１レコードにすることにより、更新するレコード数が１／ｎにできるので、追加、書き換え、削除などの更新処理が高速にできるようになる。
【００３６】
次に、図４により、本実施の形態によるデータ検索方法を説明する。図４に示すデータ検索フローは、図２、図３および図５に示したデータベースについて共通のフローである。
【００３７】
まず、前記図１のクライアントマシン１４ａ〜１４ｆからＤＢＭＳ１２に対して、検索命令のＳＱＬを発行する（ステップＳ４１）。ＤＢＭＳ１２は、発行されたＳＱＬを解析して、データベース１１にアクセスして以下のデータ検索フローを実行する。
【００３８】
ステップＳ４２で、１番目のレコードを読み込むため、Ｎ＝１とする。
【００３９】
ステップＳ４３で、Ｎ番目のレコードを読み込む。
【００４０】
ステップＳ４４で、読み込んだレコードのデータが検索条件と一致するか否かをチェックする。一致する場合は、ステップＳ４５でレコード内のデータをバッファリングしてから、ステップＳ４６でＮをインクリメントしてＮ＝Ｎ＋１とする。一致しない場合は、ステップＳ４７でＮをインクリメントしてＮ＝Ｎ＋１とする。
【００４１】
ステップＳ４６またはステップＳ４７でＮをインクリメントした後、ステップＳ４８またはステップＳ４９で、Ｎが総レコード数を超えている（Ｎ＞総レコード数）か否かをチェックする。Ｎが総レコード数以下の場合は、ステップＳ４３へ戻り、Ｎ番目のレコードを読み込む。Ｎが総レコード数を超えている場合は、ステップＳ５０へ進み、検索結果を出力してデータ検索を終了する。
【００４２】
以上のように、データ検索時のデータ読み込みはレコード単位で行われるため、データの検索時間は、レコード数に比例する。したがって、レコード数を少なくすることにより、データの検索時間を短縮することができる。レコードは縦方向に増えるので、従来、縦方向へ格納していたデータを横方向に格納する。これにより、レコード数が削減され、データ検索が高速化する。
【００４３】
また、索引キー付きの索引走査によるデータ検索の場合も、レコード数が削減するので、同様にしてデータ検索が高速化される。索引走査によるデータ検索の場合、従来、索引キーはレコード単位であったが、フィールドにも索引キーをつけた索引ブロックを設けることにより、フィールド単位、または、フィールド単位とレコード単位の組み合わせでの検索が可能となる。
【００４４】
以上、本発明者によってなされた発明をその実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００４５】
本願において開示される発明は、コンピュータを利用したデータベースシステムについて適用可能である。
【図面の簡単な説明】
【００４６】
【図１】本発明の一実施の形態のデータベースシステムの概略構成を示す図である。
【図２】本発明の一実施の形態のデータベースシステムにおいて、データベースの構成の一例を示す図である。
【図３】本発明の一実施の形態のデータベースシステムにおいて、データベースの構成の他の一例を示す図である。
【図４】本発明の一実施の形態のデータベースシステムにおいて、データ検索のフローを示すフローチャートである。
【図５】従来のデータベースの構成の一例を示す図である。
【符号の説明】
【００４７】
１１  データベース
１２  ＤＢＭＳ
１３  データベースサーバ
１４ａ〜１４ｆ  クライアントマシン
２１，３１，５１  ロット番号フィールド
２２，３２，５２  日付フィールド
２３，３３，５３  ウエハ番号フィールド（第１のフィールド）
２４ａ〜２４ｈ，３４，５４  検査データフィールド（第２のフィールド）
【図１】
2006004236.tif 000003
【図２】
2006004236.tif 000004
【図３】
2006004236.tif 000005
【図４】
2006004236.tif 000006
【図５】
2006004236.tif 000007