JP3707132B2 - Database management system - Google Patents
Database management system Download PDFInfo
- Publication number
- JP3707132B2 JP3707132B2 JP17192696A JP17192696A JP3707132B2 JP 3707132 B2 JP3707132 B2 JP 3707132B2 JP 17192696 A JP17192696 A JP 17192696A JP 17192696 A JP17192696 A JP 17192696A JP 3707132 B2 JP3707132 B2 JP 3707132B2
- Authority
- JP
- Japan
- Prior art keywords
- component
- query
- components
- relationship
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【0001】
【発明の属する技術分野】
本発明は構造化文書を管理対象とするデータベース管理システムに関し、特に文書が取り得る構造を規定した構文規則の情報を用いて文書の論理構造に基づいた問い合わせを作成することができるデータベース管理システムに関する。
【0002】
【従来の技術】
一般に、文書には、章、節、項などに代表される論理的な構成要素から構成されているものがあるが、そのような論理的な構成要素を所定の規則に従って木構造に階層化した文書を、特に構造化文書と呼んでいる。構造化文書に関する国際規格としては、例えばSGML(Standard Generalized Markup Language;ISO 8879 ) などが知られている。ここで、構造化文書の一例を示す。
【0003】
図20は構造化文書を木構造で表現した一例を示す図である。
図示のように、構造化文書は文書の論理的な構成要素に対応して木構造で表現される。構造化文書40において、矩形で表わした部分が文書の構成要素を表わし、矩形の中に示した文字列は構成要素名を表わしている。また、木構造の末端の各構成要素は、図示した文字列のようなテキストを各々持っている。
【0004】
構造化文書は、その文書中に出現可能な構成要素の種類、各構成要素の出現順序、構成要素間の包含関係等を規定する規則に従って作成される。構造化文書を規定するこの規則は、文書タイプと呼ばれる。前述のSGMLでは、DTD(Document Type Definition)が文書タイプに対応する概念である。ここで、図20に示す構造化文書40を規定した文書タイプについて説明する。
【0005】
図21は文書タイプの一例を示す図である。
図示の文書タイプ41では、矩形がこの文書タイプの持つ構成要素を表わしており、楕円が下位の構成要素の出現形態を規定する生成規則を表わしている。この生成規則の意味を説明すると、まず、生成規則「SEQ」は、この生成規則の下位の構成要素が、左から右へ順に出現することを表わす。生成規則「REP」は、この生成規則の下位の構成要素が、1回以上繰り返し出現することを表わす。生成規則「CHO」は、この生成規則の下位の構成要素のいずれか一つが出現することを表わす。
【0006】
文書タイプ41で最上位の構成要素は「報告書」である。最上位の構成要素は文書全体を表わしており、この文書タイプ41は「報告書」という名称の文書タイプであることが判る。また、この文書タイプ41からは以下のことが判る。すなわち、構成要素「報告書」は、その下位構造に「前付け」、「本体」、「後付け」という三つの構成要素を持つ。構成要素「報告書」の下位のこれら三つの構成要素に対する生成規則「SEQ」によって、三つの構成要素は文書中にこの順番で出現しなければならないことが規定されている。
【0007】
構成要素「前付け」の下位には、四つの構成要素「表題」、「著者」、「日付」、「概要」が、この順番で出現しなければならない。また、構成要素「概要」の下位には構成要素「段落」が1回以上繰り返し出現しなければならない。構成要素「本体」の下位には、構成要素「章」が1回以上繰り返し出現しなければならない。また、構成要素「章」の下位には構成要素「見出し」、「章内容」が、この順番で出現しなければならない。構成要素「章内容」の下位には、構成要素「段落」もしくは構成要素「節」のどちらかが、1回以上繰り返し出現しなければならない。更に、構成要素「節」の下位には構成要素「見出し」、「節内容」が、この順番で出現しなければならない。構成要素「節内容」の下位には構成要素「段落」が、1回以上繰り返し出現しなければならない。そして、構成要素「後付け」の下位には、構成要素「文献」が1回以上繰り返し出現しなければならない。
【0008】
このように所定の規則を持つ文書タイプに基づいて生成された文書はデータベースを用いて管理することができる。そして大量の文書を管理するデータベースでは文書またはその構成要素を検索する場合、必要な文書またはその構成要素の文脈に関する条件を利用して問い合わせを作成すれば効率の良い検索を行うことができる。
【0009】
ここで言う文書の文脈に関する条件とは、文書の構成要素を指定する条件と構成要素間の階層関係を指定する条件との組み合わせで表現されるものを意味する。例えば、「章の見出しに”データベース”という文字列を含み、章の中の任意の段落に”構造”という文字列を含むような章を検索して取り出すこと」は、文脈に関する条件である。ここで、「章」、「見出し」、「段落」は、構造化文書中に出現する構成要素を表わしている。また、『”データベース”という文字列を含む「見出し」』、『”構造”という文字列を含む「段落」』が、それぞれ構成要素に関する条件を表わしている。そして、「見出し」が「章」の見出しであること、「段落」が「章」の中に含まれること、などが構成要素間の階層関係を規定していると言える。
【0010】
図22は文書の文脈に関する条件を持った問い合わせを図式的に表わした一例を示す図である。
図示の問い合わせ42は、上記の条件「章の見出しに”データベース”という文字列を含み、章の中の任意の段落に”構造”という文字列を含むような章を検索して取り出すこと」を指定した問い合わせを表わしている。矩形で示した要素が条件に含まれる構成要素であり、構成要素の下に二重線で接続した文字列がその構成要素に含まれるべき文字列に関する条件である。条件に含まれる構成要素のうち最上位にある構成要素が検索の対象として取り出されることを示している。また、構成要素間の階層関係を規定するために、親子関係にある構成要素同士は実線で、祖先と子孫との関係にある構成要素同士は点線で接続してある。構造化文書に対しては、このように文脈に関する条件を指定することによってきめ細かい検索が可能である。
【0011】
構造化文書を管理対象とする従来のデータベースにおいて、文書の文脈に関する条件を指定して検索を行う方法として、特開平6−301721号公報に示された方法がある。この方法では文書を構成要素単位に分解し、リレーショナルデータベースに格納する。そして、文書構造を指定できる検索言語をリレーショナルデータベースの標準処理言語であるSQL(Structured Query Language )に変換して検索を行う。
【0012】
しかし、この方法では文書タイプの情報、すなわち、その文書タイプの構造に出現し得る構成要素と全構成要素の出現順序および包含関係についての情報とをユーザがあらかじめ知っていないと、問い合わせは作成できない。つまり、文書タイプの情報を知らなければ、文脈を指定した問い合わせを作成しても、その問い合わせが文書タイプの構造に適合しているかどうか判らず、その結果、条件を満たす文書がまったく存在しないこともあり得る。
【0013】
この問題を解決する方法として、検索を行う際に文書タイプの構造をユーザに提示して問い合わせを作成させる方法がある。例えば、文書データベース管理システムの一つである「MULTOS("Multimedia Office Filling-The MULTOS Approach-",Edited by C.Thanos,North-Holland,1990,ISBN:0-444-88456-4 )」では、ODA(Open Document Architecture; ISO 8613 )文書を管理対象としており、問い合わせエディタと呼ばれるグラフィカルな指示装置によって、文書の論理構造に関する条件をノード(構成要素を表わす)とアーク(構成要素間の関係を表わす)とで表現するようにしている。「MULTOS」の問い合わせエディタでは文書タイプの構造、もしくはデータベース中の特定の文書の構造を木構造で画面上に表示させ、文書タイプまたは文書の構成要素を選択し、該当する構成要素に対する条件を記述することができる。その問い合わせエディタの例を以下に示す。
【0014】
図23は従来の問い合わせエディタの表示画面の一例を示す図である。
問い合わせエディタの表示画面50は、文書タイプ名入力部51と、文書タイプ表示ウィンドウ52とから構成されている。
【0015】
ユーザが文書タイプ名入力部51に文書タイプ名を入力すると、該当する文書タイプ名を持つ文書タイプが、文書タイプ表示ウィンドウ52に木構造の形で表示される。図示の例では、ユーザが文書タイプ名「報告書」を入力した様子を表わしており、文書タイプ表示ウィンドウ52にはその「報告書」の文書タイプが表示されている。また、この問い合わせエディタでは表示された文書タイプの構成要素の中から条件を指定したい構成要素を選択して、構成要素条件指定部53を開くことができる。構成要素条件指定部53には、その構成要素に対する条件として、その構成要素の持つテキストに含まれる文字列を入力することができる。図示の例では、構成要素「表題」に関する条件を指定する構成要素条件指定部53が開いている。なお、条件の指定は任意の複数の構成要素に対して行うことが可能である。
【0016】
このような問い合わせエディタを使用することで、ユーザは画面上に表示された文書タイプの構造を参照して問い合わせを作成できるので、文書タイプについてあらかじめ知っている必要はない。
【0017】
【発明が解決しようとする課題】
しかし、実用的な規模の構造化文書を考えると、文書タイプの持つ構成要素の数は多く、複雑な構造を持っている場合が非常に多い。しかも文書タイプを木構造で表現した場合には、一つの構成要素が複数のノードとして出現することがあるため、木のノードの数は構成要素の数よりも更に多くなる。
【0018】
例えば、国際標準(Information and documentation − Electronic manuscript preparation and markup;ISO 12083:1994 )の中でSGML文書の文書タイプ定義(DTD)の一つとして定められている「Books DTD」では、文書タイプの構成要素の数は70を超えている。また、この文書タイプを木構造で表現すると木のノード数は膨大な数になり、たとえ、同一の構成要素が複数出現する場合に、そのうちの一つだけをサブツリーまで展開して他は展開しないようにしても、木のノード数は1000を超えてしまう。
【0019】
このように、実用的な規模の文書タイプの構造に基づいた構造化文書を対象とした検索の問い合わせを作成する場合、文書タイプの構造を表示して問い合わせを作成する方法では、表示される構成要素の数が非常に多いため、条件を指定したい構成要素を探す作業に非常に手間がかかるという問題点があった。
【0020】
また、一つの文書タイプ中に同一の構成要素が複数出現し得るため、ある構成要素に、出現位置に関係なく同一の条件を指定したい場合には、表示された木構造の中から、該当する構成要素すべてを探し出して条件指定を行わなければならず、これがユーザにとって大きな負担となっていた。
【0021】
本発明はこのような点に鑑みてなされたものであり、ユーザが文書タイプの構造を意識することなく、また、複数位置に出現する同一の構成要素に対しては、一度の条件指示で、文書検索のための問い合わせを作成することができるデータベース管理システムを提供することを目的とする。
【0022】
【課題を解決するための手段】
第1の発明では上記課題を解決するために、木構造に階層化されてなる論理構造を持った構造化文書を管理対象とするデータベース管理システムにおいて、文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持手段と、前記文書タイプ保持手段から文書タイプのすべての構成要素を取り出す構成要素取出手段と、前記構成要素取出手段にて取り出された構成要素の第1の集合を表示し、表示した前記第1の集合の中からユーザが選択した任意の一つの構成要素をユーザの入力操作によって受け付ける第1の構成要素選択手段と、前記第1の構成要素選択手段が受け付けた第1の構成要素とユーザが次に選択しようとする構成要素との間のユーザが指定した関係をユーザの入力操作によって受け付ける関係指定手段と、前記第1の構成要素選択手段が受け付けた第1の構成要素から見て前記関係指定手段が受け付けた関係を有するすべての構成要素を前記文書タイプ保持手段に保持された文書タイプから検索する構成要素検索手段と、前記構成要素検索手段により検索された構成要素の第2の集合を表示し、表示した前記第2の集合の中からユーザが選択した任意の一つの第2の構成要素をユーザの入力操作によって受け付ける第2の構成要素選択手段と、前記第1の構成要素選択手段が受け付けた第1の構成要素、前記関係指定手段が受け付けた関係、および前記第2の構成要素選択手段が受け付けた第2の構成要素から問い合わせを生成する問い合わせ生成手段と、前記問い合わせ生成手段にて生成された問い合わせに含まれる構成要素を表示し、表示した構成要素をユーザが選択した場合に選択された構成要素のユーザによる編集を受け付ける問い合わせ編集手段と、前記構成要素取出手段にて取り出された構成要素の第1の集合、ユーザにより指定されるべき構成要素間の関係、前記構成要素検索手段により検索された構成要素の第2の集合、および前記問い合わせ生成手段にて生成された問い合わせを表示する表示手段と、を備えていることを特徴とするデータベース管理システムが提供される。
【0023】
このようなデータベース管理システムによると、文書検索のための問い合わせを作成する際には、まず、構成要素取出手段によって文書タイプ保持手段から文書タイプのすべての構成要素を取り出して、これらを表示手段に表示する。取り出された構成要素の集合から、ユーザによって選択された任意の一つの構成要素を第1の構成要素選択手段が受け付け、更に、今、選択された構成要素と次に選択されるべき構成要素との間の関係がユーザによって指定され、それを関係指定手段が受け付ける。次に、構成要素検索手段により、選択された構成要素から見て指定された関係を有するすべての構成要素を文書タイプ保持手段から検索し、その検索結果を表示手段に表示する。検索された構成要素の集合からユーザが選択した任意の一つの構成要素を第2の構成要素選択手段が受け付けると、問い合わせ生成手段が、選択された二つの構成要素と指定された関係とから問い合わせを生成する。生成された問い合わせに含まれる構成要素を表示してその構成要素がユーザによって選択された場合に問い合わせ編集手段が選択された構成要素のユーザによる編集を受け付ける。よって、文書タイプの構造を意識しなくても、問い合わせを作成することができる。また、その際、複数位置に出現する同一の構成要素に対しては、関係の指定を広く行うことによって、一つの条件指示で問い合わせを作成することができる。
【0024】
また、第2の発明では、木構造に階層化されてなる論理構造を持った構造化文書を管理対象とするデータベース管理システムにおいて、文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持手段と、前記文書タイプ保持手段から文書タイプのすべての構成要素を取り出す構成要素取出手段と、前記構成要素取出手段にて取り出された構成要素の集合を表示し、表示した構成要素の集合の中からユーザが選択した任意の二つの構成要素をユーザの入力操作によって受け付ける構成要素選択手段と、前記構成要素選択手段が受け付けた二つの構成要素間に存在する関係のすべてを前記文書タイプ保持手段に保持された文書タイプから検索する関係検索手段と、前記関係検索手段により検索された関係の集合を表示し、表示された関係の中からユーザが選択した関係をユーザの入力操作によって受け付ける関係選択手段と、前記構成要素選択手段が受け付けた二つの構成要素および前記関係選択手段が受け付けた関係から問い合わせを生成する問い合わせ生成手段と、前記問い合わせ生成手段により生成された問い合わせに含まれる構成要素を表示し、表示した構成要素をユーザが選択した場合に選択された構成要素のユーザによる編集を受け付ける問い合わせ編集手段と、前記構成要素取出手段にて取り出された構成要素の集合、前記関係検索手段により検索された関係の集合、および前記問い合わせ生成手段により生成された問い合わせを表示する表示手段と、を備えていることを特徴とするデータベース管理システムが提供される。
【0025】
このようなデータベース管理システムによると、文書検索のための問い合わせを作成する際には、まず、構成要素取出手段により文書タイプ保持手段から文書タイプのすべての構成要素を取り出し、取り出した構成要素を表示手段に表示する。取り出された構成要素の集合から、ユーザが任意の二つの構成要素を選択して、それを構成要素選択手段が受け付けると、選択された二つの構成要素の間に存在し得るすべての関係が関係検索手段により文書タイプから検索され、その検索結果は表示手段に表示される。検索された関係からユーザにより任意の一つの関係が選択されてそれを関係選択手段が受け付けると、問い合わせ生成手段が、選択された二つの構成要素と選択された関係とから問い合わせを生成する。生成された問い合わせに含まれる構成要素を表示してその構成要素がユーザによって選択された場合に問い合わせ編集手段が選択された構成要素のユーザによる編集を受け付ける。よって、文書タイプの構造を意識しなくても、問い合わせを作成することができる。また、その際、複数位置に出現する同一の構成要素に対しては、関係の指定を広く行うことによって、一つの条件指示で問い合わせ作成することができる。
【0026】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
図1は第1の発明によるデータベース管理システムの原理構成および実施の形態を示す図である。
【0027】
第1の発明のデータベース管理システムは、文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持部1と、文書タイプ中のすべての構成要素を取り出す構成要素取出部2と、第1の構成要素を選択する第1の構成要素選択部3と、第1の構成要素と後に選択する予定の第2の構成要素との間の関係を指定する関係指定部4と、第1の構成要素から見て指定された関係にあるすべての構成要素を検索する構成要素検索部5と、第2の構成要素を選択する第2の構成要素選択部6と、第1の構成要素と第2の構成要素とその二つの構成要素の関係とから問い合わせを生成する問い合わせ生成部7と、問い合わせに含まれる構成要素に対して編集を行う問い合わせ編集部8と、各種情報を表示するための表示部9とから構成されている。
【0028】
上記構成のデータベース管理システムでは、文書タイプ保持部1は、自データベース管理システムで取り扱う文書の論理構造を規定する文書タイプを、すべて保持している。
【0029】
ここで、文書タイプを保持するためのデータ構造は、一つの構成要素から、その上位および下位の任意の構成要素へ到達可能であれば、どんな形式のものでもよい。本実施の形態では、データ構造は、構成要素と生成規則をオブジェクトとして、オブジェクト間をポインタでリンクさせる形式としている。なお、一つの文書タイプ中の複数の位置に、「見出し」や「段落」のように同一の名称を持つ構成要素が複数回出現する場合がある。このような場合、「見出し」や「段落」に対応するオブジェクトはそれぞれ一つだけとし、そのオブジェクトが上位の構成要素へのポインタを複数持つようにする。
【0030】
構成要素取出部2は、文書タイプ保持部1から文書タイプの持つすべての構成要素を取り出し、取り出した構成要素は表示部9に表示される。本実施の形態では、問い合わせを作成する際、第1の構成要素と、第2の構成要素と、その二つの構成要素の間の関係とを文書の文脈に関する基本的な条件と考える。そこで、取り出された構成要素の集合から、第1の構成要素選択部3によって任意の一つの構成要素が選択され、これが作成される問い合わせの第1の構成要素となる。また、関係指定部4によって、第1の構成要素と後に選択する予定の第2の構成要素との関係が指定される。なお、これ以降、第1の発明のデータベース管理システムで問い合わせが作成される際に条件となる、第1の構成要素と、第2の構成要素と、その二つの構成要素の間の関係とを基本条件と呼ぶことにする。
【0031】
構成要素検索部5は、選択された第1の構成要素および指定された関係を基に、その条件を満たす構成要素を文書タイプ保持部1に保持された文書タイプから検索する。この検索の結果、第1の構成要素から見て指定された関係にあるすべての構成要素が得られ、表示部9に表示される。第2の構成要素選択部6によって、検索された構成要素から任意の一つの構成要素が選択され、作成される問い合わせの第2の構成要素となる。基本条件が揃ったところで問い合わせ生成部7は、第1の構成要素と、第2の構成要素と、その二つの構成要素の間の関係とから問い合わせを生成する。
【0032】
問い合わせ編集部8は、生成された問い合わせの編集を行う。ここで言う編集とは、問い合わせに含まれる構成要素に対する詳細な条件付けのことである。また、表示部9は、構成要素取出部2が取り出した文書タイプの持つすべての構成要素を表示したり、第1の構成要素から見て指定された関係にある、という条件で構成要素検索部5が検索した構成要素をすべて表示したり、問い合わせ生成部7が生成した問い合わせを表示したり、といった処理にあたる。
【0033】
次に、第1の発明のデータベース管理システムでは、どのような手順で問い合わせが作成されるのか説明する。
図2は第1の発明の実施の形態における問い合わせ作成の手順を示すフローチャートである。
【0034】
問い合わせが作成される際は、まず検索の対象となる文書タイプ名が指定される。データベース管理装置が問い合わせ作成の指示と文書タイプ名の指定とを受け付けると、構成要素取出部2は、指定された文書タイプを文書タイプ保持部1から読み込む(ステップS1)。次に、構成要素取出部2は、読み込んだ文書タイプに含まれる構成要素をすべて取り出して構成要素リストを作成し、表示部9に表示する(ステップS2)。
【0035】
表示された構成要素リストから、第1の構成要素選択部3によって任意の一つの構成要素が選択され、ここで選択された構成要素が、問い合わせを作成する第1の構成要素となる(ステップS3)。問い合わせ生成部7は、ここまでの処理で決定している条件から問い合わせを生成し、表示部9に表示する(ステップS4)。
【0036】
本実施の形態では、先に述べた基本条件を、問い合わせの作成に対する基本の条件と考えるが、問い合わせ自体は構成要素一つのみだけからでも作成することができる。条件の少ない問い合わせを用いて文書の検索をした場合には、結果として得られる文書またはその構成要素の数が増えるだけである。
【0037】
次に、生成された問い合わせが完成か否かが判断され(ステップS5)、完成ならばこのフローチャートの処理は終了する。問い合わせが未完成ならば、このフローチャートの処理は続く。
【0038】
問い合わせが未完成であるならば、その原因が判断される(ステップS6)。基本条件がまだ揃っていないならばステップS7へ進み、基本処理が行われる。また、本実施の形態では問い合わせの作成を基本条件に基づいて考えるが、必要に応じて条件とする構成要素が追加されることもある。基本条件が既に決定されており、別の構成要素が問い合わせに追加される場合には、再度ステップS3へ進む。この処理については、後に詳しく説明する。更に、既に問い合わせに含まれている構成要素に対して、詳細な条件付けがされる場合には、ステップS12へ進んで編集処理が行われる。この処理についても後で説明する。
【0039】
基本条件がまだ第1の構成要素しか存在しない場合には、関係指定部4によって、第1の構成要素と、これから決定する予定の第2の構成要素との関係が指定される(ステップS7)。そして構成要素検索部5は、第1の構成要素から見て指定された関係にある構成要素を、文書タイプ保持部1から検索して(ステップS8)、第2の構成要素の候補とする。なお、この処理の詳しい手順は後に述べる。
【0040】
構成要素検索部5による検索の結果、第2の構成要素の候補が存在しているか否かが判断され(ステップS9)、存在していればステップS10へ進む。第2の構成要素の候補が存在していなければ、エラーメッセージが出され(ステップS14)、ステップS4の処理に戻る。
【0041】
構成要素検索部5は、検索の結果、第2の構成要素の候補となった構成要素のリストを作成し、表示部9に表示する(ステップS10)。第2の構成要素選択部6は、その検索結果から任意の一つの構成要素を選択し、ここで選択された構成要素が、作成される問い合わせの第2の構成要素となる(ステップS11)。これで基本条件がすべて揃ったので、再度ステップS4へ進み、問い合わせが生成される。
【0042】
ここで、ステップS6の分岐において、構成要素の追加が選択された場合の処理について説明する。問い合わせに構成要素が追加される場合にも、やはり構成要素二つとその関係とが基本の単位となる。ステップS3へ進み、基本条件の選出と同じ手順で構成要素が追加される。つまり、第1の構成要素と、第2の構成要素と、第1の構成要素と第2の構成要素との間の関係とを揃えればよい。
【0043】
ただし、構成要素が追加される場合には、構成要素リストからだけではなく、既にステップS4において生成された問い合わせの条件として木構造で表示されている構成要素から任意の一つが選択されて、第1の構成要素とすることもある。この処理が繰り返されると、任意の大きさの木構造が問い合わせの条件となる。
【0044】
次に、ステップS6の分岐において構成要素の編集が選択された場合の処理について説明する。既に問い合わせに含まれている構成要素に対して詳細な条件付けがされる場合には、まず、対象となる構成要素が選択される(ステップS12)。その後、付加する条件が入力され、問い合わせの編集が行われる(ステップS13)。
【0045】
次に、図2のステップS8で述べた構成要素の検索処理について説明する。
図3は構成要素検索処理の手順を示したフローチャートである。
構成要素検索部5はまず、検索の対象である文書タイプを読み込む(ステップS21)。そして読み込んだ文書タイプから、ここまでの処理で決定している第1の構成要素を検索する(ステップS22)。
【0046】
次に構成要素検索部5は、第1の構成要素と第2の構成要素との関係として指定された関係が何であるかを判断する(ステップS23)。そして、指定された関係が「親」ならば、第1の構成要素の親の要素を検索する(ステップS24)。また、指定された関係が「子」ならば、第1の構成要素の子の要素を検索する(ステップS25)。更に、指定された関係が「祖先」ならば、第1の構成要素の祖先の要素を検索し(ステップS26)、指定された関係が「子孫」ならば、第1の構成要素の子孫の要素を検索する(ステップS27)。
【0047】
ここで、第1の発明のデータベース管理システムの実施の形態における、問い合わせ作成の画面の例をあげて、問い合わせ作成の手順の説明を行う。
図4は第1の発明の実施の形態に基づく問い合わせ作成画面の一例を示す図である。
【0048】
問い合わせ作成画面10は、文書タイプの構成要素リストを表示する構成要素表示部11と、第1の構成要素と第2の構成要素との関係をどのような関係とするか指定する関係指定部12と、作成した問い合わせの編集を行う指示を出す編集開始ボタン13と、第1の構成要素と指定された関係を持つ構成要素の検索を指示する検索開始ボタン14と、第2の構成要素の候補を表示する検索結果表示部15と、作成した問い合わせを表示する問い合わせ表示部16とから構成されている。
【0049】
問い合わせ作成画面10は、図1に示した表示部9と対応している。ここで、構成要素表示部11は図1の構成要素取出部2の取り出した構成要素を表示する役割と、第1の構成要素選択部3の役割とを果たす。同様に検索結果表示部15は、構成要素検索部5の検索結果を表示する役割と、第2の構成要素選択部6の役割とを果たす。
【0050】
ここで、図21に示した文書タイプ「報告書」に基づいた文書に関する検索のための問い合わせが作成されるとして、問い合わせ作成画面の表示および利用の様子を順を追って説明する。
【0051】
なお、作成される問い合わせの条件は、図22に示した「章の見出しに”データベース”という文字列を含み、章の中の任意の段落に”構造”という文字列を含むような章を検索して取り出すこと」とする。
【0052】
図2のフローチャートに沿って問い合わせは作成されるが、まず、第1の構成要素と第2の構成要素との間の関係が指定される、ステップS7までの説明を行う。
【0053】
図5は第1の発明の実施の形態にて二つの構成要素間の関係が指定された時の問い合わせ作成画面を示す図である。
文書タイプ名「報告書」が入力され(ステップS1)、構成要素表示部11にリスト表示された構成要素(ステップS2)から、ポインティングデバイスなどによって第1の構成要素として「章」が選択される(ステップS3)。また、第1の構成要素と第2の構成要素との関係として「子」が選択される(ステップS7)。
【0054】
第1の構成要素として「章」が選択された結果、構成要素表示部11では構成要素「章」が他の構成要素と区別して表示される。また、第1の構成要素と第2の構成要素との関係として「子」が選択された結果、関係指定部12では関係「子」がチェックされる。
【0055】
問い合わせ表示部16には確定している問い合わせ条件「章」が表示されている。ここで問い合わせの作成が終了すると、この問い合わせは『「報告書」から「章」を検索して取り出す』という問い合わせとなる。
【0056】
このように、検索の対象とする文書タイプが指定されると、構成要素取出部2が該当する文書タイプの構成要素を文書タイプ保持部1から取り出し、構成要素表示部11に表示する。そのため、ユーザは文書タイプの持つ構成要素にどのようなものがあるのか知らなくとも、第1の構成要素を決定できる。
【0057】
次に、第2の構成要素の候補が表示されるステップS10までの説明を行う。図6は第1の発明の実施の形態にて検索結果の表示が行われた時の問い合わせ作成画面を示す図である。
【0058】
要素検索ボタン14が押され、第1の構成要素である「章」から見て指定した関係にある、つまり「子供」にあたる構成要素が検索される(ステップS8)。図21を見ると、文書タイプ「報告書」の構成要素「章」には「子供」にあたる要素として、構成要素「見出し」と構成要素「章内容」とが存在していることが判る(ステップS9)。そこで、構成要素「見出し」と構成要素「章内容」とが検索結果表示部15に表示される(ステップS10)。
【0059】
このように、第1の構成要素と第2の構成要素との関係が指定されれば、構成要素検索部5は、第2の構成要素の候補となる構成要素を、文書タイプ保持部1から検索し、検索結果表示部15に表示する。そのため、ユーザは文書タイプの持つ構成要素の出現順序や包含関係を知らなくとも、第2の構成要素の候補となる構成要素を得ることができる。
【0060】
次に、第2の構成要素が選択されるステップS11までの説明を行う。
図7は第1の発明の実施の形態にて第2の構成要素が選択された時の問い合わせ作成画面を示す図である。
【0061】
検索結果表示部15に表示された構成要素から、ポインティングデバイスなどによって構成要素「見出し」が第2の構成要素として選択される(ステップS11)。ここで、第2の構成要素として選択された結果、構成要素「見出し」は他の構成要素と区別して表示される。また、問い合わせ表示部16には確定している問い合わせ条件「章」および「見出し」が表示されている。構成要素「章」と構成要素「見出し」との関係は親子関係であるので、親子関係を示す実線でこの二つの構成要素は接続されている。
【0062】
ここで、問い合わせの作成が終了すると、この問い合わせは『「子」として「見出し」という構成要素を含む「章」という構成要素』を検索する問い合わせとなる。
【0063】
次に、問い合わせに含まれる構成要素に条件が付加されるステップS13までの説明を行う。
図8は第1の発明の実施の形態にて編集の対象となる構成要素が選択された時の問い合わせ作成画面を示す図である。
【0064】
問い合わせ表示部16から、ポインティングデバイスなどによって、構成要素「見出し」が編集対象として選択される(ステップS12)。編集対象が選択され、編集開始ボタン13が押されると、問い合わせ編集画面17が起動される。
【0065】
問い合わせ表示部16では、編集対象として選択された構成要素「見出し」が二重線で囲まれ、他の構成要素と区別される。また、問い合わせ編集画面17は「”見出し”の条件」の入力を受け付ける。
【0066】
起動された問い合わせ編集画面17には構成要素「見出し」に付随させる条件として文字列”データベース”が入力される(ステップS13)。
図9は第1の発明の実施の形態にて構成要素に条件が付加された時の問い合わせ作成画面を示す図である。
【0067】
文字列”データベース”は構成要素「見出し」に関する条件であるので、問い合わせ表示部16では構成要素「見出し」の下にこの文字列を二重線で接続して、この関係を表わしている。ここで問い合わせの作成が終了すると、この問い合わせは『”データベース”という文字列を含んでいる「見出し」という構成要素を子供として持つ「章」という構成要素』を検索する問い合わせとなる。
【0068】
次に、ステップS6の判定にて構成要素が追加される場合の説明を行う。
図10は第1の発明の実施の形態にて構成要素が追加された時の問い合わせ作成画面を示す図である。
【0069】
問い合わせ表示部16から、ポインティングデバイスなどによって構成要素「章」が第1の構成要素として選択される(ステップS3)。また、関係指定部12にて第1の構成要素と第2の構成要素との関係として「子孫」が選択される(ステップS7)。要素検索ボタン14が押され、構成要素「章」から見て「子孫」にあたる構成要素が検索され(ステップS8)、検索結果が検索結果表示部15に表示される(ステップS10)。表示された結果から、ポインティングデバイス等によって構成要素「段落」が、第2の構成要素として選択される(ステップS11)。
【0070】
構成要素「章」と構成要素「段落」との関係は祖孫関係(祖先と子孫との関係)であるので、祖孫関係を示す点線でこの二つの構成要素が接続されている。
ここで問い合わせの作成が終了すると、この問い合わせは『”データベース”という文字列を持つ「見出し」という構成要素を子供に持ち、「段落」という構成要素を子孫に持つ「章」という構成要素』を検索する問い合わせとなる。
【0071】
次に、追加した構成要素に対して編集が行われるステップS13までの説明を行う。
図11は第1の発明の実施の形態にて追加された構成要素に条件が付加された時の問い合わせ作成画面を示す図である。
【0072】
問い合わせ表示部16から、ポインティングデバイスなどによって構成要素「段落」が編集対象として選択され(ステップS12)、編集開始ボタン13が押されると、問い合わせ編集画面が起動される。起動された問い合わせ編集画面にて構成要素「段落」に付随させる条件の設定が行われ(ステップS13)、問い合わせの作成が終了する(ステップS5)。
【0073】
ここで、作成された問い合わせは、『”データベース”という文字列を持つ「見出し」という構成要素を子供に持ち、”構造”という文字列を持つ「段落」という構成要素を子孫に持つ、「章」という構成要素』を検索する問い合わせである。
【0074】
上記の説明では構成要素「見出し」に対する編集が、構成要素「段落」の追加の前に行われたが、この作業の順番は逆でもよい。また、構成要素「段落」が追加されたのと同様、問い合わせの条件はいくらでも多くなる。更に、問い合わせ作成画面はここにあげた例に限るものではない。構成要素が選択可能であり、構成要素間の親子関係と祖孫関係が区別できれば、利用方法に応じた形式を採ればよい。また、問い合わせの構成要素に付加する条件として、文字列以外を指定することもできる。文書タイプの構成要素が属性を持つならば、その属性に関する条件も編集できるように構成する。
【0075】
このようなデータベース管理システムによって、ユーザは文書の検索を行うための問い合わせを作成する際、文書タイプの持つ構成要素や、その出現順序および包含関係について知らなくとも、問い合わせを作成することができる。
【0076】
次に、第2の発明について図面を参照して説明する。
図12は第2の発明によるデータベース管理システムの原理構成および実施の形態を示す図である。
【0077】
第2の発明のデータベース管理システムは、文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持部21と、文書タイプ中のすべての構成要素を取り出す構成要素取出部22と、第1および第2の構成要素を選択する構成要素選択部23と、第1の構成要素と第2の構成要素との間に存在し得る関係を検索する関係検索部24と、第1の構成要素と第2の構成要素との関係を選択する関係選択部25と、第1の構成要素と第2の構成要素とその二つの構成要素の関係とから問い合わせを生成する問い合わせ生成部26と、問い合わせに含まれる構成要素に対して編集を行う問い合わせ編集部27と、各種情報を表示するための表示部28とから構成されている。
【0078】
上記構成のデータベース管理システムでは、文書タイプ保持部21は、自データベース管理システムで取り扱う文書の論理構造を規定する文書タイプを、すべて保持している。
【0079】
ここで、文書タイプを保持するためのデータ構造は、一つの構成要素から、その上位および下位の任意の構成要素へ到達可能であれば、どんな形式のものでもよい。なお、本実施の形態におけるデータ構造は、第1の発明の実施の形態のデータ構造と同じものとする。
【0080】
構成要素取出部22は、文書タイプ保持部21から文書タイプの持つすべての構成要素を取り出し、取り出された構成要素は表示部28に表示される。本実施の形態でも、第1の発明の実施の形態同様、問い合わせを作成する際には、第1の構成要素と、第2の構成要素と、その二つの構成要素の間の関係とを基本条件と考える。そこで、取り出された構成要素の集合から、構成要素選択部23によって任意の二つの構成要素が選択され、作成される問い合わせの第1および第2の構成要素とされる。
【0081】
関係検索部24は、選択された二つの構成要素を基に文書タイプ保持部21に保持された文書タイプを検索する。この検索の結果、第1の構成要素と第2の構成要素との間に存在し得るすべての関係が得られ、表示部28に表示される。検索された関係から、関係選択部25によって、第1の構成要素と第2の構成要素との関係が選択される。問い合わせを作成する基本条件が揃ったところで、問い合わせ生成部26は、第1の構成要素と、第2の構成要素と、その二つの構成要素の間の関係とから問い合わせを生成する。
【0082】
問い合わせ編集部27は、生成された問い合わせに含まれる構成要素に対する詳細な条件付けを行う。また、表示部28は、構成要素取出部22が取り出した文書タイプの持つすべての構成要素を表示したり、関係検索部24が検索した第1の構成要素と第2の構成要素との間に存在し得る関係をすべて表示したり、問い合わせ生成部26が生成した問い合わせを表示したり、といった処理にあたる。
【0083】
次に、第2の発明のデータベース管理システムでは、どのような手順で問い合わせが作成されるのか説明する。
図13は第2の発明の実施の形態における問い合わせ作成の手順を示すフローチャートである。
【0084】
問い合わせが作成される際は、まず検索の対象となる文書タイプ名が指定される。データベース管理システムが問い合わせ作成の指示と文書タイプ名の指定とを受け付けると、構成要素取出部22は、指定された文書タイプを文書タイプ保持部21から読み込む(ステップS31)。次に、構成要素取出部22は、読み込んだ文書タイプに含まれる構成要素をすべて取り出して構成要素リストを作成し、表示部28に表示する(ステップS32)。
【0085】
表示された構成要素リストから、構成要素選択部23によって任意の一つの構成要素が選択され、ここで選択された構成要素が、作成される問い合わせの第1の構成要素となる(ステップS33)。問い合わせ生成部26は、ここまでの処理で決定している条件から問い合わせを生成し、表示部28に表示する(ステップS34)。
【0086】
次に、生成された問い合わせが完成か否か判断され(ステップS35)、完成ならばこのフローチャートの処理は終了する。問い合わせが未完成ならばこのフローチャートの処理は続く。
【0087】
問い合わせが未完成であるならば、その原因が判断される(ステップS36)。基本条件がまだ揃っていないならばステップS37へ進み、基本処理が行われる。また、基本条件が既に決定されており、別の構成要素が問い合わせに追加される場合には、再度ステップS33へ進む。この処理については、後に詳しく説明する。更に、既に問い合わせに含まれている構成要素に対して、詳細な条件付けがされる場合には、ステップS42へ進んで編集処理が行われる。この処理についても後で説明する。
【0088】
基本条件がまだ第1の構成要素しか存在しない場合には、表示された構成要素リストから、構成要素選択部23によって任意の一つの構成要素が選択され、ここで選択された構成要素が、作成される問い合わせの第2の構成要素となる(ステップS37)。関係検索部24は文書タイプ保持部21から、第1の構成要素と第2の構成要素との間に存在し得る関係を検索して(ステップS38)、検索結果を表示部28に表示する。なお、この処理の詳しい手順は後に述べる。
【0089】
関係検索部24による検索の結果、第1の構成要素と第2の構成要素との間に存在し得る関係があったがどうかが判断され(ステップS39)、関係があればステップS40へ進む。二つの構成要素の間に直系の関係(親子関係もしくは祖孫関係)が存在していなければ、エラーメッセージが出され、ステップS34の処理に戻る(ステップS44)。
【0090】
関係検索部24は、検索の結果、第1の構成要素と第2の構成要素との間に存在した関係のリストを作成し、表示部28に表示する(ステップS40)。次に、検索結果のリストから、関係選択部25によって任意の一つの関係が選択される(ステップS41)。基本条件がすべて揃ったので、再度ステップS34へ進み、問い合わせが生成される。
【0091】
ここで、ステップS36の分岐において、構成要素の追加が選択された場合の処理について説明する。問い合わせに構成要素が追加される場合にも、やはり構成要素二つとその関係とが基本の単位となる。ステップS33へ進み、基本条件の選出と同じ手順で構成要素が追加される。つまり、第1の構成要素と、第2の構成要素と、第1の構成要素と第2の構成要素との間の関係とを揃えればよいことになる。
【0092】
ただし、構成要素が追加される場合には、構成要素リストからだけではなく、既にステップS34において生成された問い合わせの条件として木構造で表示されている構成要素から任意の一つが選択されて、第1の構成要素とすることもある。この処理が繰り返されると、任意の大きさの木構造が問い合わせの条件となる。
【0093】
次に、ステップS36の分岐において構成要素の編集が選択された場合の処理について説明する。既に問い合わせの条件となっている構成要素に対して詳細な条件付けがされる場合には、まず、対象とする構成要素が選択される(ステップS42)。その後、付加する条件が入力され、問い合わせの編集が行われる(ステップS43)。
【0094】
次に、図13のステップS38で述べた、第1の構成要素と第2の構成要素との間に存在し得る関係を検索する処理について説明する。
図14は関係検索処理の手順を示したフローチャートである。
【0095】
関係検索部24はまず、検索の対象である文書タイプを読み込む(ステップS51)。そして読み込んだ文書タイプから、ここまでの処理で決定している第1の構成要素を検索する(ステップS52)。
【0096】
次に、関係検索部24は、第1の構成要素の親になり得る構成要素を検索する(ステップS53)。検索結果の中に第2の構成要素と一致するものが存在するか否か判断し(ステップS54)、存在していたならば「子→親」関係を表示する(ステップS55)。
【0097】
続いて、関係検索部24は、第1の構成要素の祖先になり得る構成要素を検索する(ステップS56)。検索結果の中に第2の構成要素と一致するものが存在するか否か判断し(ステップS57)、存在していたならば「子孫→祖先」関係を表示する(ステップS58)。
【0098】
更に、関係検索部24は、読み込んだ文書タイプから、ここまでの処理で決定している第2の構成要素を検索する(ステップS59)。また、第2の構成要素の親になり得る構成要素を検索する(ステップS60)。検索結果の中に第1の構成要素と一致するものが存在するか否か判断し(ステップS61)、存在していたならば「親→子」関係を表示する(ステップS62)。
【0099】
最後に、関係検索部24は、第2の構成要素の祖先になり得る構成要素を検索する(ステップS63)。検索結果の中に第1の構成要素と一致するものが存在するか否か判断し(ステップS64)、存在していたならば「祖先→子孫」関係を表示する(ステップS65)。
【0100】
ここで、第2の発明のデータベース管理システムの、実施の形態における問い合わせ作成の画面の例をあげて、問い合わせ作成の手順の説明を行う。
図15は第2の発明の実施の形態に基づく問い合わせ作成画面の一例を示す図である。
【0101】
問い合わせ作成画面30は、文書タイプの構成要素リストを表示する構成要素表示部31および32と、作成した問い合わせの編集を行う指示を出す編集開始ボタン33と、第1の構成要素と第2の構成要素との間に存在し得る関係を検索させる関係検索ボタン34と、第1の構成要素と第2の構成要素との間に存在する関係を表示する関係表示部35と、作成した問い合わせを表示する問い合わせ表示部36とから構成されている。
問い合わせ作成画面30は、図12に示した表示部28と対応している。ここで構成要素表示部31および32は図12の構成要素取出部22が取り出した構成要素を表示する役割と、構成要素選択部23の役割とを果たす。同様に関係表示部35は、関係検索部24の検索結果を表示する役割と、関係選択部25の役割とを果たす。
【0102】
ここで、図21に示した文書タイプ「報告書」に基づいた文書に関する検索のための問い合わせが作成されるとして、問い合わせ作成画面の表示および利用の様子を順を追って説明する。なお、作成される問い合わせの条件は、図22に示した「章の中の任意の位置にある見出しに”データベース”という文字列を含むような章を検索して取り出すこと」とする。
【0103】
図13のフローチャートに沿って問い合わせは作成されるが、まず、第2の構成要素が選択される、ステップS37までの説明を行う。
図16は第2の発明の実施の形態にて二つの構成要素が選択された時の問い合わせ作成画面を示す図である。
【0104】
文書タイプ名「報告書」が入力され(ステップS31)、構成要素表示部31にリスト表示された構成要素(ステップS32)から、ポインティングデバイスなどによって第1の構成要素として「章」が選択され(ステップS33)、同様に、構成要素表示部32にリスト表示された構成要素から、第2の構成要素として「見出し」が選択される(ステップS37)。
【0105】
第1の構成要素として「章」が選択された結果、構成要素表示部31では構成要素「章」が他の構成要素と区別して表示される。また、第2の構成要素として「見出し」が選択された結果、構成要素表示部32では構成要素「見出し」が他の構成要素と区別して表示される。
【0106】
問い合わせ表示部36には確定している問い合わせ条件「章」および「見出し」が表示されている。ここで問い合わせの作成が終了すると、この問い合わせは『「章」という構成要素または「見出し」という構成要素』を検索する問い合わせとなる。
【0107】
このように、検索の対象とする文書タイプが指定されると、構成要素取出部22が該当する文書タイプの構成要素を文書タイプ保持部21から取り出し、構成要素表示部31および32に表示する。そのため、ユーザは文書タイプの持つ構成要素にどのようなものがあるのか知らなくとも、第1および第2の構成要素を決定できる。
【0108】
次に、第1の構成要素と第2の構成要素との間に存在する関係が表示される、ステップS40までの説明を行う。
図17は第2の発明の実施の形態にて検索結果が表示された時の問い合わせ作成画面を示す図である。
【0109】
関係検索ボタン34が押され、第1の構成要素である「章」と第2の構成要素である「見出し」との間に存在し得る関係が検索される(ステップS38)。図21を見ると文書タイプ「報告書」の構成要素「章」と構成要素「見出し」との間には親子関係と、祖孫関係(祖先と孫との関係)が存在していることが判る(ステップS39)。そこで、「親→子」関係と「祖先→子孫」関係とが関係表示部35に表示される(ステップS40)。
【0110】
このように、第1の構成要素と第2の構成要素とが選択されれば、関係検索部24は第1の構成要素と第2の構成要素との間に存在し得る関係を、文書タイプ保持部21から検索し、関係表示部35に表示する。そのため、ユーザは文書タイプの持つ構成要素の出現順序や包含関係を知らなくとも、第1の構成要素と第2の構成要素との間に存在する関係を得ることができる。
【0111】
次に、第1の構成要素と第2の構成要素との関係が選択される、ステップS41までの説明を行う。
図18は第2の発明の実施の形態にて二つの構成要素の間の関係が選択された時の問い合わせ作成画面を示す図である。
【0112】
関係表示部35に表示された関係から、ポインティングデバイスなどによって関係「祖先→子孫」が第1の構成要素と第2の構成要素との関係として選択される(ステップS42)。ここで、第1の構成要素と第2の構成要素との関係として選択された結果、関係「祖先→子孫」は他の関係と区別して表示される。また、問い合わせ表示部36には構成要素「章」と構成要素「見出し」とが祖孫関係を示す点線で接続されて表示されている。
【0113】
ここで問い合わせの作成が終了すると、この問い合わせは『子孫として「見出し」という構成要素を含む「章」という構成要素』を検索する問い合わせとなる。
【0114】
次に、問い合わせに含まれる構成要素に条件が付加されるステップS43までの説明を行う。
図19は第2の発明の実施の形態にて構成要素に条件が付加された時の問い合わせ作成画面を示す図である。
【0115】
問い合わせ表示部36から、ポインティングデバイスなどによって構成要素「見出し」が編集対象として選択される(ステップS42)。編集対象が選択され、編集開始ボタン33が押されると、問い合わせ編集画面が起動される。そして、起動された問い合わせ編集画面で構成要素「見出し」に付随させる条件として文字列”データベース”が入力される(ステップS43)。
【0116】
この問い合わせは『「章」という構成要素の下位」の任意の位置にある「見出し」という構成要素に”データベース”という文字列を含むような「章」という構成要素』を検索する問い合わせとなる。なお、『「見出し」という構成要素を子孫に持つ「章」』と言う場合、図21に示す文書タイプ41では構成要素「見出し」は、構成要素「章」の子供である場合と曾孫である場合との二通りがあるが、ここではその区別を行わない。
【0117】
上記の説明では構成要素を二つだけ含む問い合わせを作成したが、第1の発明の実施の形態同様、問い合わせの条件はいくらでも増やすことができる。更に、問い合わせ作成画面はここにあげた例に限るものではなく、ユーザの利用方法に応じて利用しやすい表現を採ればよい。問い合わせに含む構成要素の条件に、文字列以外を含むこともできる。
【0118】
このようなデータベース管理システムによって、ユーザは文書の検索を行うための問い合わせを作成する際、文書タイプの持つ構成要素や、その出現順序および包含関係について知らなくとも、問い合わせを作成することができる。
【0119】
【発明の効果】
以上説明したように、本発明では検索の対象となる文書タイプ名を入力すれば該当する文書タイプの構成要素をすべて表示する構成要素取出手段と、第1の構成要素および第2の構成要素を選択する手段と、第1の構成要素と第2の構成要素との間の関係を指定または選択する手段と、二つの構成要素とその間の関係とから問い合わせを生成する問い合わせ生成手段とを備えるようにした。これにより、ユーザは文書タイプの構造を意識することなく、文書検索のための問い合わせを作成することができる。
【0120】
また、本発明では構成要素の表示の際、その構成要素が文書タイプのどの位置に存在するかという情報を指定する必要がなく、そのため、複数位置に出現する同一の構成要素に対して一度の条件指示で、文書探索のための問い合わせを作成することができる。
【図面の簡単な説明】
【図1】第1の発明によるデータベース管理システムの原理構成および実施の形態を示す図である。
【図2】第1の発明の実施の形態における問い合わせ作成の手順を示すフローチャートである。
【図3】構成要素検索処理の手順を示したフローチャートである。
【図4】第1の発明の実施の形態に基づく問い合わせ作成画面の一例を示す図である。
【図5】第1の発明の実施の形態にて二つの構成要素間の関係が指定された時の問い合わせ作成画面を示す図である。
【図6】第1の発明の実施の形態にて検索結果の表示が行われた時の問い合わせ作成画面を示す図である。
【図7】第1の発明の実施の形態にて第2の構成要素が選択された時の問い合わせ作成画面を示す図である。
【図8】第1の発明の実施の形態にて編集の対象となる構成要素が選択された時の問い合わせ作成画面を示す図である。
【図9】第1の発明の実施の形態にて構成要素に条件が付加された時の問い合わせ作成画面を示す図である。
【図10】第1の発明の実施の形態にて構成要素が追加された時の問い合わせ作成画面を示す図である。
【図11】第1の発明の実施の形態にて追加された構成要素に条件が付加された時の問い合わせ作成画面を示す図である。
【図12】第2の発明によるデータベース管理システムの原理構成および実施の形態を示す図である。
【図13】第2の発明の実施の形態における問い合わせ作成の手順を示すフローチャートである。
【図14】関係検索処理の手順を示したフローチャートである。
【図15】第2の発明の実施の形態に基づく問い合わせ作成画面の一例を示す図である。
【図16】第2の発明の実施の形態にて二つの構成要素が選択された時の問い合わせ作成画面を示す図である。
【図17】第2の発明の実施の形態にて検索結果が表示された時の問い合わせ作成画面を示す図である。
【図18】第2の発明の実施の形態にて二つの構成要素の間の関係が選択された時の問い合わせ作成画面を示す図である。
【図19】第2の発明の実施の形態にて構成要素に条件が付加された時の問い合わせ作成画面を示す図である。
【図20】構造化文書を木構造で表現した一例を示す図である。
【図21】文書タイプの一例を示す図である。
【図22】文書の文脈に関する条件を持った問い合わせを図式的に表わした一例を示す図である。
【図23】従来の問い合わせエディタの表示画面の一例を示す図である。
【符号の説明】
1 文書タイプ保持部
2 構成要素取出部
3 第1の構成要素選択部
4 関係指定部
5 構成要素検索部
6 第2の構成要素選択部
7 問い合わせ生成部
8 問い合わせ編集部
9 表示部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a database management system for managing structured documents, and more particularly to a database management system capable of creating a query based on the logical structure of a document using information on syntax rules that define the structures that the document can take. .
[0002]
[Prior art]
In general, some documents are composed of logical components represented by chapters, sections, sections, etc., but such logical components are hierarchized into a tree structure according to predetermined rules. Documents are specifically called structured documents. For example, SGML (Standard Generalized Markup Language; ISO 8879) is known as an international standard for structured documents. Here, an example of a structured document is shown.
[0003]
FIG. 20 is a diagram illustrating an example of a structured document expressed in a tree structure.
As shown in the figure, the structured document is represented by a tree structure corresponding to the logical components of the document. In the
[0004]
A structured document is created according to rules that define the types of components that can appear in the document, the order of appearance of each component, the inclusion relationship between components, and the like. This rule defining structured documents is called a document type. In SGML described above, DTD (Document Type Definition) is a concept corresponding to a document type. Here, the document type that defines the
[0005]
FIG. 21 is a diagram showing an example of a document type.
In the document type 41 shown in the figure, a rectangle represents a constituent element of the document type, and an ellipse represents a generation rule that defines the appearance form of a lower constituent element. The meaning of this generation rule will be described. First, the generation rule “SEQ” represents that the lower order components of this generation rule appear in order from left to right. The generation rule “REP” represents that a lower-order component of the generation rule repeatedly appears one or more times. The production rule “CHO” indicates that any one of the lower components of the production rule appears.
[0006]
The highest-level component in the document type 41 is “report”. The highest level component represents the entire document, and it can be seen that this document type 41 is a document type named “Report”. Further, the following can be understood from the document type 41. That is, the component “report” has three components, “front”, “main body”, and “retro”, in its lower structure. The production rule “SEQ” for these three components below the component “report” stipulates that the three components must appear in this order in the document.
[0007]
Under the component “front matter”, the four components “title”, “author”, “date”, and “summary” must appear in this order. In addition, the component “paragraph” must appear one or more times below the component “summary”. The component “chapter” must appear repeatedly one or more times below the component “main body”. In addition, the component “heading” and “chapter content” must appear in this order below the component “chapter”. Under the component “chapter content”, either the component “paragraph” or the component “section” must appear repeatedly one or more times. Furthermore, the component “heading” and “section content” must appear in this order below the component “section”. The component “paragraph” must appear repeatedly one or more times below the component “section content”. Then, under the component “retrofitting”, the component “document” must repeatedly appear one or more times.
[0008]
Thus, a document generated based on a document type having a predetermined rule can be managed using a database. In a database that manages a large number of documents, when searching for a document or its constituent elements, an efficient search can be performed if a query is created using a condition relating to the context of the necessary document or its constituent elements.
[0009]
The condition relating to the context of the document referred to here means a condition expressed by a combination of a condition for specifying a component of the document and a condition for specifying a hierarchical relationship between the components. For example, “searching and extracting a chapter that includes the character string“ database ”in the chapter heading and the character string“ structure ”in an arbitrary paragraph in the chapter” is a context-related condition. Here, “chapter”, “heading”, and “paragraph” represent components that appear in the structured document. In addition, “heading” including the character string “database” and “paragraph” including the character string “structure” respectively represent the conditions regarding the constituent elements. It can be said that the heading of “chapter” as “heading” and the inclusion of “paragraph” in “chapter” define the hierarchical relationship between the constituent elements.
[0010]
FIG. 22 is a diagram showing an example in which an inquiry having a condition regarding a document context is schematically represented.
The
[0011]
In a conventional database that manages structured documents, there is a method disclosed in Japanese Patent Application Laid-Open No. 6-301721 as a method for performing a search by specifying conditions relating to the context of a document. In this method, a document is decomposed into components and stored in a relational database. A search language that can specify a document structure is converted into SQL (Structured Query Language), which is a standard processing language of a relational database, and a search is performed.
[0012]
However, in this method, a query cannot be created unless the user knows in advance the document type information, that is, the constituent elements that can appear in the structure of the document type and the information about the appearance order and inclusion relations of all the constituent elements. . In other words, if you do not know the document type information, even if you create a query that specifies the context, you do not know whether the query conforms to the structure of the document type, and as a result, there are no documents that satisfy the condition. There is also a possibility.
[0013]
As a method of solving this problem, there is a method of creating a query by presenting the structure of the document type to the user when performing a search. For example, "MULTIS (" Multimedia Office Filling-The MULTOS Approach- ", Edited by C. Thanos, North-Holland, 1990, ISBN: 0-444-88456-4)", one of the document database management systems, ODA (Open Document Architecture; ISO 8613) documents are managed, and the conditions related to the logical structure of the document are expressed as nodes (representing components) and arcs (representing relationships between components) by a graphical pointing device called an inquiry editor. ) And so on. In the query editor of “MULTIS”, the structure of the document type or the structure of a specific document in the database is displayed on the screen in a tree structure, the document type or the component of the document is selected, and the conditions for the corresponding component are described. can do. An example of the query editor is shown below.
[0014]
FIG. 23 is a diagram showing an example of a display screen of a conventional inquiry editor.
The inquiry
[0015]
When the user inputs the document type name to the document type
[0016]
By using such an inquiry editor, the user can create an inquiry by referring to the structure of the document type displayed on the screen, so it is not necessary to know the document type in advance.
[0017]
[Problems to be solved by the invention]
However, considering a structured document on a practical scale, the document type has a large number of components and often has a complex structure. In addition, when the document type is expressed in a tree structure, one component may appear as a plurality of nodes, so that the number of nodes in the tree is larger than the number of components.
[0018]
For example, “Books DTD”, which is defined as one of the document type definitions (DTD) of SGML documents in the international standard (Information and documentation − Electronic manuscript preparation and markup; ISO 12083: 1994), describes the structure of the document type. The number of elements is over 70. In addition, if this document type is expressed in a tree structure, the number of nodes in the tree will be enormous. Even if the same component appears multiple times, only one of them will be expanded to the subtree and the others will not be expanded. Even so, the number of nodes in the tree exceeds 1000.
[0019]
In this way, when creating a search query for a structured document based on the structure of a document type of a practical scale, the structure that is displayed in the method of creating a query by displaying the structure of the document type Since the number of elements is very large, there is a problem that it takes a lot of work to search for a component for which a condition is to be specified.
[0020]
In addition, since the same component can appear multiple times in one document type, if you want to specify the same condition for a certain component regardless of the appearance position, it will be applicable from the displayed tree structure. All components must be searched for and conditions must be specified, which has been a heavy burden on the user.
[0021]
The present invention has been made in view of such points, and the user is not aware of the structure of the document type, and for the same component appearing at a plurality of positions, a single condition instruction is given. It is an object of the present invention to provide a database management system capable of creating a query for document retrieval.
[0022]
[Means for Solving the Problems]
In the first invention, in order to solve the above-mentioned problem, in a database management system for managing structured documents having a logical structure hierarchized in a tree structure, a syntax rule defining a logical structure that can be taken by the document A document type holding unit that holds the document type, a component extraction unit that extracts all components of the document type from the document type holding unit, and a first of the components extracted by the component extraction unit set And the user selects from the displayed first set Any one component of the user Accept by input operation First component selection means, and the first component selection means Accepted The first component and User Between the components to be selected next User specified Relationship of user Accept by input operation Relationship specifying means and the first component selection means Accepted The relationship specifying means as seen from the first component Accepted A component element search unit that searches all component elements having the same relationship from the document type held in the document type holding unit; and a second set of component elements searched by the component element search unit And the user selects from the displayed second set Any one second component of the user Accepted by input operation Second component selection means and the first component selection means Accepted First component, the relationship specifying means Accepted Relationship and the second component selection means Accepted Query generating means for generating a query from the second component, and components included in the query generated by the query generating means When the user selects the displayed component In Of the selected component A user by Edit Accept A query editing means; and a first set of components extracted by the component extraction means; The relationship between the components to be specified by the user, There is provided a database management system comprising: a second set of component elements searched by the component element search means; and a display means for displaying an inquiry generated by the inquiry generation means. The
[0023]
According to such a database management system, when creating a query for document retrieval, first, all the components of the document type are extracted from the document type holding unit by the component extracting unit, and these are displayed on the display unit. indicate. From the set of extracted components, Any one component selected by the user First component selection means Accepted Furthermore, the relationship between the currently selected component and the next component to be selected is Specified by the user Relationship designation means Accept . Next, the constituent element search means searches all the constituent elements having the designated relationship as seen from the selected constituent element from the document type holding means, and displays the search result on the display means. From a set of retrieved components Any one component selected by the user Second component selection means Accepts The query generation means generates a query from the two selected components and the specified relationship. . Raw Constituents included in the generated query When the component is selected by the user, the query editing means accepts editing of the selected component by the user . Therefore, an inquiry can be created without being conscious of the structure of the document type. At that time, for the same component appearing at a plurality of positions, an inquiry can be created with one condition instruction by widely specifying the relationship.
[0024]
In the second invention, in a database management system for managing structured documents having a logical structure that is hierarchized in a tree structure, a document type that is a syntax rule that defines a logical structure that the document can take is specified. Document type holding means to hold, component extraction means for extracting all components of the document type from the document type holding means, and a set of components extracted by the component extraction means And the user selected from the displayed set of components Any two components of the user Accept by input operation Component selection means, and the component selection means Accepted A relationship search means for searching all of the relationships existing between the two components from the document type held in the document type holding means, and a set of relationships searched by the relationship search means And the user selected from the displayed relationships Relationship of user Accepted by input operation Relationship selection means and the component selection means Accepted Two components and the relation selection means Accepted Query generation means for generating a query from the relationship, and components included in the query generated by the query generation means When the user selects the displayed component In Of the selected component A user by Edit Accept A query editing unit; a set of component elements extracted by the component element extracting unit; a set of relationships searched by the relationship search unit; and a display unit for displaying the query generated by the query generation unit. There is provided a database management system characterized by comprising.
[0025]
According to such a database management system, when a query for document search is created, first, all the components of the document type are extracted from the document type holding unit by the component extracting unit, and the extracted components are displayed. Display on means. From a set of extracted components The user selects any two components and Component selection means Accepted Then, all relationships that can exist between the two selected components are searched from the document type by the relationship search means, and the search results are displayed on the display means. From the retrieved relationship Any one relationship selected by the user Relationship selection means Accepted Then, the query generation means generates a query from the two selected components and the selected relationship. . Raw Constituents included in the generated query When the component is selected by the user, the query editing means accepts editing of the selected component by the user . Therefore, an inquiry can be created without being conscious of the structure of the document type. At that time, for the same component appearing at a plurality of positions, an inquiry can be created with one condition instruction by widely specifying the relationship.
[0026]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram showing a principle configuration and an embodiment of a database management system according to the first invention.
[0027]
A database management system according to a first aspect of the present invention includes a document
[0028]
In the database management system configured as described above, the document
[0029]
Here, the data structure for holding the document type may be in any format as long as it can reach any upper and lower constituent elements from one constituent element. In the present embodiment, the data structure has a format in which components and generation rules are objects and objects are linked by pointers. Note that a component having the same name, such as “heading” or “paragraph”, may appear a plurality of times at a plurality of positions in one document type. In such a case, there is only one object corresponding to each of “heading” and “paragraph”, and the object has a plurality of pointers to upper components.
[0030]
The
[0031]
The
[0032]
The
[0033]
Next, in the database management system according to the first aspect of the invention, the procedure for creating an inquiry will be described.
FIG. 2 is a flowchart showing a procedure for creating a query according to the embodiment of the first invention.
[0034]
When an inquiry is created, a document type name to be searched is first specified. When the database management apparatus accepts an instruction for creating a query and designation of a document type name, the
[0035]
One arbitrary component is selected from the displayed component list by the
[0036]
In the present embodiment, the basic condition described above is considered as a basic condition for creating a query, but a query itself can be created from only one component. When searching for documents using queries with fewer conditions, the number of resulting documents or their components only increases.
[0037]
Next, it is determined whether or not the generated inquiry is completed (step S5). If completed, the process of this flowchart ends. If the inquiry is incomplete, the process of this flowchart continues.
[0038]
If the inquiry is incomplete, the cause is determined (step S6). If the basic conditions are not yet met, the process proceeds to step S7, where basic processing is performed. In the present embodiment, the creation of a query is considered based on basic conditions, but components that serve as conditions may be added as necessary. If the basic conditions have already been determined and another component is added to the inquiry, the process proceeds to step S3 again. This process will be described in detail later. Furthermore, when detailed conditions are given to the components already included in the inquiry, the process proceeds to step S12 and editing processing is performed. This process will also be described later.
[0039]
If the basic condition still has only the first component, the
[0040]
As a result of the search by the
[0041]
The constituent
[0042]
Here, a process when the addition of a component is selected in the branch of step S6 will be described. Even when a component is added to an inquiry, the two components and their relationship are the basic units. Proceeding to step S3, components are added in the same procedure as selecting the basic condition. That is, the first component, the second component, and the relationship between the first component and the second component may be aligned.
[0043]
However, when a component is added, from the component list Only But already Generated in step S4 Inquiry conditions and Displayed in a tree structure Any one of the constituent elements may be selected as the first constituent element. When this process is repeated, a tree structure having an arbitrary size becomes a query condition.
[0044]
Next, processing when editing of a component is selected in the branch of step S6 will be described. When detailed conditions are given to the components already included in the inquiry, first, the target components are selected (step S12). Thereafter, the conditions to be added are input, and the inquiry is edited (step S13).
[0045]
Next, step S in FIG. 8 The component search process described in the above item will be described.
FIG. 3 is a flowchart showing the procedure of the component search process.
First, the component
[0046]
Next, the
[0047]
Here, an inquiry creation procedure in the embodiment of the database management system according to the first aspect of the invention will be described with reference to an example of an inquiry creation screen.
FIG. 4 is a diagram showing an example of an inquiry creation screen based on the embodiment of the first invention.
[0048]
The
[0049]
The
[0050]
Here, it is assumed that a query for searching for a document based on the document type “report” shown in FIG. 21 is created, and the display and use of the query creation screen will be described in order.
[0051]
Note that the query condition to be created is a search for a chapter including the character string “database” in the chapter heading and the character string “structure” in any paragraph in the chapter shown in FIG. And take it out. "
[0052]
Although an inquiry is created according to the flowchart of FIG. 2, first, description will be made up to step S7 in which the relationship between the first component and the second component is designated.
[0053]
FIG. 5 is a diagram showing an inquiry creation screen when a relationship between two components is designated in the embodiment of the first invention.
The document type name “report” is input (step S1), and “chapter” is selected as the first component by a pointing device or the like from the components (step S2) listed on the
[0054]
As a result of selecting “chapter” as the first constituent element, the constituent
[0055]
The
[0056]
As described above, when the document type to be searched is designated, the
[0057]
Next, description will be made up to step S10 in which candidates for the second component are displayed. FIG. 6 is a diagram showing an inquiry creation screen when a search result is displayed according to the embodiment of the first invention.
[0058]
The
[0059]
In this way, when the relationship between the first component and the second component is designated, the
[0060]
Next, description will be made up to step S11 in which the second component is selected.
FIG. 7 is a diagram showing an inquiry creation screen when the second component is selected in the embodiment of the first invention.
[0061]
From the components displayed on the search
[0062]
When the creation of the query is completed, the query becomes a query for searching for “component“ chapter ”including“ headline ”as a“ child ”.
[0063]
Next, description will be made up to step S13 in which conditions are added to the constituent elements included in the inquiry.
FIG. 8 is a diagram showing an inquiry creation screen when a component to be edited is selected in the embodiment of the first invention.
[0064]
The component “heading” is selected as an editing target from the
[0065]
In the
[0066]
In the activated
FIG. 9 is a diagram showing an inquiry creation screen when a condition is added to a component in the embodiment of the first invention.
[0067]
Since the character string “database” is a condition relating to the component “headline”, the
[0068]
Next, the case where a component is added by determination of step S6 is demonstrated.
FIG. 10 shows an embodiment of the first invention. State It is a figure which shows the inquiry creation screen when a component is added.
[0069]
The component “chapter” is selected as a first component from the
[0070]
Since the relationship between the component “chapter” and the component “paragraph” is an grandchild relationship (a relationship between an ancestor and a descendant), the two components are connected by a dotted line indicating the grandchild relationship.
When the creation of the query ends here, this query has a “heading” component with the string “database” in the child and a “chapter” component in the “paragraph” descendant. It becomes an inquiry to search.
[0071]
Next, description will be made up to step S13 in which the added component is edited.
FIG. 11 is a diagram showing an inquiry creation screen when a condition is added to the component added in the embodiment of the first invention.
[0072]
When the component “paragraph” is selected as an object to be edited from the
[0073]
Here, the created query has a “heading” component with the character string “database” as a child, and a “paragraph” component with a character string “structure” as a descendant. This is a query for searching for “component”.
[0074]
In the above description, the editing of the component “heading” is performed before the addition of the component “paragraph”, but the order of this work may be reversed. In addition, as in the case where the component “paragraph” is added, there are as many inquiries as possible. Further, the inquiry creation screen is not limited to the example given here. If the component can be selected and the parent-child relationship and the grand-grandchild relationship between the components can be distinguished, the format corresponding to the usage method may be adopted. In addition, a condition other than a character string can be specified as a condition to be added to the inquiry component. If the document type component has an attribute, it is configured so that the conditions relating to the attribute can also be edited.
[0075]
With such a database management system, when creating a query for searching for a document, the user can create a query without knowing the components of the document type, their appearance order, and the inclusion relationship.
[0076]
Next, a second invention will be described with reference to the drawings.
FIG. 12 is a diagram showing the principle configuration and embodiment of the database management system according to the second invention.
[0077]
The database management system according to the second aspect of the present invention includes a document
[0078]
In the database management system configured as described above, the document
[0079]
Here, the data structure for holding the document type may be in any format as long as it can reach any upper and lower constituent elements from one constituent element. The data structure in the present embodiment is the same as the data structure in the first embodiment.
[0080]
The
[0081]
The
[0082]
The
[0083]
Next, in the database management system according to the second aspect of the invention, the procedure for creating an inquiry will be described.
FIG. 13 is a flowchart showing a procedure for creating a query according to the embodiment of the second invention.
[0084]
When an inquiry is created, a document type name to be searched is first specified. When the database management system receives an inquiry creation instruction and a document type name designation, the
[0085]
From the displayed component list, any one component is selected by the
[0086]
Next, it is determined whether or not the generated inquiry is completed (step S35). If completed, the process of this flowchart ends. If the inquiry is incomplete, the process of this flowchart continues.
[0087]
If the inquiry is incomplete, the cause is determined (step S36). If the basic conditions are not yet met, the process proceeds to step S37 to perform basic processing. When the basic condition has already been determined and another component is added to the inquiry, the process proceeds to step S33 again. This process will be described in detail later. Furthermore, when detailed conditions are given to the components already included in the inquiry, the process proceeds to step S42, and editing processing is performed. This process will also be described later.
[0088]
If only the first component exists in the basic condition, any one component is selected by the
[0089]
As a result of the search by the
[0090]
The
[0091]
Here, a process when the addition of a component is selected in the branch of step S36 will be described. Even when a component is added to an inquiry, the two components and their relationship are the basic units. Proceeding to step S33, components are added in the same procedure as selecting the basic condition. That is, the first component, the second component, and the relationship between the first component and the second component need only be aligned.
[0092]
However, if a component is added, only from the component list Is Not already Generated in step S34 Inquiry conditions and Displayed in a tree structure Any one of the constituent elements may be selected as the first constituent element. When this process is repeated, a tree structure having an arbitrary size becomes a query condition.
[0093]
Next, processing when editing of a component is selected in the branch of step S36 will be described. When a detailed condition is applied to a component that has already been inquired, a target component is first selected (step S42). Thereafter, the conditions to be added are input, and the inquiry is edited (step S43).
[0094]
Next, step S3 in FIG. 8 The processing for searching for a relationship that may exist between the first component and the second component described in the above will be described.
FIG. 14 is a flowchart showing the procedure of the relationship search process.
[0095]
First, the
[0096]
Next, the
[0097]
Subsequently, the
[0098]
Further, the
[0099]
Finally, the
[0100]
Here, an example of a query creation screen in the embodiment of the database management system of the second invention will be described to explain the query creation procedure.
FIG. 15 is a diagram showing an example of an inquiry creation screen based on the embodiment of the second invention.
[0101]
The
The
[0102]
Here, it is assumed that a query for searching for a document based on the document type “report” shown in FIG. 21 is created, and the display and use of the query creation screen will be described in order. The query condition to be created is “retrieve and retrieve a chapter including the character string“ database ”in the heading at an arbitrary position in the chapter” shown in FIG.
[0103]
Although an inquiry is created in accordance with the flowchart of FIG. 13, first, description will be made up to step S37, in which the second component is selected.
FIG. 16 is a diagram showing an inquiry creation screen when two components are selected in the embodiment of the second invention.
[0104]
The document type name “report” is input (step S31), and “chapter” is selected as the first component by a pointing device or the like from the components (step S32) displayed in a list on the component display unit 31 (step S31). Similarly, “heading” is selected as the second component from the components displayed in the component display section 32 (step S37).
[0105]
As a result of selecting “chapter” as the first constituent element, the constituent
[0106]
The
[0107]
As described above, when the document type to be searched is designated, the
[0108]
Next, description will be made up to step S40 in which the relationship existing between the first component and the second component is displayed.
FIG. 17 is a diagram showing an inquiry creation screen when a search result is displayed in the embodiment of the second invention.
[0109]
The
[0110]
In this way, when the first component and the second component are selected, the
[0111]
Next, description will be made up to step S41 in which the relationship between the first component and the second component is selected.
FIG. 18 is a diagram showing an inquiry creation screen when a relationship between two components is selected in the embodiment of the second invention.
[0112]
From the relationship displayed on the
[0113]
When the creation of the query ends here, the query becomes a query for searching for “a component“ chapter ”including a component“ heading ”as a descendant”.
[0114]
Next, description will be made up to step S43 in which conditions are added to the constituent elements included in the inquiry.
FIG. 19 is a diagram showing an inquiry creation screen when a condition is added to a component in the embodiment of the second invention.
[0115]
The component “heading” is selected as an editing target from the
[0116]
This inquiry is an inquiry for searching for a “component“ chapter ”that includes a character string“ database ”in a component“ headline ”at an arbitrary position of“ subordinate to the component “chapter” ”. In the case of “chapter” having a component “heading” as a descendant, in the document type 41 shown in FIG. 21, the component “heading” is a child of the component “chapter” and a great-grandchild. There are two types of cases, but the distinction is not made here.
[0117]
In the above description, an inquiry including only two components has been created. However, as with the first embodiment, the number of inquiry conditions can be increased as much as possible. Furthermore, the inquiry creation screen is not limited to the examples given here, and may be expressed in an easy-to-use manner according to the user's usage method. Other than the character string can be included in the condition of the component included in the inquiry.
[0118]
With such a database management system, when creating a query for searching for a document, the user can create a query without knowing the components of the document type, their appearance order, and the inclusion relationship.
[0119]
【The invention's effect】
As described above, in the present invention, if a document type name to be searched is input, the component extraction means for displaying all the components of the corresponding document type, the first component, and the second component Means for selecting, means for specifying or selecting a relationship between the first component and the second component, and a query generating unit for generating a query from the two components and the relationship between them I made it. As a result, the user can create a query for document search without being aware of the structure of the document type.
[0120]
Further, in the present invention, when displaying a component, it is not necessary to specify information on where the component is located in the document type. Therefore, once for the same component appearing in a plurality of positions, Inquiries for document search can be created with condition instructions.
[Brief description of the drawings]
FIG. 1 is a diagram showing a principle configuration and an embodiment of a database management system according to a first invention.
FIG. 2 is a flowchart showing a procedure for creating a query in the embodiment of the first invention;
FIG. 3 is a flowchart showing a procedure of a component element search process.
FIG. 4 is a diagram showing an example of an inquiry creation screen based on the embodiment of the first invention.
FIG. 5 is a diagram showing an inquiry creation screen when a relationship between two components is specified in the embodiment of the first invention.
FIG. 6 is a diagram showing an inquiry creation screen when search results are displayed according to the embodiment of the first invention.
FIG. 7 is a diagram showing an inquiry creation screen when a second component is selected in the embodiment of the first invention.
FIG. 8 is a diagram showing an inquiry creation screen when a component to be edited is selected in the embodiment of the first invention.
FIG. 9 is a diagram showing an inquiry creation screen when a condition is added to a component in the embodiment of the first invention.
FIG. 10 is a diagram showing an inquiry creation screen when a component is added in the embodiment of the first invention.
FIG. 11 is a diagram showing an inquiry creation screen when a condition is added to the component added in the embodiment of the first invention.
FIG. 12 is a diagram showing a principle configuration and an embodiment of a database management system according to a second invention.
FIG. 13 is a flowchart showing a procedure for creating a query according to the embodiment of the second invention;
FIG. 14 is a flowchart showing a procedure of a relationship search process.
FIG. 15 is a diagram showing an example of an inquiry creation screen based on the embodiment of the second invention.
FIG. 16 is a diagram showing an inquiry creation screen when two components are selected in the embodiment of the second invention.
FIG. 17 is a diagram showing an inquiry creation screen when a search result is displayed in the embodiment of the second invention.
FIG. 18 is a diagram showing an inquiry creation screen when a relationship between two components is selected in the embodiment of the second invention.
FIG. 19 is a diagram showing an inquiry creation screen when a condition is added to a component in the embodiment of the second invention.
FIG. 20 is a diagram illustrating an example of a structured document expressed in a tree structure.
FIG. 21 is a diagram illustrating an example of a document type.
FIG. 22 is a diagram schematically showing an example of an inquiry having a condition regarding a document context.
FIG. 23 is a diagram showing an example of a display screen of a conventional inquiry editor.
[Explanation of symbols]
1 Document type holding part
2 Component extraction section
3 First component selection unit
4 Relationship designator
5 Component search part
6 Second component selection unit
7 Inquiry generator
8 Inquiry Editing Department
9 Display section
Claims (6)
文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持手段と、
前記文書タイプ保持手段から文書タイプのすべての構成要素を取り出す構成要素取出手段と、
前記構成要素取出手段にて取り出された構成要素の第1の集合を表示し、表示した前記第1の集合の中からユーザが選択した任意の一つの構成要素をユーザの入力操作によって受け付ける第1の構成要素選択手段と、
前記第1の構成要素選択手段が受け付けた第1の構成要素とユーザが次に選択しようとする構成要素との間のユーザが指定した関係をユーザの入力操作によって受け付ける関係指定手段と、
前記第1の構成要素選択手段が受け付けた第1の構成要素から見て前記関係指定手段が受け付けた関係を有するすべての構成要素を前記文書タイプ保持手段に保持された文書タイプから検索する構成要素検索手段と、
前記構成要素検索手段により検索された構成要素の第2の集合を表示し、表示した前記第2の集合の中からユーザが選択した任意の一つの第2の構成要素をユーザの入力操作によって受け付ける第2の構成要素選択手段と、
前記第1の構成要素選択手段が受け付けた第1の構成要素、前記関係指定手段が受け付けた関係、および前記第2の構成要素選択手段が受け付けた第2の構成要素から問い合わせを生成する問い合わせ生成手段と、
前記問い合わせ生成手段にて生成された問い合わせに含まれる構成要素を表示し、表示した構成要素をユーザが選択した場合に選択された構成要素のユーザによる編集を受け付ける問い合わせ編集手段と、
前記構成要素取出手段にて取り出された構成要素の第1の集合、ユーザにより指定されるべき構成要素間の関係、前記構成要素検索手段により検索された構成要素の第2の集合、および前記問い合わせ生成手段にて生成された問い合わせを表示する表示手段と、
を備えていることを特徴とするデータベース管理システム。In a database management system that manages structured documents with a logical structure that is hierarchized into a tree structure,
A document type holding means for holding a document type which is a syntax rule that defines a logical structure that a document can take;
Component extraction means for extracting all components of the document type from the document type holding means;
And displaying a first set of components taken out by said component extracting means, the Ru accepted by an input operation of any one component selected by the user from among the first set of displaying user 1 component selection means;
A relationship specifying unit accepting an relationship designated by the user by the input operation of the user between the components first component and the user to which the first component selected unit receives in turn tries to select,
A component for searching all component elements having the relationship accepted by the relationship designating unit from the document type held in the document type holding unit as seen from the first component received by the first component selection unit Search means;
A second set of components searched by the component search means is displayed, and any one second component selected by the user from the displayed second set is received by a user input operation. Second component selection means,
Query generation for generating a query from the first component received by the first component selection unit, the relationship received by the relationship designating unit, and the second component received by the second component selection unit Means,
A query editing means for accepting editing of the inquiry generating means to display the elements included in the generated query by, according to user selected components when the components displayed user selects,
A first set of components extracted by the component extraction means, a relationship between components to be specified by a user , a second set of components searched by the component search means, and the inquiry Display means for displaying the inquiry generated by the generating means;
A database management system characterized by comprising:
文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持手段と、
前記文書タイプ保持手段から文書タイプのすべての構成要素を取り出す構成要素取出手段と、
前記構成要素取出手段にて取り出された構成要素の集合を表示し、表示した構成要素の集合の中からユーザが選択した任意の二つの構成要素をユーザの入力操作によって受け付ける構成要素選択手段と、
前記構成要素選択手段が受け付けた二つの構成要素間に存在する関係のすべてを前記文書タイプ保持手段に保持された文書タイプから検索する関係検索手段と、
前記関係検索手段により検索された関係の集合を表示し、表示された関係の中からユーザが選択した関係をユーザの入力操作によって受け付ける関係選択手段と、
前記構成要素選択手段が受け付けた二つの構成要素および前記関係選択手段が受け付けた関係から問い合わせを生成する問い合わせ生成手段と、
前記問い合わせ生成手段により生成された問い合わせに含まれる構成要素を表示し、表示した構成要素をユーザが選択した場合に選択された構成要素のユーザによる編集を受け 付ける問い合わせ編集手段と、
前記構成要素取出手段にて取り出された構成要素の集合、前記関係検索手段により検索された関係の集合、および前記問い合わせ生成手段により生成された問い合わせを表示する表示手段と、
を備えていることを特徴とするデータベース管理システム。In a database management system that manages structured documents with a logical structure that is hierarchized into a tree structure,
A document type holding means for holding a document type which is a syntax rule that defines a logical structure that a document can take;
Component extraction means for extracting all components of the document type from the document type holding means;
The Display set of components taken in components extraction means, a component selection means any two components selected by the user Ru received by the input operation of the user from the set of the indicated components ,
A relationship search means for searching all of the relationships existing between the two components received by the component selection means from the document type held in the document type holding means;
A relationship selecting means Ru received by the input operation of the user the relationship selected by the user from the displayed set of retrieved relationship display relationships by the relationship retrieval means,
Query generating means for generating a query from the two constituent elements received by the constituent element selecting means and the relation received by the relation selecting means;
A query editing means for displaying the components included in the generated query, add undergone editing by the user of the selected components when the components displayed user selected by the query generation means;
A display means for displaying a set of constituent elements extracted by the constituent element extracting means, a set of relations searched by the relation searching means, and a query generated by the query generating means;
A database management system characterized by comprising:
文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持手段から文書タイプのすべての構成要素を構成要素取出手段が取り出し、
取り出された構成要素の第1の集合を表示手段に表示し、表示した前記第1の集合の中からユーザが選択した任意の一つの第1の構成要素を第1の構成要素選択手段が受け付けし、
前記第1の構成要素選択手段が受け付けた第1の構成要素とユーザが次に選択しようとする構成要素との間のユーザが指定した関係を関係指定手段がユーザの入力操作によって受け付けし、
前記第1の構成要素選択手段が受け付けた第1の構成要素に対して前記関係指定手段が受け付けた関係を有するすべての構成要素を構成要素検索手段が前記文書タイプ保持手段に保持された前記文書タイプから検索し、
検索された構成要素の第2の集合を表示手段に表示し、表示した前記第2の集合の中からユーザが選択した任意の一つの第2の構成要素を第2の構成要素選択手段がユーザの入力操作によって受け付けし、
問い合わせ生成手段が前記第1の構成要素、前記関係、および前記第2の構成要素から問い合わせを生成し、
前記問い合わせ生成手段にて生成された問い合わせに含まれる構成要素を表示手段に表示し、表示した構成要素をユーザが選択した場合に問い合わせ編集手段がユーザによる選択された構成要素の編集を受け付ける、
ことを特徴とするデータベース管理システムの問い合わせ作成方法。In the query creation method of the database management system for managing structured documents having a logical structure layered in a tree structure,
The component extraction means extracts all the components of the document type from the document type holding means that holds the document type, which is a syntax rule that defines the logical structure that the document can take,
The first set of extracted components is displayed on the display means, and the first component selection means accepts any one first component selected by the user from the displayed first set. And
Relationship specifying means the relationship specified by the user between a component first component and the user to which the first component selected unit receives in turn tries to select is accepted by the input operation of the user,
The document in which the component search unit holds all the components having the relationship received by the relationship specifying unit with respect to the first component received by the first component selection unit. Search by type,
The second set of searched components is displayed on the display means, and the second component selecting means selects any one second component selected by the user from the displayed second set. Is accepted by the input operation of
Query generation means said first component, before Symbol relationship, and generates a query from the second component,
Displaying the component included in the query generated by the query generating unit on the display unit, and when the user selects the displayed component, the query editing unit accepts editing of the selected component by the user ;
A method for creating a query of a database management system characterized by the above.
文書の取り得る論理構造を規定した構文規則である文書タイプを保持する文書タイプ保持手段から文書タイプのすべての構成要素を構成要素取出手段が取り出し、
取り出された構成要素の集合を表示手段に表示し、表示した構成要素の集合の中からユーザが選択した任意の二つの構成要素を構成要素選択手段がユーザの入力操作によって受け付けし、
前記構成要素選択手段が受け付けた二つの構成要素間に存在する関係のすべてを関係検索手段が前記文書タイプ保持手段に保持された前記文書タイプから検索し、
検索された関係の集合を表示手段に表示し、表示した前記集合の中からユーザが選択した所望の関係を関係選択手段がユーザの入力操作によって受け付けし、
問い合わせ生成手段が、選択された二つの構成要素および関係から問い合わせを生成し、
前記問い合わせ生成手段にて生成された問い合わせに含まれる構成要素を表示手段に表示し、表示した構成要素をユーザが選択した場合に問い合わせ編集手段がユーザによる選択された構成要素の編集を受け付ける、
ことを特徴とするデータベース管理システムの問い合わせ作成方法。In the query creation method of the database management system for managing structured documents having a logical structure layered in a tree structure,
The component extraction means extracts all the components of the document type from the document type holding means that holds the document type, which is a syntax rule that defines the logical structure that the document can take,
The set of extracted components is displayed on the display means, and any two components selected by the user from the displayed set of components are received by the component selection means by the user's input operation ,
The relationship search unit searches all the relationships existing between the two components received by the component selection unit from the document type held in the document type holding unit ,
A set of retrieved relationships is displayed on the display means, and the relationship selection means accepts a desired relationship selected by the user from the displayed set by the user's input operation ,
The query generation means generates a query from the two selected components and relationships,
Displaying the component included in the query generated by the query generating unit on the display unit, and when the user selects the displayed component, the query editing unit accepts editing of the selected component by the user ;
A method for creating a query of a database management system characterized by the above.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP17192696A JP3707132B2 (en) | 1996-07-02 | 1996-07-02 | Database management system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP17192696A JP3707132B2 (en) | 1996-07-02 | 1996-07-02 | Database management system |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH1021256A JPH1021256A (en) | 1998-01-23 |
JP3707132B2 true JP3707132B2 (en) | 2005-10-19 |
Family
ID=15932411
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP17192696A Expired - Fee Related JP3707132B2 (en) | 1996-07-02 | 1996-07-02 | Database management system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3707132B2 (en) |
-
1996
- 1996-07-02 JP JP17192696A patent/JP3707132B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH1021256A (en) | 1998-01-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2535093C (en) | Generating end-user presentations from structured data | |
CA2204447C (en) | Document display system and electronic dictionary | |
US8127224B2 (en) | System for creating and editing mark up language forms and documents | |
US20020059297A1 (en) | Search formulation user interface | |
US20080275856A1 (en) | System for viewing and indexing mark up language messages, forms and documents | |
US20080147605A1 (en) | Apparatus and method for creating a customized virtual data source | |
JP2005190163A (en) | Method, apparatus and program for retrieving structured data | |
JP3178421B2 (en) | Text search device and computer-readable recording medium storing text search program | |
US5142678A (en) | Method for a requesting user to use a marker to associate a document with an end user action | |
US6941524B2 (en) | System and method for displaying a recursive relationship between objects in a tree | |
JPH11149484A (en) | Thesaurus retrieval and synthesization system | |
JPH05225185A (en) | Document processor | |
JP3707132B2 (en) | Database management system | |
US11036729B2 (en) | Document creation support system | |
JP3632643B2 (en) | Structured document management device | |
JP3842576B2 (en) | Structured document editing method and structured document editing system | |
JPH05225240A (en) | Document data base device | |
Liu et al. | Towards building logical views of websites | |
JP3824468B2 (en) | Data management system | |
Salampasis et al. | HyperTree: a structural approach to web authoring | |
JPH05135054A (en) | Document processing method | |
JPH08161345A (en) | Information retrieving system | |
JPH0895975A (en) | Preparation method for logically structured document | |
JPH09305619A (en) | Hierarchical index retrieving device and document retrieving method | |
JP4334450B2 (en) | Structured document search apparatus and structured document search method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041214 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050214 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050329 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050525 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050712 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050725 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090812 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100812 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110812 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |