JP5352197B2 - 業務支援データベース装置およびその方法 - Google Patents

Description

この発明は、業務支援データベース装置に関し、特に新しいデータ構造およびその検索に関する。

発明者は、特許文献１にて、特殊なデータ構造をしたデータベースシステムを開示した。

WO2008/029741

発明者は、業務支援において、特許文献１では「指示」に着目して単一のフォーマットでこれを表すようにしたが、「指示」以外にも「許可」等も存在することが分かった。さらに、特許文献１で明らかなように、作業者、対象者などについては、別途マスタファイルを作成する必要がある。すなわち、このような人などのマスタファイルと「指示」のためのマスタファイルの双方について、データベース管理を行うプログラムが必要であった。

この発明は、上記問題を解決し、柔軟性の高いデータベース管理装置を提供することを目的とする。

１）本発明にかかる業務支援データベース装置は、業務における動作を人間が認識する場合に用いる複数の個別データを複数のレコードに分けて記憶しておき、前記複数のレコードにより１の動作が表されているグループレコードとして、データ検索する業務支援データベース装置であって、Ａ）前記各レコードは、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリー、上位レコードＩＤが記載されたアップディスクリプタを有しており、Ｂ）検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールド”カテゴリ”を検索し、該当する1または２以上のレコードを開始レコードとして特定する開始レコード特定手段、Ｃ）開始レコードが与えられると、当該レコードのアップディスクリプタを参照して、その上位レコードを特定する処理を、アップディスクリプタに上位レコードが定義されていないレコードまで繰り返し、前記上位レコードが定義されていないレコードを先頭レコードとして特定する先頭レコード特定手段、Ｄ）開始レコードが与えられると、当該開始レコードよりもレコードＩＤが大きく、前記アップディスクリプタに上位レコードが定義されていないレコードの１つ前のレコードを末尾レコードとして、特定する末尾レコード特定手段、Ｅ）前記開始レコード特定手段が特定した全開始レコードを、前記先頭レコード特定手段および前記末尾レコード特定手段に与え、各開始レコードについて、当該開始レコードの先頭レコードから末尾レコードで構成される複数のレコードを１のグループレコードであると特定するグループレコード特定手段、Ｆ）前記抽出したグループレコード全てについて、前記任意の１の検索語以外の検索語が、存在するグループレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段を備えている。したがって、複数のレコードによって、属性を定義するデータベースであっても、レコード群を特定した検索ができる。

２）本発明にかかるデータベース検索装置は、レコードと所定のフィールドがマトリックス配置されたデータベース検索装置であって、Ａ）前記各レコードは、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタを有しており、Ｂ）検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定する開始レコード特定手段、Ｃ）開始レコードから前記アップディスクリプタを順次たどり、当該開始レコードと同じグループに属する先頭レコードを特定する先頭レコード特定手段、Ｄ）前記先頭レコードＩＤが前記アップディスクリプタに記憶されているレコードを抽出し、抽出した前記先頭レコードに直接または他のレコードを介して間接に連結されているレコードを、前記アップディスクリプタを参照して、順次抽出する所属レコード抽出手段、Ｅ）前記所属レコード抽出手段が抽出したレコードについて、前記任意の１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段を備えている。

したがって、複数のレコードによって、属性を定義するデータベースであっても、レコード群を特定した検索ができる。

３）本発明にかかるデータベース検索装置は、さらに、フィールドとしてマークを有しており、前記先頭レコード特定手段は、前記開始レコードから前記先頭レコードを特定する際に、注目したレコードのアップディスクリプタから参照する上位レコードを特定するときに、前記注目したレコードの、下のレコードのフィールド「マーク」に、先頭を示す属性が存在する場合には、当該注目したレコードが先頭レコードであると判断する。

したがって、先頭レコードの特定が簡易迅速にできる。

４）本発明にかかるデータベース検索装置は、レコードと所定のフィールドがマトリックス配置されたデータベースシステムであって、前記フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタ、属するグループの先頭レコードＩＤ、および前記先頭レコードＩＤが参照するレコードＩＤのフィールド「カテゴリ」の値を有しており、前記複数のレコードに記憶されたデータにより１の動作が表されているグループレコードとして、データ検索を行うデータベースシステムにおいて、Ａ）検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定する開始レコード特定手段、Ｂ）開始レコードについて属するグループの先頭レコードＩＤを参照して、同じＩＤが定義されているレコードをグループレコードとして抽出する抽出手段、Ｃ）前記抽出手段が抽出したレコードについて、前記１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段を備えている。

したがって、複数のレコードによって、属性を定義するデータベースであっても、レコード群を特定した検索が迅速にできる。

５）本発明にかかるデータベース検索方法は、レコードと所定のフィールド項目がマトリックス配置されたデータベースのコンピュータによる検索方法であって、前記各レコードには、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタを有しており、コンピュータが下記のステップを実行すること、Ａ）検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定するステップ、Ｂ）開始レコードから前記アップディスクリプタを順次たどり、当該開始レコードと同じグループに属する先頭レコードを特定するステップ、Ｃ）前記先頭レコードＩＤが前記アップディスクリプタに記憶されているレコードを抽出し、抽出した前記先頭レコードに直接または他のレコードを介して間接に連結されているレコードを、前記アップディスクリプタを参照して、順次抽出するステップ、Ｄ）前記抽出したレコードについて、前記任意の１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とするステップ。

したがって、複数のレコードによって、属性を定義するデータベースであっても、レコード群を特定した検索ができる。

６）本発明にかかるデータベース検索プログラムは、各レコードが、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタを有しているデータベースを検索するプログラムであって、コンピュータを以下の手段として機能させるためのデータベース検索プログラム。Ａ）検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定する開始レコード特定手段、Ｂ）開始レコードから前記アップディスクリプタを順次たどり、当該開始レコードと同じグループに属する先頭レコードを特定する先頭レコード特定手段、Ｃ）前記先頭レコードＩＤが前記アップディスクリプタに記憶されているレコードを抽出し、抽出した前記先頭レコードに直接または他のレコードを介して間接に連結されているレコードを、前記アップディスクリプタを参照して、順次抽出する所属レコード抽出手段、Ｄ）前記所属レコード抽出手段が抽出したレコードについて、前記任意の１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段。

したがって、複数のレコードによって、属性を定義するデータベースであっても、レコード群を特定した検索ができる。

なお、グループとは、実施形態ではグランドプランとして取り扱われる単位をいう。

１．着眼点および前提となるデータ構造についての説明
発明者は、業務支援システムを作成するに当たって、個々の業務を「人による認識」という観点でとらえ、その集合であると把握すれば、これを特定することができるのではないかと考えた。たとえば「診察する」という行為は、医師が患者を診て、処置をする行為である。したがって、「診察する」という個別業務は、「医師」「患者」「病名診断」「処置」という用語を用いて定義することができる。また、対象者などのマスタファイルも、「登録する」という分類に属する行為であり、それを「認識」という観点でとらえれば同じデータ構造のデータベースシステムで管理が可能とであると考えるに至った。その際、どのようなデータ構造とすれば、データ管理が可能であるかについて、種々検討した結果、図１に示すようなデータ構造が好ましいと考えた。

図１を用いて、本件発明に用いたデータ形式について説明する。

各レコードのフィールドについて説明する。１レコードは、フィールド「ＩＤ」、フィールド「カテゴリ」、フィールド「アップディスクリプタ」、フィールド「マーク」、およびフィールド「サイン」で構成されている。フィールド「ＩＤ」はレコードごとに一意である。フィールド「カテゴリ」は、このレコードの上位概念が何かを示し、具体的には、参照先レコードのＩＤが記憶される。フィールド「マーク」は、後述する格を記憶する。フィールド「サイン」は、「カテゴリ」、「アップディスクリプタ」、「マーク」には入れられないデータが記憶される。たとえば、ＣＴ撮影した場合の画像データの保存アドレスなどが記憶される。

本件発明に関するデータ構造は、複数のレコードが１のグループを構成し、特定を希望するデータが表現される。

どのレコードが１のグループを構成するのかについては、フィールド「アップディスクリプタ」を順次参照したときに、共通のレコードにたどり着くか否かで判断できる。たとえば、ＩＤ「１０００１００００００００９７」が所属するグループを捜す場合、ＩＤ「１０００１００００００００９７」は、フィールド「アップディスクリプタ」が「１０００１００００００００９５」である（図１レコード２７３参照）。ＩＤ「１０００１００００００００９５」は、フィールド「アップディスクリプタ」には何も記述されていない（レコード２７１参照）。したがって、先頭レコードであることが分かる。先頭レコードが分かれば、フィールド「アップディスクリプタ」に先頭レコードのＩＤが記載されているレコードは、１のグループに属すると判断できる。レコード２７４についても、フィールド「アップディスクリプタ」が「１０００１００００００００９５」であるので、１のグループに属する。一方、次のレコードであるＩＤ「１０００１００００００００９９」であるレコード２７５は、フィールド「アップディスクリプタ」は、「１０００１００００００００９５」ではない。したがって、同じグループではないと判断できる。このようにして、１のグループを構成するレコードを特定することができる。

また、あるレコードを仲介して先頭レコードにつながっている場合もある。たとえば、図１ｂに示すように、ＩＤ「１０００５０００００００１２４」であるレコード４８２は、同様にして、レコード４７７が先頭レコードであると判断できる。レコード４７７は、ＩＤ「１０００５０００００００１１９」であり、フィールド「アップディスクリプタ」が「１０００５０００００００１１９」であるレコードは、レコード４７７〜４８３が同じグループに属すると判断できる。

レコード４８３の次のレコード４８４は、フィールド「アップディスクリプタ」が「１０００５０００００００１２５」で、先頭レコードのＩＤ「１０００５０００００００１１９」とは異なる。しかし、ＩＤ「１０００５０００００００１２５」であるレコード３２４は、フィールド「アップディスクリプタ」が「１０００５０００００００１１９」である。したがって、ＩＤ「１０００５０００００００１２５」であるレコード４８４は、ＩＤ「１０００５０００００００１１９」の孫レコードであることがわかる。

これを順次繰り替えすことにより、先頭レコードに属するレコードを抽出することができる。このようにして、先頭レコードからたどれる範囲が、１の固まりのレコードであると判断できる。このように、フィールド「アップディスクリプタ」は、各レコードがどのレコードに属するのかを特定するデータが記述されており、各レコードの所属先が直接的または別のレコード(複数段階の場合もあり）を介して間接的に記述される。

この場合、図１ｂの場合には、ＩＤ「１０００５０００００００１１９」であるレコード４７７〜ＩＤ「１０００５０００００００１４０」であるレコード４９８が、１のグループであると判断できる。

なお、次のレコードであるＩＤ「１００００００００００００００１」であるレコード４９９は、フィールド「アップディスクリプタ」には、何も記述されていない。したがって、先頭レコード４７７からたどることができない。

記述したように複数のレコードである１レコード群で定義される用語は、各レコードが定義される属性を有することとなる。たとえば、図１に示すレコード２７１〜２７４で特定されるグループは、以下のような複数の属性を有する。

図１に示すレコードＩＤ「１０００１０００００００９５」であるレコード２７１は、フィールド「カテゴリ」が「１０００１」である。ＩＤ「１０００１」のレコード１２３は、図２に示すように、フィールド「サイン」が「ＩＤ登録」である。したがって、レコード２７１は、「ＩＤ登録」という属性を示している。

なお、ＩＤ「１０００２」のレコード１２４は、図２に示すように、フィールド「サイン」が「ｓｃｒｉｐｔ登録」である。「ｓｃｒｉｐｔ登録」とは、個別業務など、所定の手順で定義されるものをいう。

レコードＩＤ「１０００１０００００００９６」であるレコード２７２は、フィールド「カテゴリ」が「５０００１」である。ＩＤ「５０００１」は、図２に示すように、フィールド「サイン」が「運営者」であるレコード１２８である。したがって、このグループは、「運営者」という属性を示している。この属性を用いてシステムにおけるデータの更新制限などが可能となる。

図１に示すレコードＩＤ「１０００１０００００００９７」であるレコード２７３は、フィールド「カテゴリ」が「２００５」で、フィールド「サイン」が「受付担当」である。ＩＤ「２００５」を参照すると、図２に示すように、フィールド「サイン」が「日本語」である。これは、このグループは、「日本語」という属性を有する「受付担当」という用語を属性として有することを示している。

図１に示すレコードＩＤ「１０００１０００００００９８」であるレコード２７４は、フィールド「カテゴリ」が「１０００１０００００００６７」である。図５のレコードＩＤ「１０００１０００００００６７」であるレコード２４３を参照すると、レコード２４３から始まるレコード群で定義される「スタッフ」を参照している。また、フィールド「マーク」が「ｒ１１」である。「ｒ１１」は、図３ｂのレコード８８を参照すると、「上格」である。「上格」とは、上のレコードに属していること、すなわち、レコード２７３であるＩＤ「１０００１０００００００９８」は、「スタッフ」に属するという属性を有する。

図３，図３ｂに示す各種の格について、簡単に説明する。「時間格」とは、時間を表す属性である。「場所格」とは場所を表す属性である。「場所格」は、さらに詳細に、「内」「外」「上」「下」「右」「左」「through」・・・「gui」がある。たとえば、「ｌ１」、フィールド「サイン」に記載されていれば、内側であることを意味する。このような詳細を属性として有することにより、個別業務をより的確に規定することができる。

「ムード格」とは、「許可格」、「勧告格」、「命令格」、「事実格」、「マニュアル格」があり、それぞれ、属性として、許可を求めるもの、勧告を求めるもの、命令（指示）を求めるもの、事実であることを示すもの、マニュアル（説明）であることを示すものである。

「関係性格」とは、レコードとレコードの関係を示しており、そのＩＤ「５９」を参照しているレコードから明らかなように、「小」、「択一格」、「併走格」、「順列格」、「結果格」、「属性格」、「必須格」、「親和格」、「連想格」、「禁忌格」、「禁忌推奨格」、「類縁格」、「上格」、「下格」がある。

「小」とは、値が小さいこと、「択一格」とは、複数レコードが並んでいる場合、いずれか1つしか選択できないこと、「併走格」とは、並列で実行可能であり、その順番は問わないことを意味する。「併走格」を表すには、それぞれのレコードに「１」が入る。また、「順列格」を表すには、順列に応じて、「１」「２」と順番が入る。

「結果格」とは、因果をあらわすもので、Ａという行為の結果、Ｂという行為が起きる（または起きた）場合に、Ｂが結果格という属性を有することとなる。「属性格」とは、事象間の関係性を示すもので、「上格」とは、上のレコードに属するということを示す。「下格」とは下のレコードがこのレコードに属しているいうことを示す。「親和格」とは、Ａという事象からみてＢという事象が近い関係の時に、ＢはＡの親和格という属性を有する。「連想格」とは、ある事象から近い関係にある事象を示しているもので、Ａという事象からみてＢという事象が近い関係の時に、Ｂは、Ａの連想格という属性を有する。「必須格」とは、つぎの事象を発生させるために必要な条件を定義するもので、「禁忌格」とは、つぎの事象を発生させる際に、あってはならない条件を定義するものである。「権限格」とは、そのＩＤ「７４」を参照しているレコードから明らかなように、「確定格」、「上書格」、「閲覧格」、「複写格」がある。「確定格」とはデータを確定（＝変更不可に）させられる権限を示し，これにより、データの入力・変更が禁止することができる。本実施形態においては、１行目のフィールド「サイン」に確定日時を入力することを示す。「上書格」はデータの上書きができる権限を示す。「閲覧格」はデータの閲覧のみが可能である権限を示す。「複写格」は、「複写格」とは、データをコピーしてデータベースに登録できる権限を示す。

以上説明したように、複数のレコードによって、複数の属性を表すことができるので、この業務システムで用いる用語を定義することができる。同様にして、この業務支援システムにおける人物を定義することもできる。図４，５を用いて、具体的に説明する。たとえば、図１の場合と同様にして、レコード５１１〜５１７が１のレコード群であることがわかる。

なお、本実施形態においては、先頭レコードのフィールド「アップディスクリプタ」は空としたので、先頭レコードのフィールド「アップディスクリプタ」は空であるレコードを先頭レコードとし、次の先頭レコードの手前までが１のレコード群であると判断してもよい。また、本実施形態においては、先頭レコードのフィールド「マーク」には、そのレコードのモードを記憶するようにしたので、ｍ１〜ｍ４のいずれかが記述される。したがって、かかるマークを参照して、値がｍ１〜ｍ４のレコードを先頭レコードとし、次の先頭レコードの手前までが１のレコード群であると判断してもよい。

ＩＤ「２０００００００００００００８」であるレコード５１１は、フィールド「カテゴリ」が「１０００１」である。ＩＤ「１０００１」を参照すると、図２に示すように、フィールド「サイン」が「ＩＤ登録」である。したがって、このグループは、「ＩＤ登録」という属性を有する。

レコードＩＤ「２０００００００００００００９」であるレコード５１２は、フィールド「カテゴリ」が「５０００１」である。ＩＤ「５０００１」を参照すると、図２に示すように、フィールド「サイン」が「運営者」である。レコードＩＤ「２００００００００００００１０」であるレコード５１３は、フィールド「カテゴリ」が「５０００２」である。ＩＤ「５０００２」を参照すると、図２に示すように、フィールド「サイン」が「利用者」である。したがって、このグループは、「運営者」および「利用者」という属性を示している。この属性を用いてシステムにおけるデータの更新制限などが可能となる。

図４に示すＩＤ「２００００００００００００１１」であるレコード５１４は、フィールド「カテゴリ」が「２００５」で、フィールド「サイン」が「成仁太郎」である。ＩＤ「２００５」であるレコード１１２は、図２に示すように、フィールド「サイン」が「日本語」である。したがって、このグループは、「日本語」という属性を有する「成仁太郎」という用語で定義される。

図４に示すＩＤ「２００００００００００００１２」であるレコード５１５は、フィールド「カテゴリ」が「２００６」で、フィールド「サイン」が「セイジンタロウ」である。ＩＤ「２００６」であるレコード１１３は、図２に示すように、フィールド「サイン」が「カナ」である。したがって、このグループは、「カナ」という属性を有する「セイジンタロウ」という用語で定義される。

図４に示すＩＤ「２００００００００００００１３」であるレコード５１６は、フィールド「カテゴリ」が「１０００００００００００００１」である。フィールド「ＩＤ」が、「１０００００００００００００１」のレコード４９９は、図４に示すように、フィールド「カテゴリ」が「１０００１」である。したがって、図１の場合と同様に、レコード４９９は「ＩＤ登録」を示している。

ここでレコード４９９は、レコード５００〜５０３とともに、１のレコード群を構成している。１のレコード群を構成しているか否かの判断手法については既に説明したので、省略する。したがって、レコード５１６は、レコード４９９〜５０３のレコード群を示す。レコード４９９〜５０３のレコード群は「医療法人社団成仁」を定義しているので、結局レコード５１６は、「医療法人社団成仁」を属性として有することが定義されている。

図４に示すＩＤ「２０００００００００００１４」であるレコード５１７は、フィールド「アップディスクリプタ」が「１０００１０００００００７１」であるので、図５に示すフィールド「ＩＤ」が、「１０００１０００００００７１」のレコード２４７は、レコード４９９と同様に、レコード２４７〜２５０の１のレコード群を構成している。レコード２４７〜２５０で定義されるレコード群は、「医師」を定義している。

結局、図４に示すレコード５１１〜５１７のレコード群は、図６に示すような階層構造の属性を有することとなる。このように、複数のレコード群によって、複数の属性を表すことができる。

２．機能ブロック図
図７に、本発明にかかる業務支援データベース装置１の機能ブロック図を示す。業務支援データベース装置１は、業務における動作を人間が認識する場合に用いる複数の個別データを複数のレコードに分けて記憶しておき、前記複数のレコードにより１の動作が表されているグループレコードとして、データ検索する装置であって、各レコードは、フィールドとして、「ＩＤ」、実体データアドレスまたは実体データアドレスへ導くデータが記載された「カテゴリ」、上位レコードＩＤが記載された「アップディスクリプタ」、および、その他の事項が記載される「サイン」を有している。

業務支援データベース装置１は、開始レコード特定手段３、先頭レコード特定手段４、末尾レコード特定手段５、グループレコード特定手段６、および検索結果特定手段７を備えている。

開始レコード特定手段３は、検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールド”カテゴリ”を検索し、該当する1または２以上のレコードを開始レコードとして特定する。先頭レコード特定手段４は開始レコードが与えられると、当該レコードのアップディスクリプタを参照して、その上位レコードを特定する処理を、アップディスクリプタに上位レコードが定義されていないレコードまで繰り返し、前記上位レコードが定義されていないレコードを先頭レコードとして特定する。末尾レコード特定手段５は、開始レコードが与えられると、当該開始レコードよりもレコードＩＤが大きく、前記アップディスクリプタに上位レコードが定義されていないレコードの１つ前のレコードを末尾レコードとして、特定する。グループレコード特定手段６は、開始レコード特定手段３が特定した全開始レコードを、先頭レコード特定手段４および末尾レコード特定手段５に与え、各開始レコードについて、当該開始レコードの先頭レコードから末尾レコードで構成される複数のレコードを１のグループレコードであると特定する。検索結果特定手段７は、前記抽出したグループレコード全てについて、前記任意の１の検索語以外の検索語が、存在するグループレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする。

３．ハードウェア構成
図７に示す業務支援システム１のハードウェア構成について、図８を用いて説明する。同図は、業務支援データベース装置１を、ＣＰＵを用いて構成したハードウェア構成の一例である。

業務支援データベース装置１は、ＣＰＵ２３、メモリ２７、ハードディスク２６、モニタ３０、光学式ドライブ２５、入力デバイス２８、通信ボード３１、およびバスライン２９を備えている。ＣＰＵ２３は、ハードディスク２６に記憶された各プログラムにしたがいバスライン２９を介して、各部を制御する。

ハードディスク２６は、オペレーティングシステムプログラム２６ｏ（以下ＯＳと略す）、データベース管理プログラム２６ｐが記憶される。

データベース管理プログラム２６ｐの処理は、検索処理を除くと従来と同様である。検索処理については後述する。データ記憶部２６k には、図１に示すようなテーブル構造にて、データが記憶される。

患者に関する情報、医師に関する情報、事務員に関する情報についても、既に説明したように、図４，図５に示すようなテーブル構造で記憶される。

データの入出力処理については、従来と同様に、業務における個別業務ごとに、後述するように、専用の入出力画面をハードディスク２６に記憶させておき、必要な画面が読み出されて、表示される。

本実施形態においては、オペレーティングシステムプログラム（ＯＳ）２６ｏとして、LINUX（登録商標または商標）を採用したが、これに限定されるものではない。

なお、上記各プログラムは、光学式ドライブ２５を介して、プログラムが記憶されたＣＤ−ＲＯＭ２５ａから読み出されてハードディスク２６にインストールされたものである。なお、ＣＤ−ＲＯＭ以外に、フレキシブルディスク（ＦＤ）、ＩＣカード等のプログラムをコンピュータ可読の記録媒体から、ハードディスクにインストールさせるようにしてもよい。さらに、通信回線を用いてダウンロードするようにしてもよい。

本実施形態においては、プログラムをＣＤ−ＲＯＭからハードディスク２６にインストールさせることにより、ＣＤ−ＲＯＭに記憶させたプログラムを間接的にコンピュータに実行させるようにしている。しかし、これに限定されることなく、ＣＤ−ＲＯＭに記憶させたプログラムを光学式ドライブ２５から直接的に実行するようにしてもよい。なお、コンピュータによって、実行可能なプログラムとしては、そのままインストールするだけで直接実行可能なものはもちろん、一旦他の形態等に変換が必要なもの（例えば、データ圧縮されているものを、解凍する等）、さらには、他のモジュール部分と組合して実行可能なものも含む。

４．検索処理に用いるデータ構造について
すでに説明したように本件データ構造では、フィールド「カテゴリ」に上位概念を、フィールド「アップディスクリプタに、レコード間の接続関係を、フィールド「マーク」に格を、フィールド「サイン」にその他の情報が記載される。また、１のレコード群を構成するレコード数は任意である。したがって、特許文献１のように「指示」のためのひな形ファイルを別途も受けることなく、業務におけるマスタも前記レコード群の定義形式によって定義することができる。

図９、図１０に示すレコード群３５９〜４１５は、診察をする場合のマスタである。診察は、「予約」、「来訪確認」、「呼び込み」、「処置」、「会計」、「処方箋発行」・・・という個別業務から構成される。このような個別業務について、共通で使うデータもある。たとえば、患者ＩＤは「予約」、「来訪確認」、「呼び込み」、「病名付与」、「処置」、「会計」、「処方箋発行」等で全て共通である。医者ＩＤも「予約」、「処置」、等で共通である。したがって、これらをまとめて、マスタを作成している。本実施形態においてはこれらをグランドプランマスタと呼ぶ。

このようなグランドプランマスタを作成しておき、「診察」についてデータ入力する際には、これを読み出して、コピーして、入力データを上書きするようにすればよい。なお、本件データ構造では、データの格納レコードが当該レコード群のうち、何番目のレコードに存在するかについて、固定されておらず、任意である。したがって、あるレコード群にデータを上書きする際に、当該レコード群のうち、どのレコードにデータを書き込むのかを決定する必要がある。たとえば、図９では、変動する部分については、そこに記録されるデータの上位概念を記述しておき、これを参照して、上書きするようにすればよい。たとえば、レコード３８３はフィールド「カテゴリ」が「１０００１０００００００７１」である。「１０００１０００００００７１」は、属性「医師」であることがわかる（図５参照）。このように、フィールド「カテゴリ」の値を参照して、どのレコードに上書きすればよいことが分かる。

なお、その際、フィールド「マーク」を参照する。たとえば、レコード３６５は、フィールド「マーク」が「ｐ１」である。これは、図１１を参照すると、「実施格」であることが分かる。「実施格」とは、その業務を行う主体を意味する。レコード１０のフィールド「サイン」は、「被作用格」である。「被作用格」とはその業務の対象者を意味する。レコード９，１０はフィールド「アップディスクリプタ」の値が「７」である。ＩＤ「７」のレコード８は、フィールド「サイン」に「人格」と記述されている。いずれも人に関する属性であることが分かる。

また、時刻については、レコード３７４のフィールド「マーク」は「ｔ」である。「ｔ」はレコード５２（図３参照）から時間格であることが分かり、その下のレコード３８５，３８６のフィールド「マーク」は「ｆｒｏｍ」と「ｔｏ」であるので、これが診察開始時刻と診察終了時刻を上書きするレコードであると判断できる。このように、各レコードに記録されている属性を判断して、データを書き込むようにすればよい。

また、本実施形態においては、前記グランドプランについて、１のムード格を付与するようにした。グランドプランは、複数のプランで構成される。プランは、ひとまとまりとなる作業をまとめた小グループであり、たとえば、図９，図１０に示す１のグランドプランは、図９のレコード３６９〜３７７，３７８〜３８９、図１０のレコード３９０〜４１４までの３つのプランを含む。また、レコード３５９、３６０、３６１，３６２，３６３，３６４、３６５〜３６６，３６７〜３６８もそれぞれ１のプランである。本実施形態においては、このように、レコード３５９、３６０、３６１，３６２，３６３，３６４、３６５〜３６６，３６７〜３６８をそれぞれ１のプランとしたが、レコード３５９〜３６８をまとめて１のプランと扱ってもよい。

このようにプランについて、順列がある場合、フィールド「マーク」に順列を表す数字を記憶させるようにしている。これにより、概念的に上下関係にある言葉と、手順的につながっている言葉を区別することができる。

図１２、図１３は、図９、図１０に示すグランドプランマスタをコピーしたレコード群にデータを入力した入力後のレコード群９７７〜１０３８である。コピーしているので、レコードＩＤは異なっている。たとえば、図１２と図９を比較すると、レコード９８３のフィールド「カテゴリ」の値が「２００００００００００００２９」、と、レコード９８５のフィールド「カテゴリ」の値が「２００００００００００００４９」と、レコード９９４のフィールド「カテゴリ」の値が「２００００００００００００２９」と、レコード１０００のフィールド「カテゴリ」の値が「２０００００００００００００８」と、レコード１００２の値が、「２００８／１０／１／１１：００」と、レコード１００３のフィールド「カテゴリ」の値が「２００８／１０／１／１１：３０」と上書きされている。

データ入力処理は、従来と同様である。たとえば、図１４Ａに示す入力画面を表示し、図１４Ｂに示すように、必要なデータが入力され、保存ボタン５１が選択されると、対応づけたレコードのフィールド「カテゴリ」の値を上書きするようすればよい。

また、本件データ構造では、１のレコード群を構成するレコード数については制限がない。したがって、上記説明したようにグランドプランマスタにまとめてもよいし、また、各個別業務について１つのグランドプランマスタとしてもよい。

本明細書においては、マスタのレコード群もこれに入力データを上書きしたレコード群もデータ構造が同じであるので、検索プログラムを共用することができる。

５．フローチャート
つぎに、本データ構造における検索処理について説明する。以下では、図１５、図１６、図１７に示すデータが、既に記憶されている場合に、医師「成仁太郎」の「２００８年１０月１日」の「診察」の予定を画面上に一覧表示する場合の処理について説明する。

一般的には、上記のような３つの検索語で検索する場合、これらの条件をand条件で満足するデータを抽出することになる。しかし、本件データ構造では、全レコードのデータ形式が同じであり、１のレコード群の範囲が明確でない。本件データベース装置においては、任意の１つの検索語を用いて、レコード群を特定し、その１つの検索語を満足しているレコード群のうち、残りの検索語についても条件を満たすレコード群から、該当するレコードの値を抽出することにより、目的のデータを抽出できるようにしている。

ＣＰＵ２３は、複数の検索語として、「成仁太郎」、「２００８年１０月１日」「診察」を記憶し(図１８ステップＳ１）、いずれか 検索語を特定する(ステップＳ３）。この実施例では、３つの検索語のうち、先頭の検索語「成仁太郎」を特定するものとする。なお、いずれを選択するのかについては任意であり、かかる手法に限定されるものではない。

ＣＰＵ２３は、選択した検索語から候補レコード群を特定する(ステップＳ５）。ステップＳ５の処理について、図１９を用いて説明する。検索語から、ＩＤ抽出し、注目レコードとする(ステップＳ１１）。この場合、検索語は「成仁太郎」であるので、「成仁太郎」がフィールド「カテゴリ」に存在するレコードを抽出する（ステップＳ２１）。これは、本実施形態においては、そのレコードの、上位概念のレコードのＩＤまたは日時を、フィールド「カテゴリ」に書き込むように規定したからである。この場合、図４に示すように、「成仁太郎」は、ＩＤ「２００００００００００００１１」に存在する(図４レコード５１４参照)。これを注目レコードとする。つぎに、ＣＰＵ２３は、先頭レコードを特定する(ステップＳ１３）。

ステップＳ１３の処理について、図２０を用いて説明する。ＣＰＵ２３は、注目レコード５１４のアップディスクリプタから上位レコードを取得する(ステップＳ３１）。この場合、注目レコード５１４(図４参照)のフィールド「アップディスクリプタ」の値「２０００００００００００００８」が取得される。つぎに、ＣＰＵ２３は、取得された値がフィールド「ＩＤ」に記憶されているレコードを特定し、そのレコードのフィールド「アップディスクリプタ」が空か否か判断する(ステップＳ３３）。この場合、取得された値がフィールド「ＩＤ」に記憶されているレコード５１１のフィールド「アップディスクリプタ」を参照すると、値が空である。ＣＰＵ２３は、ステップＳ２１にて取得したレコード５１１が、注目レコードの所属するレコード群の先頭レコードであると決定する（ステップＳ３７）。これにより、「成仁太郎」は、ＩＤ「２０００００００００００００９」で表されることがわかる。

また、ステップＳ３３にて、フィールド「アップディスクリプタ」が空でない場合には、取得した上位レコードを注目レコードとし(ステップＳ３５）、ステップＳ３３の処理が繰り返される。

このようにして、先頭レコードが特定される。なお、図９ステップＳ１１，ステップＳ１３の処理が必要なのは、本件データ構造においては、各用語についても複数のレコードにて定義されているので、検索語が存在するレコードが所属するレコード群の先頭レコードのＩＤを特定する必要があるからである。

ＣＰＵ２３は、先頭レコードのＩＤがフィールド「カテゴリ」に存在するレコードを抽出する(図１９ステップＳ１５）。この場合、先頭レコードは、レコード５１１であるので、フィールド「カテゴリ」が、「２０００００００００００００８」であるレコードが抽出される。この場合、図１５，図１６、図１７から、レコード６５０、７０５、９２５の３つが抽出される。

ＣＰＵ２３は、処理番号iを初期化し(ステップＳ１６）、i番目のレコードについて、レコード群giを特定する(ステップＳ１７）。ステップＳ１７の処理について、図２１を用いて説明する。

ＣＰＵ２３は、i番目のレコードを注目レコードとし（ステップＳ２１）、この注目レコードから、先頭レコードを特定する(ステップＳ２３）。先頭レコードの特定については既に説明した(図２０)ので、詳細は省略する。これにより、１番目のレコード６５０の先頭レコードとして、レコード６２７が特定される(図１６参照）。つぎに、ＣＰＵ２３は、特定した先頭レコードに対応する末尾レコードを特定する(図２１ステップＳ２５）。

末尾レコードの特定処理について、図２２を用いて説明する。ＣＰＵ２３は、先頭レコードを抽出対象レコードとする(ステップＳ４１）。この場合、レコード６２７が抽出対象レコードとなる。ＣＰＵ２３は、抽出対象レコードのフィールド「ＩＤ」の値が、フィールド「アップディスクリプタ」に記録されているレコードを抽出する(図２２ステップＳ４３）。この場合、「３０００００００００００００１」が記憶されているレコード６２８〜６３２，６３４、６３６、６４５が抽出される(図１５参照)。ＣＰＵ２３は、ステップＳ４３にて抽出したレコードを抽出対象レコードに追加する（ステップＳ４５）。これにより、抽出対象レコードは、レコード６２８〜６３２，６３４、６３６、６４５となる。ＣＰＵ２３は、抽出対象レコードの、次のレコードのフィールド「アップディスクリプタ」が空か否か判断する（ステップＳ４７）。この場合、いずれも空ではないので、ステップＳ４３に戻り、抽出対象レコード６２８〜６３２，６３４、６３６、６４５のフィールド「ＩＤ」の値が、フィールド「アップディスクリプタ」に記録されているレコードを抽出する(ステップＳ４３）。この場合、「３０００００００００００００１」〜「３０００００００００００００６」、「３０００００００００００００８」、「３００００００００００００１０」、「３００００００００００００１９」が記録されている６３３、６３５、６３７〜６４１，６４３、６４６〜６４９、６５１、６５４〜６５６が抽出される(図１５参照)。ＣＰＵ２３は、ステップＳ４３にて抽出したレコードを抽出対象レコードに追加する。これにより、抽出対象レコードは、レコード６２７〜６４１、６４３、６４５〜６４９、６５１，６５４〜６５６となる。以下同様にして、抽出対象レコードが追加され、抽出対象レコードの次のレコードについて、そのフィールド「アップディスクリプタ」が空となるまで繰り返す。このように、階層構造を順次、抽出することにより、末尾レコードを取得することができる。仮に、図１６に示すレコード６５６が、ステップＳ４７の条件を満たしたとすると、レコード６５６が、末尾レコードとして決定される（図２２ステップＳ４９）。

ＣＰＵ２３は、末尾レコードを取得すると、レコード群g1としてレコード６２７〜６５６を記憶する(図２１ステップＳ２７)。ＣＰＵ２３は１番目のレコード群が特定されると、ステップＳ１５で抽出したレコード全てについて、ステップＳ１７の処理を実行したか否か判断する(ステップＳ１８）。この場合、残っているレコードがあるので、ステップＳ１９に進み、処理番号iをインクリメントする。そして、２番目のレコードについてステップＳ１７の処理を実行する。

このようにして、レコード群g1（レコード６２７〜レコード６５６（図１５参照））,g2（レコード６８２〜７１１（図１６参照））,g3（レコード９１６〜９４７（図１７参照））が抽出される。

選択した検索語から候補レコード群が特定する処理(図１８ステップＳ５）が終了すると、ＣＰＵ２３は、残りの検索語にて、ステップＳ５にて抽出したレコード群を検索して、データ抽出を行う(ステップＳ７)。この場合、残りの検索語は、「２００８年１０月１日」および「診察」である。したがって、これらがフィールド「カテゴリ」に記憶されているレコードを有するレコード群を抽出する。

検索語「診察」については、検索語「成仁太郎」と同様にして、これを定義しているレコード群の先頭レコードを抽出する。本実施形態においては、日付はフィールド「カテゴリ」に直接、記録するようにしたので、そのまま、検索することができる。これにより、レコード群g1（レコード６２７〜６５６））,g2（レコード６８２〜７１１）が抽出される。この場合、スケジュールを検索する場合であるので、抽出したレコード群から必要なレコードのフィールド「カテゴリ」から、データを読み出するようにすればよい。この場合、たとえば、図２３に示すような表示が可能となる。

なお、いずれのレコードを抽出すればよいかについては、フィールド「マーク」を参考にすることにより、より明確となる。フィールド「マーク」については、「p」は人間であり、「ｔ」は日時であり、「from」「to」は、人間の場合には誰から誰にとなり、日時の場合には、いつからいつまでを表している。

末尾レコードの特定について、この実施形態では、先頭レコードのＩＤがフィールド「アップディスクリプタ」に記憶されているレコードを順次抽出することにしたが、先頭レコードまたは注目レコードから大きな番号のレコードのフィールド「アップディスクリプタ」を順次チェックし、空であるレコードを検出すると、その手前までが１のレコード群であると判断してもよい。

また、本実施形態においては、先頭レコードのフィールド「マーク」には、そのレコードのモードを記憶するようにしたので、ｍ１〜ｍ４のいずれかが記述される。したがって、かかるマークを参照して、値がｍ１〜ｍ４のレコードを先頭レコードとし、次の先頭レコードの手前までが１のレコード群であると判断してもよい。

本実施形態においては、フィールド「アップディスクリプタ」の値によって、同じレコード群を構成するレコードであるかを判断するようにしている。したがって、属性を追加する場合でも、フィールドを増やす必要がない。これにより、たとえば、ある個別業務について、対象者が複数存在する場合でも、レコードを追加するだけでデータ保持が可能となる。また、ＡさんがＢ医師の予約をしたが、Ｂ医師がＣ医師に代理で頼む場合も、Ｂ医師を中間指示者として記憶することもできる。

一般的には、検索をメインに考えると、レコード構造とするのが好ましい。一方、項目も項目に記載するデータ長も不明な場合、非固定長でデータ羅列することが多い。しかし、前者では新たな属性を記憶するには、フィールドを１つ増やす必要がある。これに対して、後者では、検索の都度、全データを調べる必要がある。本発明のデータ構成は、両者のよいところを引き継ぎ、項目の追加等は1つレコードを増やすだけである。また、検索の場合には、各フィールドの値で検索ができるので、全データを、検索する必要がない。したがって、データ変更が容易で且つ、データ検索が容易なデータ構造を提供することができる。

また、上記特許文献１でも、人や道具などについては別途、データ構成の異なるマスターファイルが必要であった。これに対して、本件発明では、人や各種の属性についても、このデータ構成で定義することができる。

６．他の実施形態
なお、本実施形態においては、検索時に各レコードのフィールド「アップディスクリプタ」を参照して、そのレコードがつながっているレコードを特定して、レコード群を特定している。また、検索時に各レコードのフィールド「カテゴリ」を参照して、上位のレコードを特定することにより、そのレコードが属する概念を特定している。

しかし、検索時に動的に行うのではなく、図２４に示すように、予め、各レコードが所属するレコード群(グランドプランｉｄ)を予め演算し、特定するようにしてもよい。さらに、そのレコード群の先頭レコードのフィールド「カテゴリ」の値を記憶するようにしてもよい。

レコード５５２が注目レコードである場合、フィールド「アッププランＩＤ」が同じレコードが同一レコード群であることが分かる。また、そのレコード群の先頭レコードのフィールド「カテゴリ」の値は、そのレコード群のいずれかのレコードのフィールド「アッププラン」を参照すると、取得することができる。これにより、検索処理時間を向上させることができる。

なお、図２４では、フィールド「マーク」「サイン」については省略している。

図２４では、さらに、プランＩＤを予め演算して特定している。プランＩＤとは、既に説明したように、グランドプランを構成する小グループである。

また、本実施形態においては「場所格」として、その詳細を設定可能である。このように、各格について、詳細が必要な場合にはこれを定義しておくことにより、レコードに記載されたデータの属性を、コンピュータがより確実に判断することができる。

なお、本実施形態においては、フィールド「サイン」にテキストデータを記憶するようにした。しかし、これにフィールド「サイン」に記憶されるのは、これに限定されるわけではなく、音声やイラスト等を記憶することもできる。 たとえば、本実施形態においては、図４に示すように、「成仁太郎」を定義するレコード５１４に、フィールド「カテゴリ」が「２００５」で、フィールド「マーク」が「i1」で、フィールド「サイン」が「成仁太郎」である。なお、「i1」は、レコード９６(図３ｂ)を参照にすると、テキスト格であることが分かる。たとえば、その次のレコードに、フィールド「カテゴリ」が「２００５」で、フィールド「マーク」が「ｉ４」で、フィールド「サイン」が「音声ファイルを記憶したアドレス」を記憶させることにより、これを読みだせば、聴覚障害者にも対応可能である。「ｉ４」は、レコード９９を参照にすると、音声格であることが分かる。

同様に、写真や、動画なども同様に属性として参照することもできる。その場合の格のレコードについては、図３ｂレコード９５〜１００に記載している。

上記実施形態では、1台の装置として適用した場合について説明したが、複数のコンピュータをネットワーク接続して、これを実現してもよい。たとえば、検索指示は端末から与えられ、これを受けてサーバで検索処理を行い、検索結果を当該端末に与えるようにすればよい。

上記実施形態においては、図１に示す機能を実現するために、ＣＰＵを用い、ソフトウェアによってこれを実現している。しかし、その一部若しくはすべてを、ロジック回路等のハードウェアによって実現してもよい。

なお、上記プログラムの一部の処理をオペレーティングシステム（ＯＳ）にさせるようにしてもよい。

本件データベース装置におけるデータ構造を示す図である。 本件データベース装置におけるデータ構造を示す図である。 本件データベース装置におけるデータ構造を示す図である。 本件データベース装置におけるデータ構造を示す図である。 本件データベース装置におけるデータ構造を示す図である。 本件データベース装置におけるデータ構造を示す図である。 本件データベース装置におけるデータ構造を示す図である。 図４に示すレコード群５１１〜５１７におけるデータの階層関係を示す図である。 本発明にかかる業務支援装置１の機能ブロック図である。 業務支援装置１を、ＣＰＵを用いて実現したハードウェア構成の一例を示す図である。 本発明にかかるデータベースのデータ構造（入力前）を示す図である。 本発明にかかるデータベースのデータ構造（入力前）を示す図である。 本件データベース装置におけるデータ構造を示す図である。 本発明にかかるデータベースのデータ構造（入力後）を示す図である。 本発明にかかるデータベースのデータ構造（入力後）を示す図である。 データ入力画面例である。 グランドプランマスタをコピーして作成されたデータ群にデータを入力した後のデータ例を示す図である。 グランドプランマスタをコピーして作成されたデータ群にデータを入力した後のデータ例を示す図である。 グランドプランマスタをコピーして作成されたデータ群にデータを入力した後のデータ例を示す図である。 検索処理フローチャートである。 図１８ステップＳ５の詳細フローチャートである。 先頭レコード抽出処理フローチャートである。 図１９ステップＳ１７の詳細フローチャートである。 末尾レコード抽出処理フローチャートである。 抽出結果から生成した画面例である。 検索速度を向上させるデータ構造を示す図である。

符号の説明

１・・・・ 業務支援データベース装置
２３・・・ＣＰＵ
２７・・・メモリ

Claims (6)

1. 業務における動作を人間が認識する場合に用いる複数の個別データを複数のレコードに分けて記憶しておき、前記複数のレコードにより１の動作が表されているグループレコードとして、データ検索する業務支援データベース装置であって、
   Ａ）前記各レコードは、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリー、上位レコードＩＤが記載されたアップディスクリプタを有しており、
   Ｂ）検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールド”カテゴリ”を検索し、該当する1または２以上のレコードを開始レコードとして特定する開始レコード特定手段、
   Ｃ）開始レコードが与えられると、当該レコードのアップディスクリプタを参照して、その上位レコードを特定する処理を、アップディスクリプタに上位レコードが定義されていないレコードまで繰り返し、前記上位レコードが定義されていないレコードを先頭レコードとして特定する先頭レコード特定手段、
   Ｄ）開始レコードが与えられると、当該開始レコードよりもレコードＩＤが大きく、前記アップディスクリプタに上位レコードが定義されていないレコードの１つ前のレコードを末尾レコードとして、特定する末尾レコード特定手段、
   Ｅ）前記開始レコード特定手段が特定した全開始レコードを、前記先頭レコード特定手段および前記末尾レコード特定手段に与え、各開始レコードについて、当該開始レコードの先頭レコードから末尾レコードで構成される複数のレコードを１のグループレコードであると特定するグループレコード特定手段、
   Ｆ）前記抽出したグループレコード全てについて、前記任意の１の検索語以外の検索語が、存在するグループレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段、
   を備えたことを特徴とする業務支援データベース装置。
2. レコードと所定のフィールドがマトリックス配置されたデータベース検索装置であって、
   前記各レコードは、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタを有しており、
   検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定する開始レコード特定手段、
   開始レコードから前記アップディスクリプタを順次たどり、当該開始レコードと同じグループに属する先頭レコードを特定する先頭レコード特定手段、
   前記先頭レコードＩＤが前記アップディスクリプタに記憶されているレコードを抽出し、抽出した前記先頭レコードに直接または他のレコードを介して間接に連結されているレコードを、前記アップディスクリプタを参照して、順次抽出する所属レコード抽出手段、
   前記所属レコード抽出手段が抽出したレコードについて、前記任意の１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段、
   を備えたことを特徴とするデータベース検索装置。
3. 請求項２のデータベース検索装置において、
   さらに、フィールドとしてマークを有しており、
   前記先頭レコード特定手段は、前記開始レコードから前記先頭レコードを特定する際に、注目したレコードのアップディスクリプタから参照する上位レコードを特定するときに、前記注目したレコードの下のレコードのフィールド「マーク」に、先頭を示す属性が存在する場合には、当該注目したレコードが先頭レコードであると判断すること、
   を特徴とするデータベース検索装置。
4. レコードと所定のフィールドがマトリックス配置されたデータベースシステムであって、前記フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタ、属するグループの先頭レコードＩＤ、および前記先頭レコードＩＤが参照するレコードＩＤのフィールド「カテゴリ」の値を有しており、前記複数のレコードに記憶されたデータにより１の動作が表されているグループレコードとして、データ検索を行うデータベースシステムにおいて、
   検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定する開始レコード特定手段、
   開始レコードについて属するグループの先頭レコードＩＤを参照して、同じＩＤが定義されているレコードをグループレコードとして抽出する抽出手段、
   前記抽出手段が抽出したレコードについて、前記１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段、
   を備えたことを特徴とするデータベースシステム。
5. レコードと所定のフィールド項目がマトリックス配置されたデータベースのコンピュータによる検索方法であって、
   前記各レコードには、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタを有しており、
   コンピュータが下記のステップを実行すること、
   検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定するステップ、
   開始レコードから前記アップディスクリプタを順次たどり、当該開始レコードと同じグループに属する先頭レコードを特定するステップ、
   前記先頭レコードＩＤが前記アップディスクリプタに記憶されているレコードを抽出し、抽出した前記先頭レコードに直接または他のレコードを介して間接に連結されているレコードを、前記アップディスクリプタを参照して、順次抽出するステップ、
   前記抽出したレコードについて、前記任意の１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とするステップ、
   を特徴とするデータベース検索方法。
6. 各レコードが、フィールドとして、レコードＩＤ、実体データアドレスまたは実体データアドレスへ導くデータが記載されたカテゴリ、上位レコードＩＤが記載されたアップディスクリプタを有しているデータベースを検索するプログラムであって、コンピュータを以下の手段として機能させるためのデータベース検索プログラム。
   検索条件として複数の検索語が与えられると、当該検索条件のうち任意の１の検索語でフィールドであるカテゴリを検索し、該当するレコードを開始レコードとして特定する開始レコード特定手段、
   開始レコードから前記アップディスクリプタを順次たどり、当該開始レコードと同じグループに属する先頭レコードを特定する先頭レコード特定手段、
   前記先頭レコードＩＤが前記アップディスクリプタに記憶されているレコードを抽出し、抽出した前記先頭レコードに直接または他のレコードを介して間接に連結されているレコードを、前記アップディスクリプタを参照して、順次抽出する所属レコード抽出手段、
   前記所属レコード抽出手段が抽出したレコードについて、前記任意の１の検索語以外の検索語が、存在するレコードを１または２以上特定し、特定したレコードのカテゴリに記憶されたデータまたは、当該データで特定されるアドレスの実体データを前記検索語の検索結果とする検索結果特定手段。

Images