JP3030786B2 - ユーザー拡張の可能なデータベースシステム - Google Patents

Description

【発明の詳細な説明】 発明の背景 1.発明の分野 本発明の方法及び装置はデータベースの編成に関す
る。さらに特定すれば、本発明の方法及び装置は、様々
に異なる型のソースファイルからのデータベースファイ
ルの生成に関する。

2.関連出願 本出願は、1990年３月27日出願（名称「Method and A
pparatus for Searching Database Component Files to
Retrieve Information from Modified Files」）の米
国特許出願No.07/500,141（米国特許第5129082号）に関
連しており、同関連出願は参照によりこの明細書に取入
れらる。

3.技術背景 データベースは、後の探索や検索に備えて所定の方式
で編成され且つ記憶される情報の集合体である。通常、
データは、いくつかのパラメータに従って索引付けされ
且つそれらのパラメータに従って検索可能であるように
編成される。たとえば、データベースは、テキストファ
イル中の語又は語のストリングを迅速に検索できるよう
に、テキストファイル中の語の索引付けするための情報
を含んでいても良い。データベース構造に記憶されるデ
ータはアクセス及び検索に備えて単一のファイルの中で
編成されても良いし、複数のファイルの中で編成されて
も良い。

通常、データベースはそれを生成する元になったソー
スファイルの型に従って編成される。たとえば、本の本
文であるソースファイルに関わるデータファイルはコン
ピュータプログラムのソースコードから取出したデータ
ベースとは異なっているであろう。同様に、データベー
ス探索を目的として開発される走査検索メカニズムはソ
ースファイルの型ごとに違うものとなるであろう。それ
に相応して、ソースファイルの言語に従ってデータベー
スや、データベースを探索するための走査検索メカニズ
ムは異なる。

加えて、新たな演算言語が絶えず現われていることか
ら、言語ごとにデータベースと、走査検索メカニズムと
を提供するのはきわめて困難である。この問題の解決方
法は、ユーザーが汎用データベース及び走査検索メカニ
ズムに対して言語の意味を定義できるように、ユーザー
拡張可能データベース及び走査検索メカニズムを提供す
るというものである。言語の意味を定義したならば、デ
ータベースを作成することができ、探索を実行すること
ができる。

発明の概要 従って、本発明の目的は、多用なソースファイル型及
び言語に対して使用できるようなデータベースシステム
を提供することである。

本発明の目的は、ユーザー拡張可能データベース及び
走査検索（brousing）メカニズムから構成されるデータ
ベースシステムを提供することである。

さらに、本発明の目的は、多用なソースファイル型に
対して同一のデータベース生成メカニズムを使用できる
と共に、生成したデータベースコンポーネントファイル
を探索するために同一の走査検索メカニズムを使用でき
るように、ソースファイルとデータベースシステムとの
間にインタフェースを提供することである。

入力としてソースファイル型、すなわち、言語と、対
応する探索フィルタとの記述を受信し、走査検索メカニ
ズムにより使用されるべき言語ごとのタグセット定義フ
ァイルと、フィルタ定義ファイルとを出力するコンパイ
ラを具備するテキストファイル用データベースシステム
を採用する。タグセット定義ファイルはデータベースビ
ルダメカニズムに入力され、データベースビルダによ
り、入力ソースファイルから情報を選択し、それをデー
タベースコンポーネントファイルへ移動するために使用
される。従って、ソースファイル型の記述を提供するこ
とにより、本発明のデータベースシステムにどのような
型の、どのような言語のソースファイルでも入力して、
後に走査検索メカニズムにより検閲、探索しうるような
データベースコンポーネントファイルを生成することが
できる。

図面の簡単な説明 本発明のデータベースシステムの目的、特徴及び利点
は本発明の以下の説明から明白になるであろう。

図１は、本発明のコンピュータシステムの１例のブロ
ック線図表示である。

図２は、本発明のデータベースシステムの機能ブロッ
ク線図である。

図3a及び図3bは、本発明のデータベースシステムの好
ましい実施例の機能ブロック線図である。

図４は、ソースファイル型記述の１例である。

図5a及び図5bは、フィルタメニューを例示する。

図６は、本発明のデータベースシステムのコンパイラ
メカニズムのフローチャートである。

図７は、ソースファイル型定義についてコンパイラに
より生成されるフィルタファイルを示す。

図8a及び図8bは、ソースファイル型記述「lang1」及
び「lang2」についてコンパイラにより生成されるタグ
セット定義ファイルを示す。

図9aは、本発明のデータベースシステムに入力すべき
ソースファイルを示す。図9bは、データベースビルダの
１例であり、図9cは、図9aのソースファイルについて本
発明のデータベースシステムにより生成されるデータベ
ースコンポーネントファイルを示す。

発明の詳細な説明 表記法及び用語 以下の詳細な説明の大部分は、コンピュータメモリ内
部のデータビットについての演算のアルゴリズム及び記
号表示によって提示される。それらのアルゴリズムによ
る説明や表示は、データ処理技術に熟達する者がその作
業の内容を他の当業者に最も有効に伝達するために使用
する手段である。

ここでは、また、一般にも、アルゴリズムは所望の結
果に至る首尾一貫したステップのシーケンスであると理
解されている。それらのステップは物理的量の物理的操
作を要求するステップである。通常、それらの量は記
憶、転送、組合わせ、比較及びその他の方法による操作
が可能な電気信号又は磁気信号の形態をとるが、必ずそ
うであるとは限らない。時によっては、主に一般に使用
されている用語であるという理由により、それらの信号
をビット、値、要素、記号、文字、項、数などと呼ぶと
好都合であることがわかる。ただし、そのような用語及
びそれに類する用語は、全て、適切な物理的量と関連さ
せるべきものであり、単にそれらの量に便宜上付された
ラベルであるにすぎないということを忘れてはならな
い。

さらに、実行される操作を、一般にはオペレータが実
行する知的動作と関連している加算又は比較などの用語
で呼ぶことが多い。本発明の一部を形成する、ここで説
明の動作のいずれにおいても、そのようなオペレータの
能力は不要であるか、又は多くの場合に望ましくない；
動作は機械の動作である。本発明の動作を実行するのに
有用な機械には、汎用デジタルコンピュータ又は他の同
様の装置がある。あらゆる場合に、コンピュータを動作
させるに際しての動作の方法と、計算それ自体の方法と
の明確な区別に留意すべきである。本発明は、電気信号
又は他の（たとえば、機械的、化学的）物理的信号を処
理して、他の所望の物理的信号を発生させるときにコン
ピュータを動作させるための方法ステップに関する。

また、本発明は、それらの動作を実行するための装置
にも関する。この装置は要求される目的に合わせて特別
に構成されても良いし、あるいは、コンピュータに記憶
させたコンピュータプログラムにより選択的に起動又は
再構成される汎用コンピュータから構成されていても良
い。ここで提示するアルゴリズムは、元来、特定のコン
ピュータ又は他の装置と関連するものではない。詳細に
いえば、様々な汎用機械をここに示す教示に従って書込
んだプログラムと共に使用しても良いし、あるいは、要
求される方法ステップを実行するためには、より特殊化
した装置を構成するほうがより好都合であるとわかるか
もしれない。多用なそれらの機械について要求される構
造は、以下に提示する説明から明白になるであろう。

システム全般の構成 図１は、本発明によるデータベースに関わる典型的な
コンピュータ利用システムを示す。そこに示されている
のは、３つの主要な構成要素から構成されるコンピュー
タ101である。それらの構成要素の中の第１のものは、
適切な構造形態をとる情報をコンピュータ101のその他
の部分との間で通信し合うために使用される入出力（I/
O）回路102である。また、コンピュータ101の一部とし
て、中央処理装置（CPU）103と、メモリ104も示されて
いる。それら後の２つの要素は、多くの汎用コンピュー
タやほぼ全ての専用コンピュータにおいて通常見られる
ものである。実際、コンピュータ101の中に含まれてい
るいくつかの要素はこの広い意味でのデータプロセッサ
を代表することを意図している。コンピュータ101の役
割を果たすのに適するデータプロセッサの特定の例は、
カリフォルニア州マウンテンビューのSun Microsystem
s,Inc.が製造している機械を含む。言うまでもなく、同
様の能力を有する他のコンピュータを以下に説明する機
能を実行するために簡明な方法により適応させることが
できるであろう。

また、図１には入力装置105も示されているが、これ
は典型的な実施例ではキーボードとして示されている。
しかしながら、入力装置は実際にはカード読取り装置、
磁気テープ又は紙テープ読取り装置、もしくは他の周知
の入力装置（当然、別のコンピュータを含む）であって
も良いことを理解すべきである。大容量メモリ装置106
はI/O回路102に結合しており、コンピュータ101の追加
記憶能力を与える。大容量メモリは別のプログラムなど
を含んでいても良く、また、磁気テープ又は紙テープ読
取り装置もしくは他の周知の装置の形態をとっていても
良い。大容量メモリ106内部に保持されているデータを
メモリ104の一部としてコンピュータ101に標準方式で適
宜取入れても良いことは理解されるであろう。

さらに、ユーザーに対しメッセージ又は他の通信を表
示するために使用される表示モニター107が示されてい
る。そのような表示モニターは周知の数種類のCRT表示
装置の中のいずれかの形態をとっていれば良い。カーソ
ル制御装置108は、指令モードを選択すると共に、たと
えば、データベースを照会するためのパラメータなどの
入力データを編集するために使用され、システムに情報
を入力するより都合の良い手段を構造している。

プロセスの説明 本発明のユーザー拡張可能データベースシステムはコ
ンパイラと、データベースビルダとを含む。様々に異な
る型のテキスト形ソースファイルについてデータベース
コンポーネントファイルを形成でき、また、データベー
ス走査検索手段が特定の１つの言語に限定されないよう
に、多用なソースファイル型又は言語（以下、一括して
「言語」と呼ぶ）に対して同一の走査検査メカニズム
（「探索メカニズム」ともいう）を使用できるであろ
う。たとえば、異なるプログラミング言語による多用な
コンピュータプログラムに対して同一のデータベースを
使用することができる。同様に、多用な言語並びに多用
な文体及びフォーマットで書込まれている本又は記事な
どの複数のテキスト資料について、データベースコンポ
ーネントファイルを形成することができる。

そのシステムは図２の機能ブロック線図に示されてい
る。ソースファイル言語の記述200（「ソースファイル
型記述」）をコンパイラ210に入力すると、コンパイラ
はデータベースビルダ230により理解可能であるタグセ
ット定義220を生成する。入力ソースファイルに関わる
データベースコンポーネントファイルを生成するため
に、タグセット定義220を入力ソースファイル240と共に
データベースビルダ230に入力する。データベースビル
ダ230は、記号情報を抽出し且つデータベースコンポー
ネントファイル260に記憶すべき情報をフォーマットす
るときに、タグセット定義を使用し、それを入力ソース
ファイルに適用する。入力ソースファイルに関連する情
報を検索するために、後にデータベースコンポーネント
ファイル260を走査検索メカニズムにより探索すること
ができる。

ソースファイル型記述はソースファイルの言語を定義
する。ソースファイル型記述は、データベースに入力す
べき記号と関連づけることができる意味タグ値のリステ
ィングから構成されている。オプションとして、ソース
ファイル型記述は、ユーザーが探索を実行するときに様
々なフィルタを採用できるようにするソースファイルの
型に特定して適合させたフィルタ記述を含む。

意味タグはソースファイルのテキストの各部分を分類
するための手段を構成すると共に、複数のソースファイ
ル型について同一の走査検索・フィルタリングメカニズ
ムを使用するための手段を構成する。コンパイラはソー
スファイル型記述を使用して、データベースビルダ230
により理解可能なフォーマットでタグセット定義ファイ
ルを生成する。加えて、ソースファイル型記述にフィル
タ記述が含まれている場合には、そのソースファイルの
言語を求めてデータベース中の探索を実行するときにユ
ーザーにフィルタリングのオプションを与えるために走
査検索メカニズムにより参照されるフィルタファイルを
コンパイラはソースファイル型に関わる意味タグに従っ
て生成する。そこで、走査検索メカニズムは生成される
あらゆるデータベースコンポーネントファイルとの間で
互換性をもち、それぞれ特定のソースファイル言語を探
索するための走査検索メカニズムの修正は回避される。
データベースコンポーネントファイルについて探索を実
行するために、記号とフィルタを識別する照会を走査検
索メカニズムに入力する。フィルタは照会の範囲を狭め
且つさらに精密に探索を実行させるための手段を構成す
る。走査検索メカニズムに関する詳細については、前述
した1990年３月27日出願の米国特許出願No.07/500,141
（米国特許第5129082号）を参照。

本発明のデータベースシステムを使用することによっ
て、後に同一の走査検索メカニズムを利用して探索でき
るデータベースコンポーネントファイルを生成するため
に、多用な言語で書込まれたソースファイルをデータベ
ースビルダに入力できるであろう。このことは図3aによ
り示されており、この場合、それぞれ異なる言語で書込
こまれている４つの入力ファイル300,301,302,303をデ
ータベースビルダ315に入力して、データベースコンポ
ーネントファイル320,321,322,323を生成でき、それら
のデータベースコンポーネントファイルは、後に、照会
340を処理して、照会の結果である一致295を生成するた
めに、走査検索メカニズム325により利用される。照会
を実行するのに要する時間の量を少なくするために、そ
れぞれの記号が入っているデータベースコンポーネント
ファイルの索引を提供するためのデータベースに関わる
インデックスファイル345を生成するのが好ましい。走
査検索メカニズムはインデックスファイル345を利用し
て、特定の記号の出現を見出すためにどのデータベース
コンポーネントファイルを探索すべきかを判定する。

この実施例におけるデータベースビルダ315は、あら
ゆる種類の言語に対してデータベースコンポーネントフ
ァイルを生成する単一のメカニズムである。データベー
スビルダはソースファイルを読取り、ソースファイルに
入っている記号を抽出し、所定の基準（たとえば、記号
の型）に従って記号に対応する意味タグを割当て、各記
号と、ソースファイル中でその記号が位置している行の
行番号と、対応する意味タグとを識別するデータベース
コンポーネントファイルを作成するのが好ましい。デー
タベースビルダ315は、ソースファイルから記号を抽出
する別のメカニズムの一部であっても良く、その場合、
データベースビルダ315は提供される抽出記号情報を利
用して、データベースコンポーネントファイルを作成す
る。ソースファイルの言語にかかわらず同一の走査検索
メカニズムを利用する能力は、入力としてソースファイ
ル型ごとのソースファイル記述270,271,272,273を受入
れて、ソースファイル型ごとのタグセット定義ファイル
280,281,282,283を生成するコンパイラ285を介して与え
られる。オプションとして、ソースファイル型記述の中
で異なるソースファイル言語に関わるフィルタを指定す
ることができ、コンパイラは、ユーザーが照会に対して
フィルタリング機能を実行することを走査検索メカニズ
ムに指示できるようにするために走査検索メカニズム32
5が利用するフィルタファイル（ここでは、「ex.」ファ
イルという）290を生成することができる。

別の実施例を図3bに示す。この実施例では、言語ごと
に別個のデータベースビルダ310,311,312,313を設けて
いる。たとえば、ソースファイル「foo.1」300をタグセ
ット定義ファイル280と共にデータベースビルダ310に入
力して、対応するデータベースコンポーネントファイル
を生成する。同様に、ソースファイル「foo.2」301を対
応するタグセット定義ファイル281と共にデータベース
ビルダ311に入力して、データベースコンポーネントフ
ァイル321を生成する。

この実施例は、本発明のデータベース発生器をコンピ
ュータプログラムコンパイラ又はインタプリタなどの言
語特定プロセスに組込む場合に使用できるであろう。コ
ンピュータプログラムコンパイラはソースファイル（す
なわち、コンパイルすべきコンピュータプログラム）を
解析し、後のコンピュータプログラムの実行に備えて目
的コードを生成する。ソースファイル解析中、コンピュ
ータプログラムコンパイラはコンピュータプログラムの
中で使用されるそれぞれの記号と、記号の型を識別す
る。データベースビルダはこの情報を利用して対応する
意味タグを識別すると共に、識別される各記号と、ソー
スファイル中でその記号が位置している行番号と、タグ
セット定義ファイルの中で規定される対応する意味タグ
とから構成されるデータベースコンポーネントファイル
を生成する。

先に簡単に説明したように、ソースファイル記述は記
号に関わる意味タグと、関連するフィルタとを定義し、
それらは全てソースファイル型によって決まる。本発明
のデータベースシステムを介して入力すべきソースファ
イル型ごとに、１つのソースファイル記述が提供され
る。

図４を参照して、理論上の言語「lang1」及び「lang
2」に関するソースファイル型記述を説明する。ファイ
ルはASCIIフォーマットである；しかしながら、本発明
のデータベースシステムはそれには限定されず、別のフ
ォーマットでも実現可能である。言語「lang1」はテキ
ストの１つの行で第１の語と、テキストの１つの行で第
１ではない語であるとそれぞれ定義される２つの意味タ
グ「first−on−line」及び「not−first−on−line」
から構成されている。言語「lang2」も、大文字で表わ
された語と、大文字で表わされない語であるとそれぞれ
定義される２つの意味タグ「capitalized−word」及び
「not−capitalized−word」から構成されている。ファ
イルの始め（行１）には、 version−statement＝'version'＜small integer＞ の形態をとる「バージョン」ステートメントがある。バ
ージョンステートメントは１から32767の範囲の整数バ
ージョン番号を取る。バージョンステートメントがファ
イル中に言語ステートメントの出現に先立って（行１の
バージョンステートメントのように）位置している場
合、指示されたバージョン番号はフィルタを含む.exフ
ァイル及び作成中であるタグセット定義ファイルとを識
別するために使用される。バージョンステートメントが
ファイル中の言語ステートメントの後に（行４のバージ
ョンステートメントのように）位置している場合には、
バージョン番号は特定の言語のバージョンを識別するた
めに使用される。

図４を参照すると、行３は「言語」ステートメントを
含んでいる。言語ステートメントは、 language−statement:＝'language'＜name＞ の形態をとる。

言語ステートメントは１つの引数をとる。引数である
「名前」は以下のステートメントが記述する言語の名前
である。この例では、言語の名前は「lang1」である。
同様に、行24の言語ステートメントについては、言語の
名前は「lang2」である。

行番号６から９は「特性」ステートメントを示す。特
殊ステートメントは記号の特性を宣言し、「タグ」ステ
ートメント（行13から15）に記載されるような意味タグ
と、「フィルタ」ステートメント（行17から20）に記載
されているようなフィルタとを関連づけるために使用さ
れる。各意味タグはそれが定義する特性のリストを有
し、また、各フィルタ項目はそれと一致する特性のリス
トを１つ又は２つ以上有する。フィルタ項目は、そのフ
ィルタ項目が参照する全ての特性を定義する全てのタグ
と一致する。特性ステートメントは、 property−statement:＝'properties'＜prefix＞’｛’
＜property−identifier＞^＊’｝’ の形態をとる。第１の引数のprefix（接頭辞）は特性ス
テートメントを識別する。第２の引数は実際の特性をリ
スティングする。たとえば、lang1の特性は「word」、
「first」及び「not−first」であり、lang2の特性は
「word」、「capitalized」及び「not−capitalized」
である。

行13から15の「タグ」ステートメントは、データベー
スビルダがデータベース中のlang1の記号と関連すると
想定される意味タグのリストを定義する。「タグ」ステ
ートメントは、 tags−statement:＝'tags'＜prefix＞＜size＞’｛’＜
tas＞^＊’｝’ ただし、tag:＝＜tag−identifier＞’＝’ ’（’＜property identifier＞^＊’）’［＜weight
＞］である。引数「prefix（接頭辞）」は、ステートメ
ントを識別するための接頭辞タグステートメントを指示
するために使用される。「size（サイズ）」ステートメ
ントはタグの数を識別し、コンパイラが実行されるたび
に各タグステートメントが同数のタグを発生することを
保証するために使用される。引数「property identifie
r（特性識別子）」は、意味タグを特性ステートメント
の中で識別される特性と関連づけることによりフィルタ
項目を意味タグに一致させるために使用される。たとえ
ば、行13から15のlang1に関わるタグステートメントは
特性「word」及び「first」を有するタグ「first−on−
line」と、特性「word」及び「not−first」を有するタ
グ「not−first−on−line」とを含む。引数「weight
（重み）」は整数値を照会に応答して一致を分類するた
めに使用されるそれぞれのタグと関連づける。重みの小
さい一致は重みの大きい一致の前に提示される。

図４の行17〜20は言語lang1に関するフィルタステー
トメントを示し、行39〜42は言語lang2に関わるフィル
タステートメントを示す。「フィルタ」ステートメント
はフィルタ項目から構成されるフィルタパネルを定義
し、次のような形態をとる； filter−statement:＝'filter'‘｛‘＜filter−item＞
^＊’｝’ filter−item:＝leaf−item l pull−nght−item leaf−item:＝‘”‘＜filter−item−name＞'"'［＜eq
uiv−spec＞］’ ＝‘＜prop−lists＞ prop−lists:＝‘（‘’＜property＞^＊’）’［‘｜
‘‘（‘＜property＞^＊’）’］^＊ pull−right−item:＝‘”‘＜filter−item−name
＞'"'［＜equiv−spec＞］ 'filter'‘｛‘＜filter−item＞^＊’｝’ equiv−spec:＝‘equiv‘＜language＞‘”‘＜filter
−item−name＞'"' フィルタ項目を作成するときには、そのフィルタ項目
と共に識別される特性と、全ての意味タグとを使用し
て、フィルタ項目が整合すべき意味タグを形成する。特
定の１つのソース型について指定されるフィルタによっ
て、記号の意味タグに基づいてユーザーは探索の幅を狭
めることができる。フィルタは、図5aに示すようなユー
ザーに対し表示されるメニューパネルを介して実現され
るのが好ましい。オプションとして、探索の幅を狭める
ために使用することができる追加フィルタ項目を含むよ
うにフィルタパネルを拡張しても良い。図5bは、フィル
タ項目「宣言」の選択後に拡張したフィルタパネルを示
す。

フィルタパネルはフィルタ項目のリストから構成され
ている。各フィルタ項目は、フィルタが整合すべき意味
タグのリストを定義する。これはフィルタ項目と意味タ
グの特性リスト（「prop−lists」）から作成される。
各フィルタ項目は「葉（leaf）」項目又は「プルライト
（pull−right）」項目のいずれかである。葉フィルタ
項目は、走査検索メカニズムが探索を実行するときに一
致であると考えられるために、フィルタ項目が整合すべ
き意味タグを識別するために使用される１つ又は複数の
特性を指定する。

プルライトフィルタ項目は、プルライトメニュー項目
を定義する特定のフィルタ項目を選択したときに表示さ
れる別のフィルタステートメントを指定し、一致のため
のタグのセットをそのプルライトフィルタの第１の葉項
目を受継ぐ。

タグとフィルタ項目との関連は記号の特性に従って確
定される。各意味タグはそれが定義する特性のリストを
有し、各フィルタ項目はそれが整合する特性の１つ又は
複数のリストを有する。１つのフィルタ項目は、そのフ
ィルタ項目が参照するあらゆる特性を定義する全ての意
味タグと一致する。

従って、ユーザーが.exファイルを介して走査検索メ
カニズムにおいて提供されるフィルタ項目から１つのフ
ィルタ項目を選択するときには、照会はそのフィルタ項
目が指定するタグの中の１つをもつ記号に限定される。

行17〜20に示されるフィルタステートメントは３つの
フィルタ項目「全一致（All Matches）」，「第１（Fir
st）」及び「非第１（Not First）」を定義する。第１
のフィルタ項目は特性「語（word）」により定義され
る。第２のフィルタ項目「第１」は、特性「語」及び
「第１」により定義される。第３のフィルタ項目「非第
１」は特性「語」及び「非第１（not−first）」により
定義される。従って、たとえば、言語lang1で書込まれ
たソース入力ファイルにおいて探索を実行して、フィル
タ項目「第１」を選択する場合には、走査検索メカニズ
ムは意味タグfirst−on−lineにより識別される記号を
除く全ての記号を除去する。

行39〜42のフィルタステートメントは行40の言語lang
2に関わるフィルタ項目を定義し、フィルタ項目「全
語」は特性「語」により定義される。加えて、フィルタ
項目「全語」はlang1のフィルタ項目「全一致」と等価
になるようにも設定される。

「equiv」ステートメントによって、異なるソースフ
ァイル型の間でフィルタを共用することができる。equi
vステートメントは、 equiv−spec:＝‘equiv'＜language＞‘”‘＜filter−
item−name＞‘"' の形態をとる。このステートメントは、現在フィルタ項
目が指定のフィルタ項目と等価であることを指示するた
めに使用される。従って、フィルタを表示するために、
走査検索メカニズムは単に指定されたフィルタ項目に対
応するフィルタを利用するだけである。フィルタ項目を
等価化したときには、走査検索メカニズムは言語ごとの
一致する意味タグのセットを見失わないようにしなけれ
ばならない。これを実行するために、コンパイラが生成
するファイルである.exファイルはフィルタ項目ごとに
ベクトル＜言語id、フィルタ項目名、タグ−ベクトル＞
トリプルを含む。そこで、データベースコンポーネント
ファイルはそれが生成された言語の名前を含むことにな
るので、走査検索メカニズムはソースファイルの言語に
ついて正しいタグフィルタを使用することができる。

従って、フィルタ項目「全語」はlang1の「全一致」
に関わるフィルタを利用する。走査検索メカニズムは、
「全一致」又は「全語」を求めて照会を実行するとき、
他方のフィルタ項目に関しても照会を実行する。

図６を参照して、コンパイラのプロセスの流れを説明
する。ブロック500で、コンパイラは特定のソースファ
イル型に関わるソースファイル記述からバージョン番号
のソース型記述に関する汎用情報を収集する。

ブロック510では、ソースファイル型記述に関わる言
語の名前を識別するために、ソースファイル型記述から
言語ステートメントを収集する。ブロック520で、ステ
ートメントの型、たとえば、特性ステートメント、タグ
ステートメント又はフィルタステートメントを確定する
ために各ステートメントを検査する。ステートメント型
が特性ステートメントである場合、ブロック530で、ソ
ースファイル型記述からステートメント中の対応する特
性情報を収集する。ステートメント型がタグステートメ
ントである場合には、ブロック540で、タグ情報を収集
する。同様に、ステートメントがフィルタステートメン
トである場合には、ブロック550でフィルタ情報を収集
する。

特性情報、タグ情報及びフィルタ情報を収集した後、
ブロック560で別の言語ステートメントが見出されたな
らば、プロセスは別のソースファイル型について継続し
てゆく（図４に示す通り、単一のファイルの中に２つ以
上のソースファイル型記述が含まれていることもあ
る）。次のステートメントが言語ステートメントではな
い場合には、ステートメントは特性ステートメント、タ
グステートメント又はフィルタステートメントでなけれ
ばならず、処理はブロック565を経てブロック520へと続
いてゆく。ブロック565でファイルの終わりに達してい
れば、ブロック570でフィルタステートメントにより定
義されるフィルタを作成し、ブロック580でそれらをフ
ィルタファイル（.exファイル）に書込む。ブロック590
では、ソースファイル型記述ごとに１つのタグセット定
義ファイルを書込む。

図４のソースファイル型記述により定義される言語la
ng1に関して生成された.exファイルを図７に示す。.ex
ファイルの始めには、ファイルを形成しているセクショ
ンのリスティングと場所を含む見出しセクション700が
ある。言語セクション710は定義された言語を識別す
る。重みセクション715,720はそのような言語に関わる
意味タグの重みを指定する。この例のように、重みはタ
グセクション740及び750で識別されるのが好ましい。フ
ィルタセクション730は６つのフィルタ項目「全一
致」、「全語」、「第１」、「非第１」、「大文字使
用」及び「大文字不使用」を指定する。各フィルタ項目
はフィルタが適用される言語と、フィルタ項目の名前
と、フィルタ項目が一致する意味タグとを識別する。フ
ィルタ項目の「全一致」と「全語」は等価であると指定
されている。このことはセクション35で.exファイルに
反映されており、そこでは、それら２つのフィルタ項目
はフィルタメニューにおける同一の項目であるとして指
定される。図示されてはいないが、ソースファイル型記
述でプルライトフィルタ項目が指定されていたならば、
フィルタセクションは、プルライトフィルタを有するフ
ィルタ項目の「プルライトオフセット」パラメータを、
プルライトフィルタ項目が選択されたときに利用できる
フィルタ項目が入っているファイルの中のオフセットを
識別する値に設定することにより、このことを表わすで
あろう。

タグセクション740及び750はそれぞれの意味タグと、
その重みとを指定する。意味タグはタグセット定義で識
別され、デバッギング中に使用するために.exファイル
の中に与えられているので、このセクションは.exファ
イルではオプションのセクションである。各意味タグは
その名前と、値（意味タグ番号ともいう）と、重みとに
より識別される。最終セクションであるリリースセクシ
ョン760は走査検索メカニズムのリリースバージョンを
識別する。

タグセット定義は言語に関わる各意味タグを識別す
る。言語lang1及びlang2について図４のソースファイル
型記述から生成した結果のタグセット定義ファイルを図
8a及び図8bに示す。各ファイルは、記号と関連づけるこ
とができる言語に関わるあらゆる意味タグをリストアッ
プする「enum」宣言（enum宣言はＣプログラミング言語
の定数を宣言するために使用される）を含む。ここでは
タグセット定義はＣプログラミング言語で書込まれたフ
ァイルとして表わされているが、タグセット定義ファイ
ルはそのようなものには限定されず、単純な意味タグの
リストを含む多用なフォーマットで実現できる。

詳細にいえば、図8aを参照すると、enum宣言はlang1
に関わる意味タグ「first−on−line」及び「not−firs
t−on−linne」を識別する。意味タグは＜prefix＞”
−”＜language name＞”−”＜semantic tag name＞”
＝”＜semantic tag number＞に従って指定される。
尚、タグの総数ソースファイル型定義（図４）のタグス
テートメントにより指定されるタグの最大数である４と
するために、enum宣言に２つの疑似タグ「lang1−fil
l」及び「lang1−fill」を挿入することに注意すべきで
ある。加えて、宣言は、その宣言の始まりと終わりを規
定するために使用される２つの追加タグcd−lang1−tag
s−first−member及びcb−lang1−last−memberを含
む。

同様に、図8bを参照すると、enum宣言はlang2に関わ
る意味タグ「capitalized−word」及び「not−capitali
zed−word」並びに意味タグの数を最大タグサイズとす
るための２つの疑似タグを識別する。

コンパイラにより生成されたタグセット定義ファイル
はデータベースビルダに入力されて、入力ソースファイ
ルに関わるデータベースコンポーネントファイルを生成
する。図9aは、言語lang1で書込まれた入力ソースファ
イルのサンプルを示し、それは単に意味タグ「cb−lang
1−first−line」及び「cb−lang1−not−first−on−l
ine」を有する英文テキストである。図9bは、Ｃプログ
ラミング言語で書込まれた言語lang1に関わるデータベ
ースビルダの１例である。データベースビルダは入力ソ
ースファイルに含まれているそれぞれの記号（この例で
は、各語が１つの記号である）を検査し、その記号がテ
キストの１つの行における第１の記号であるか否かを判
定する。記号がテキストの１つの行における第１の記号
であれば、データベースビルダは記号に意味タグcb−la
ng1−first−on−lineを割当て、照会を実行するための
走査検索メカニズムによる後のアクセスに備えてこの情
報をデータベースコンポーネントファイルに導入する。
同様に、記号がソース入力ファイル中のテキストの１つ
の行における第１の記号ではない場所には、データベー
スビルダは記号に意味タグcb−lang1−not−first−on
−lineを割当て、この情報をデータベースコンポーネン
トファイルに導入する。

図9cは、図9aのソース入力ファイルに関して生成され
たデータベースコンポーネントファイルを示す。データ
ベースコンポーネントファイルは見出しセクション800
と、ソース名セクション810と、記号テーブルセクショ
ン820と、意味テーブルセクション830と、リリースセク
ション840とを含む。

見出しセクション800はファイルのマジック番号（UNI
Xファイルに共通している）やファイルバージョン番号
などの管理情報を含む。文字のケースを無視するデータ
ベースビルダにより生成されたデータベースコンポーネ
ントファイルにおいてフィールドケースをセットすべき
である。言語フィールドは本実施例では言語、lang1を
照会するときに正しいフィルタ項目を選択するために使
用されるストリングを含む。ファイルがトップレベルソ
ース又は組込みファイルであるかどうかをソース型フィ
ールドが示す。見出しの残る部分は、全てのセクション
の型、大きさ及び場所が記載されているファイルの内容
のテーブルである。

ソース名セクション810は、データベースコンポーネ
ントファイルを作成する元になったソースファイルに至
る絶対経路を含む。また、ファイルの経路が相対であっ
た場合に１の値にセットされるビットも含む。これはフ
ァイル名を描出するときにソースブラウザにより使用さ
れる。

記号テーブルセクション820は、このデータベースコ
ンポーネントファイルに記述されている全ての記号の無
順位リストである。それぞれの記号は、意味テーブルセ
クション830に示されている意味レコードのベクトルに
対応するファイル相対ポインタを担う。

意味テーブルセクション830は、記号テーブルセクシ
ョンに記載されている記号ごとに＜行番号及び意味タグ
＞対のベクトルを含む。各タグの数値とストリング値の
双方を表示する。ベクトルは記号テーブル中の記号と同
じ順序で現われる。各ベクトルはベクトルレコードの終
わり「エンドレコード」によって終わる。たとえば、図
9aに示すように、記号「ourselves」はソース入力ファ
イルの行４（図9a）の第１の語であるので、記号「ours
elves」に関わる行1060で識別されるベクトルは意味タ
ブcb−lang1−first−on−lineを割当てられる。行番号
1084の図9cに記載されたベクトルは、記号「the」に関
わるベクトルである。１回の出現を除くあらゆる場合に
ついて、ソース入力ファイルでは行５で現われる行1104
で識別される記号、記号「the」は意味タグcb−lang1−
not−first−on−lineを有するものとして識別される。

最終セクションであるリリースセクション840はデー
タベースシステムのリリースバージョンと日付を識別す
る。

本発明を好ましい実施例に関連して説明したが、以上
の説明に照らして数多くの代替構成、変形、変更及び利
用が当業者には明白になるであろうということは明らか
である。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ Ｇ０６Ｆ 9/44 ３２２Ｚ (72)発明者 グラムリッチ，ウェイン・シィ アメリカ合衆国 94086 カリフォルニ ア州・サニーヴェイル・ヘンリエッタ アヴェニュ・726 (56)参考文献 ・Ｂａｄｇｅｔｔ，Ｔｏｍ，”Ｓｅａ ｒｃｈｉｎｇ ｔｈｒｏｕｇｈ ｆｉｌ ｅｓ ｗｉｔｈ ｄａｔａｂａｓｅ ｓ ｏｆｔｗａｒｅ”ＰＣ Ｍａｇａｚｉｎ ｅ，Ｖｏｌ．６，Ｎｏ．18，ｐ．175 （10ｐａｇｅｓ），Ｏｃｔ 27，1987 ・三木「パソコン用文字列検索プログ ラム『ＫＥＮＳＡＫＵ』」同志社大学理 工学研究報告，Ｖｏｌ．30，Ｎｏ．４, ｐ．310−317，1990（平２−２−28) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 17/30 G06F 12/00 G06F 9/44 ＪＩＣＳＴファイル（ＪＯＩＳ)

Claims (3)

(57)【特許請求の範囲】
1. 【請求項１】CPUと、入出力手段と、テキストを含む少
   なくとも１つのソースファイルから構成されるファイル
   システムが入るメモリとを具備するコンピュータシステ
   ムで、 様々に異なるソースファイル型のソースファイルをデー
   タベースシステムに入力できると共に、同一の走査検索
   メカニズムを使用して入力されたソースファイルについ
   て照会を実行することができるようなユーザー拡張可能
   なデータベースシステムにおいて、 （ａ）データベースシステムに入力すべきソースファイ
   ルの言語を定義するソースファイル型定義であって、 言語の特性を識別する特性ステートメントと、 少なくとも１つの特性に従って定義される言語の意味タ
   グを識別するタグステートメントと、 少なくとも１つの特性に従って定義される言語に関わる
   少なくとも１つのフィルタ項目を識別するフィルタステ
   ートメントと を有しているソースファイル型定義と； （ｂ）ソースファイル型定義をコンパイルして、フィル
   タ記述とタグセット定義とを生成するコンパイラ手段で
   あって、 前記タグセット定義には、言語に関わる各意味タグのリ
   スティングが含まれ、 前記フィルタ記述には、言語に関わるフィルタ項目のリ
   スティングが含まれ、各フィルタ項目には、フィルタ名
   と、そのフィルタが使用されている言語と、ソースファ
   イル型定義中のタグステートメント及びフィルタステー
   トメントにより指定される特性に従って確定される少な
   くとも１つの意味タグとが含まれている、 コンパイラ手段と； （ｃ）ソースファイルと、ソースファイル型に関わるタ
   グセット定義とを入力として受信し、特定のソースファ
   イル型をもつソースファイルについてデータベースコン
   ポーネントファイルを生成するデータベースビルダ手段
   であって、 入力されたソースファイル中の各記号を識別する手段
   と、 識別される記号ごとに、タグセット定義ファイル中に記
   載されている意味タグを識別する手段と、 記号と、入力されたソースファイル中でその記号が現わ
   れる行番号と、入力されたソースファイル中の記号出現
   ごとの意味タグとをデータベースコンポーネントファイ
   ルに記憶する手段と を有するデータベースビルダ手段と； （ｄ）探索すべき記号と、フィルタ項目とを識別する照
   会に応答して、少なくとも１つのデータベースコンポー
   ネントファイルから成るデータベースを探索して、記号
   を見出すデータベース走査検索手段であって、 照会により識別された記号が現われるたびにそれを求め
   てデータベースコンポーネントファイルを探索する手段
   と、 記号が現われるごとにその記号の意味タグを照会により
   識別されたフィルタ項目に関して指定された意味タグと
   比較する手段と、 照会の結果として、照会により識別されたフィルタ項目
   の意味タグの中の１つと一致する意味タグを有する照会
   により識別された記号の出現を生成する手段と を有するデータベース走査検索手段と、 を具備し、ソースファイル型定義を提供することによ
   り、様々な異なる型のソースファイルをデータベースシ
   ステムに入力することができ、同一のデータベース走査
   検索手段を使用して、ソースファイル型にかかわらず照
   会を実行するようなデータベースシステム。
2. 【請求項２】ソースファイルの言語ごとに１つずつのデ
   ータベースビルダ手段があって、複数のデータベースビ
   ルダ手段を具備している、請求項１記載のデータベース
   システム。
3. 【請求項３】CPUと、入出力手段と、テキストを含む少
   なくとも１つのソースファイルから構成されるファイル
   システムが入るメモリとを具備するコンピュータシステ
   ムで、 様々に異なるソースファイル型のソースファイルからデ
   ータベースを生成すると共に、同一の走査検索メカニズ
   ムを使用してソースファイルに対する照会を実行するユ
   ーザー拡張可能方法において、 （ａ）言語の特性を識別する特性ステートメントを生成
   し、 少なくとも１つの特性に従って定義される言語の意味タ
   グを識別するタグステートメントを生成し、 少なくとも１つの特性に従って定義される言語に関わる
   少なくとも１つのフィルタ項目を識別するフィルタステ
   ートメントを生成して、 データベースシステムに入力すべきソースファイルの言
   語を定義するソースファイル定義を作成する過程と； （ｂ）ソースファイル型定義をコンパイルして、フィル
   タ記述とタグセット定義とを生成する過程であって、 前記タグセット定義には、言語に関わる各意味タグのリ
   スティングが含まれ、 前記フィルタ記述には、言語に関わるフィルタ項目のリ
   スティングが含まれ、各フィルタ項目には、フィルタ名
   と、そのフィルタが使用されている言語と、ソースファ
   イル型定義中のタグステートメント及びフィルタステー
   トメントにより指定される特性に従って確定される少な
   くとも１つの意味タグとが含まれている、 フィルタ記述とタグセット定義とを生成する過程と； （ｃ）入力として、ソースファイルと、ソースファイル
   型に関わるタグセット定義とを受信し、 入力されたソースファイル中の各記号を識別し、 記号ごとに、タグセット定義ファイル中で定義されてい
   る意味タグの中の１つである意味タグを識別し、 記号と、入力されたソースファイル中でその記号が現わ
   れる行番号と、入力されたソースファイル中で記号が出
   現するごとの意味タグと、をデータベースコンポーネン
   トファイルに記憶して、 特定のソースファイル型のソースファイルに関わるデー
   タベースコンポーネントファイルを作成する過程と； （ｄ）照会により識別された記号が現われるたびにそれ
   を求めてデータベースコンポーネントファイルを探索
   し、 記号が現われるたびにその意味タグを照会により識別さ
   れたフィルタ項目について指定された意味タグと比較
   し、 照会の結果として、照会により識別されたフィルタ項目
   の意味タグと一致する意味タグを有する照会により識別
   された記号の出現を生成して、 探索すべき記号と、フィルタ項目とを識別する照会に応
   答して少なくとも１つのデータベースコンポーネントフ
   ァイルから構成されるデータベースを探索して、記号を
   見出す過程と を具備し、 ソースファイル型定義を提供することにより、様々に異
   なる型のソースファイルを入力できると共に、ソースフ
   ァイル型にかかわらず照会を実行することができる方
   法。