JPS6347826A - Managing method for data base - Google Patents

Managing method for data base

Info

Publication number
JPS6347826A
JPS6347826A JP61191618A JP19161886A JPS6347826A JP S6347826 A JPS6347826 A JP S6347826A JP 61191618 A JP61191618 A JP 61191618A JP 19161886 A JP19161886 A JP 19161886A JP S6347826 A JPS6347826 A JP S6347826A
Authority
JP
Japan
Prior art keywords
attribute
search
value
keyword
information
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.)
Pending
Application number
JP61191618A
Other languages
Japanese (ja)
Inventor
Hiroshi Kato
洋 加藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujifilm Business Innovation Corp
Original Assignee
Fuji Xerox Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fuji Xerox Co Ltd filed Critical Fuji Xerox Co Ltd
Priority to JP61191618A priority Critical patent/JPS6347826A/en
Publication of JPS6347826A publication Critical patent/JPS6347826A/en
Pending legal-status Critical Current

Links

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

PURPOSE:To enable keyword retrieval as to a data based upon a relational model structure by retrieving a value corresponding to a specified keyword as to respective attributes in an attribute value table and using a sum set of information having the same value as a retrieval result. CONSTITUTION:A sum set of values KW(1), KW(2),... as keywords is constituted in a domain table corresponding to (one or plural) optional attributes, and a keyword specified at the time of the storage of pieces of information Inf(1), Inf(2),... is set as an optional attribute value in the attribute value table 1 by referring the domain table 2(1). When information is retrieved, on the other hand, the value corresponding to the keyword is retrieved as to respective attributes (1)-(3),... in the attribute table 1 and the sum set of information having the same value as to the respective attribute which is obtained from the retrieval result is regarded as the retrieval result corresponding to the keyword.

Description

【発明の詳細な説明】 C産業上の利用分野コ 本発明は、関係モデル構造、詳しくは、属性値テーブル
と、この属性値テーブルの各属性に対してその許容し得
る値の和集合を構成すべきドメインテーブルとを有した
関係モデル構造に基づくデータベースの管理方法に関す
る。
DETAILED DESCRIPTION OF THE INVENTION The invention relates to a relational model structure, specifically an attribute value table and a union of its permissible values for each attribute of this attribute value table. The present invention relates to a database management method based on a relational model structure having a domain table and a domain table.

[従来の技術] 近年の技術革新によって記憶媒体の人容最化がが図られ
、特に追記型の光ディスクを利用した画像ファイルシス
テム等はその傾向が顕著なものとなっている。そこで、
このような大容量の光ディスク等にファイリングされた
情報を検索するにあたって、種々の検索システムが考え
られているが、検索データベースを関係モデル構造に基
づくものとしたシステムはそのデータの吸い易さの点か
ら種々の利点を有する。
[Prior Art] Recent technological innovations have led to the optimization of storage media, and this trend has become particularly noticeable in image file systems using write-once optical discs. Therefore,
Various search systems have been considered for searching information filed on such large-capacity optical discs, etc., but systems whose search database is based on a relational model structure have some disadvantages in terms of ease of data acquisition. It has various advantages from

この関係モデル構造に基づくデータベースは具体的には
例えば第9図に示すようになっている。
Specifically, the database based on this relational model structure is as shown in FIG. 9, for example.

これは、基本的に属性値テーブル1とドメインテーブル
2 (1)、 2 (2)、 2 (3)、・・・・・
・ とを有したものである。屈、性1直テーブル1は、
キー属性とこのキー属性にのみ関数従属する各属性(1
)、(2)、(3)、・・・・・・ が設定され、当該
各局性に対して値(属性値)が指定しくqる構造となっ
ている。また、上記属性値テーブル1における各属性(
1)、(2)、(3)・・・・・・ に対して許容し得
る値の和集合がドメインテーブル2 (1)、 2 (
2)、 2 (3)、・・・・・・ に構成されている
。具体的には、属性(1〉にて許容し得る値[A、B、
C,D、E、F、・・・ ] (和集合)がドメインテ
ーブル2(1)に、属性(2)にて許容し得る値(a、
b、c、d、e、f、 ・ ](和集合)がドメインテ
ーブル2(2)に、属性(3)にて許容し得る値[α、
β、γ、δ、ε。
This basically consists of attribute value table 1 and domain table 2 (1), 2 (2), 2 (3), etc.
・It has the following. Flexible, sexual 1st table 1 is,
A key attribute and each attribute that is functionally dependent only on this key attribute (1
), (2), (3), . . . are set, and the structure is such that a value (attribute value) can be specified for each locality. In addition, each attribute in the above attribute value table 1 (
1), (2), (3)... The union of allowable values for domain table 2 (1), 2 (
2), 2 (3),... Specifically, the allowable values [A, B,
C, D, E, F,... ] (union) is added to domain table 2 (1) with allowable values (a,
b, c, d, e, f, ・ ] (union) is stored in the domain table 2 (2) as an allowable value [α,
β, γ, δ, ε.

ζ、・・・ ] (和集合)がドメインテーブル2(3
)に、・・・・・・ 夫々構成されている。
ζ,... ] (union) is domain table 2 (3
) are composed of...

上記のような関係モデル構造にてデータベースを構築す
る場合、属性値テーブル1の各タツブル(横1行分)に
対して1つの管理ずべき情報(ファイル)を割付け、キ
ー属性に対してそのファイル番号を、各属性(1)、(
2)、(3)、・・・に対して当該ファイルを特定すべ
き8値を指定する。この8値の指定には各ドメインテー
ブルが参照されて上記各属性について許容されている値
が用いられる。
When constructing a database with the relational model structure described above, one piece of information (file) to be managed is assigned to each tupble (one horizontal row) in attribute value table 1, and that file is assigned to the key attribute. number for each attribute (1), (
2), (3), . . . specify 8 values to identify the file. For this 8-value designation, each domain table is referred to and the values allowed for each of the above attributes are used.

例えば、第9図に示すものでは、 ファイル1 属性(1)=A、属性(2)=b、属性(3)=α、・
・・ファイル2 属性(1)=B、属性(2)=d 、属性(3)=β、
・・・ファイル3 属性(1)−A、属性(2)=a、屈性(3)=α、・
・・等のような各ファイルについての値指定によってデ
ータベースが構築される。
For example, in the case shown in Figure 9, file 1 attribute (1) = A, attribute (2) = b, attribute (3) = α, ・
...File 2 Attribute (1) = B, Attribute (2) = d, Attribute (3) = β,
...File 3 Attribute (1) - A, Attribute (2) = a, Tropism (3) = α, ・
A database is constructed by specifying values for each file, such as...

上述したように関係モデル構造となるデータベースの特
徴は“1つの属性に対して1つの値しか取り得ない″こ
とである。
As mentioned above, a feature of a database having a relational model structure is that only one value can be taken for one attribute.

尚、上記属性値テーブル1及び各ドメインテーブル2 
(1)、 2 (2)、 2 (3)、・・・ は、実
際のシステムにおいては磁気ディスク等の補助記憶装置
内に作成されるのが一般的である。
In addition, the above attribute value table 1 and each domain table 2
(1), 2 (2), 2 (3), . . . are generally created in an auxiliary storage device such as a magnetic disk in an actual system.

一方、上記のような関係モデル構造のデータベースを検
索するにあたって、従来最適な方式として「表形式任意
指定検索」がある。この「表形式任意指定検索」を行な
うに際して、まず、属性値テーブル1内の情報に基づい
てインデックステーブルを作成する。例えば、第9図に
示すデータベースの場合、第10図に示すように、属性
(1)についてインデックステーブル3(1)、fi性
(2)についてインデックステーブル3(2)、属性(
3)についてインデッステーブル3(3)を夫々作成す
る。このインデックステーブルは8値に基づくソートに
より作成される。例えば、インデックステーブル3(1
)についてみると、値II A TLに対して ファイル1.ファイル3.・・・・・・値“B 11に
対して ファイル2.・・・・・・ 値“′C″に対して ファイル4.・・・ 等である。
On the other hand, when searching a database with the above-mentioned relational model structure, a ``tabular format arbitrary specification search'' is the conventional optimal method. When performing this "tabular format arbitrary specified search", first, an index table is created based on the information in the attribute value table 1. For example, in the case of the database shown in FIG. 9, as shown in FIG. 10, index table 3 (1) for attribute (1), index table 3 (2) for fi property (2),
3), index table 3(3) is created respectively. This index table is created by sorting based on 8 values. For example, index table 3 (1
), for the value II A TL, file 1. File 3. . . . File 2 for the value “B 11.” File 4 for the value “’C,” etc.

そして、例えば、 属性(1’)=A、且つ属性(2)=aのファイルを検
索する場合、インデックスファイル3(1)から値II
 A 11のファイル番号を、インデックスファイル3
(2)から値“aITのファイル番号を夫々検索し、そ
の各検索結果についてアンド(AND)処理を施すこと
によってファイル3等の最終的な結果を得るようにして
いる。
For example, when searching for a file with attribute (1') = A and attribute (2) = a, the value II is retrieved from index file 3 (1).
A The file number of 11 is index file 3.
The file number of the value "aIT" is searched from (2), and the final result such as file 3 is obtained by performing AND processing on each search result.

「表形式任意指定検索」では上記のような各属性間での
値のアンド処理、また、同−属性内での値のオア処理等
による各種処理を行なうことによって最終的な検索結果
を得ている。即ち、この「表形式任意指定検索」では1
つの属性に対しては1つの値しか取り得ない”という関
係モデル構造のデータベースを前提とした検索方式であ
る。
In "Tabular format arbitrary specified search", the final search result is obtained by performing various processing such as AND processing of values between each attribute as described above, and OR processing of values within the same attribute. There is. In other words, in this "table format arbitrary specified search", 1
This search method is based on a database with a relational model structure in which only one value can be taken for each attribute.

[発明が解決しようとする問題点] ところで、他の検索方式として「キーワード検索」があ
るが、このキーワード検索」はもともと各ファイルが属
性別に値を保持せず、キーワードとして任意のものを複
数個保持しているようなデ−タベースを対象とした検索
方式である。従って、この「キーワード検索」は上述し
たような関係モデル構造に基づいたデータベースに対し
ては本来適用し得ないものであった。
[Problems to be Solved by the Invention] By the way, there is another search method called "keyword search," but this "keyword search" originally did not hold values for each attribute in each file, but instead stored multiple arbitrary keywords as keywords. This is a search method that targets databases that are maintained. Therefore, this "keyword search" cannot originally be applied to a database based on the relational model structure as described above.

一方、情報のファイリングシステム等において、扱われ
る情報の多様性からその情報管理の多様性が望まれてい
る。即ち、特定の構造をとるデータベースに関する管理
方法を、扱う情報に応じて種々換えることができるよう
にすることである。
On the other hand, in information filing systems and the like, diversity in information management is desired due to the diversity of information handled. That is, it is possible to change the management method for a database with a specific structure in various ways depending on the information to be handled.

そこで、本発明の課題は、もともと「表形式任意指定検
索」が最適とされる関係モデル構造に基づいたデータベ
ースを基本とし、このデータベースに関して「キーワー
ド検索」を可能にすることである。
Therefore, an object of the present invention is to enable a ``keyword search'' on this database based on a database based on a relational model structure that is originally considered optimal for ``table format arbitrary specified search.''

尚、この課題を達成するについては、近年の半導体製造
記述の進歩により、大容団、低価格の半導体メモリが容
易に得られるようになったということが、具体的な技術
的背景となっている。
The specific technical background for achieving this task is that recent advances in semiconductor manufacturing description have made it easier to obtain large-capacity, low-cost semiconductor memories. There is.

[問題点を解決するための手段] 本発明は、第1図に示すように、属性値テーブル1と、
この属性値テーブル1の各属性(1)。
[Means for Solving the Problems] As shown in FIG. 1, the present invention includes an attribute value table 1,
Each attribute (1) of this attribute value table 1.

(2)、  (3)、・・・ に対応してその許容し得
る値の和集合を構成すべきドメインテーブル2(1)、
 2 (2)、 2 (3) 、・・・ とを有した関
係モデル構造に基づくデータベースの管理方法を前提と
している。そして、このようなデータベースの管理方法
にあって、上記課題を解決するための技術的手段は、任
意の属性(1または複数)に対応したドメインテーブル
、例えば2(1)にキーワードとしての値KW(1)、
KW(2)、・・・ の和集合を構成し、情報1nr(
1)、Inf(2)、 ・・・の保存に際して指定され
るキーワードを上記ドメインテーブル2(1)を参照し
て属性値テーブル1における任意の属性の値として設定
する一方、情報の検索に際して、指定されるキーワード
に対応した値を属性値テーブル1の各属性(1)。
(2), (3), ... A domain table 2 (1) that should constitute the union of its allowable values corresponding to
2 (2), 2 (3), ... The database management method is based on a relational model structure having the following. In such a database management method, the technical means for solving the above problem is to add the value KW as a keyword to a domain table corresponding to an arbitrary attribute (one or more), for example 2(1). (1),
Construct the union of KW(2),... and obtain information 1nr(
1), Inf(2), . Each attribute (1) in attribute value table 1 has a value corresponding to the specified keyword.

(2)、(3)、・・・ について検索し、その検索結
果から得られた各属性にについて同一値を有する情報の
和集合を当該キーワードに対する索結果とした。
(2), (3), ... were searched, and the union of information having the same value for each attribute obtained from the search results was taken as the search result for the keyword.

[作用コ 具体的にみると、上記方法によって第1図に示すような
データベースを構築した侵、例えば、KW(3)の情報
を検索するに際して、この指定されるキーワードに対応
した値KW(3)を属性値テーブル1の各属性(1)、
(2)、(3)、・・・について検索し、その検索の結
果から得られた各属性について同一値KW(3)を有す
る情報1nf(2)、Inf(4)、・・・ の和集合
が当該キーワードKW(3)に対する検索結果となる。
[Operations] Specifically, when a database like the one shown in Figure 1 is constructed using the above method, for example, when searching for information on KW(3), the value KW(3) corresponding to this specified keyword is searched. ) for each attribute (1) of attribute value table 1,
Search for (2), (3), ... and the sum of information 1nf(2), Inf(4), ... having the same value KW(3) for each attribute obtained from the search results. The set becomes the search result for the keyword KW(3).

[発明の実施例] 以下、本発明の実施例を図面に基づいて説明する。[Embodiments of the invention] Embodiments of the present invention will be described below based on the drawings.

第2図は本発明に係るデータベースの管理方法を実現す
るファイリングシステムの基本構成例を示したブロック
図である。
FIG. 2 is a block diagram showing an example of the basic configuration of a filing system that implements the database management method according to the present invention.

10はシステム全体を制御するシステム制御処理装置で
あり、このシステム制御処理装置10は一般的なものと
同様にプロセッサ、メモリ等のデバイスで構成されてい
る。そして、このシステム制御処理装置10はOCR等
の画像入力装置11、光ディスク麺置12、磁気ディス
ク装置13、レーザプリンタ等の画像出力装置14を夫
々制御すると共に、デイスプレィ装置16及びキーボー
ド装置17等で構成されたユーザーインタフェース装置
15との間で情報交換を行なうようになっている。
Reference numeral 10 denotes a system control processing device that controls the entire system, and this system control processing device 10 is composed of devices such as a processor and a memory, like a general system. The system control processing device 10 controls an image input device 11 such as an OCR, an optical disc noodle machine 12, a magnetic disk device 13, an image output device 14 such as a laser printer, and also controls a display device 16, a keyboard device 17, etc. Information is exchanged with the configured user interface device 15.

ここで、ファイリングすべき情報は光デイスク装置12
に順次格納されると共に、その格納した情報の検索デー
タベースが磁気ディスク装置13内に構築される。また
、磁気ディスク装置13に構築された当該データベース
の検索処理等やユーザーインタフェース処理等はシステ
ム制御処理装置10でのソフトウェアによって実現され
る。
Here, the information to be filed is the optical disk device 12.
At the same time, a search database of the stored information is constructed in the magnetic disk device 13. Further, search processing of the database built in the magnetic disk device 13, user interface processing, etc. are realized by software in the system control processing device 10.

まず、「表形式任意指定検索」を実現する場合について
説明する。
First, a case will be described in which a "tabular format arbitrary specification search" is implemented.

例えば、第3図に示すように、ある会社の従業名簿につ
いてのデータベースを想定する。
For example, as shown in FIG. 3, assume a database containing a company's employee directory.

この場合、″社員番号″がキー属性となり、パ氏名′°
、パ所底″、“年齢II 、II性別″が当該キー居住
に夫々I3I]数従屈した属性となる。そして、第3図
に示すような属性値テーブルを作成することにより関係
モデル構造のデータベースが構築される。
In this case, “employee number” is the key attribute, and the employee name is the key attribute.
, ``Age II'', ``Age II, and II Gender'' are attributes that are dependent on the key residence, respectively.Then, by creating an attribute value table as shown in Figure 3, the relational model structure can be created. A database is constructed.

この属性値テーブルは磁気ディスク装置13内に常時格
納されることになるが、例えばシステムの電源投入時に
、この属性値テーブルを参照して第4図に示すようなイ
ンデックステーブルが作成される。このインデックステ
ーブルはシステムvj御処理装置10内のメインメモリ
上に作成されることとなるが、これは、大容量、低価格
の半導体メモリが容易に得られる今日においては、実現
可能なことである。このインデックステーブルは属性゛
所焉″、“年齢″、゛性別″に関するものだけで充分で
ある。キー属性゛社員番号”、属性゛氏名″については
この場合効率等を考慮して作成しない。
This attribute value table is always stored in the magnetic disk device 13, but for example, when the system is powered on, this attribute value table is referred to and an index table as shown in FIG. 4 is created. This index table will be created on the main memory in the system VJ control processor 10, which is possible in this day and age where large capacity, low cost semiconductor memories are easily available. . It is sufficient for this index table to have information regarding the attributes "location", "age", and "gender". In this case, the key attribute "employee number" and the attribute "name" are not created in consideration of efficiency and the like.

ここで、例えば、 ゛所属″=゛営業″かつ“性別”=“男”の社員番号を
検索する場合の処理を説明する。
Here, for example, the process of searching for an employee number where ``Affiliation'' = ``Sales'' and ``Gender'' = ``Male'' will be described.

当該システムは、上記のようなインデックステーブル等
の他、゛所属″、“年齢”、゛性別″の各属性について
夫々社員番号とピット位置とを対応させたビットマツプ
メモリを有している。そして、上記条件指定に対し、“
所属″、″′性別”に対応したインデックステーブルを
参照して、対応するビットマツプメモリ上、1所属”に
ついては、“°営業″′の値を有する社員番号対応位置
に(第5図(a)参照)、′性別”については、“男”
の値を有する社員番号対応位置に(第5図(b)参照)
、夫々ビット“1”を展開する。その後、双方のビット
マツプメモリのアンド処理(AND)を同様に社員番号
とビット位置を対応させた他のビットマツプメモリ上で
行なう(第5図(C)参照)aその結果、上記条件に適
合する社員番号を11 i 11.・・・・・・ に決
定する。
In addition to the above-mentioned index table, the system has a bitmap memory in which employee numbers and pit positions are associated with each other for attributes such as "affiliation,""age," and "gender." Then, for the above condition specification, “
Referring to the index table corresponding to ``Department'' and ``Gender,'' on the corresponding bitmap memory, ``1 Department'' is placed in the position corresponding to the employee number having the value ``°Sales'' (Figure 5 (a). ), for ``gender'', ``male''
(See Figure 5(b))
, expand the bit "1" respectively. After that, AND processing (AND) of both bitmap memories is performed on another bitmap memory in which the employee number and bit position are similarly made to correspond (see Figure 5 (C)) a. As a result, the above conditions are met. Enter the employee number 11 i 11. It is decided that...

次に、基本的に上述したような関係モデル構造をとるデ
ータベースについて「キーワード検索」を実行する場合
を想定する。
Next, assume that a "keyword search" is to be performed on a database that basically has the relational model structure described above.

まず、第6図[b]に示すようにドメインテーブルには
当該ファイリングシステムにおいて許容し得るキーワー
ドとしての値゛′ワーブロバ、゛ワークステーション″
、′パソコンn、・・・ の和集合が構成されている。
First, as shown in FIG. 6 [b], the domain table contains the keywords ``'War Robber'' and ``Workstation'' that are permissible in the filing system.
, 'PC n, .

また、第6El[aJ示すような、パフアイル番号″を
キーB性とし、仮の属性(以下、板底性という)板底性
(1)、(2)。
In addition, the 6th El[aJ, puff aisle number'' is set as key B property, and provisional attributes (hereinafter referred to as board bottom property) board bottom property (1), (2).

(3)を設定した属性値テーブルが作成されている。こ
の属性値テーブルは第3図に示したものと基本的な構造
はまったく同じである。
An attribute value table in which (3) is set has been created. The basic structure of this attribute value table is exactly the same as that shown in FIG.

この状態において、ファイルの保存に際してキーワード
が指定されると、例えば、ファイル1についてキーワー
ドパワーブa”、“’ OA ”が指定されると、上記
ドメインテーブルを参照して指定された順に対応する値
“ワープロ″を板底性(1)に、“’ OA ”を板底
性(2)に設定する。尚、指定の順序が逆となった場合
には、“○A 11が板底性(1)に、“′ワープロ″
が板底性(2)に設定されることになる。即ち、ユーザ
ーインタフェース装置によるインプット操作を行なって
いる実際のオペレータには第6図[aJに示すようなf
M J6の属性値テーブルは見えていない。
In this state, if a keyword is specified when saving a file, for example, if the keywords ``powerbua'' and ``'OA'' are specified for file 1, the corresponding values are retrieved in the specified order by referring to the domain table above. Set "Word Processor" to bottom property (1) and "'OA" to board bottom property (2). If the order of specification is reversed, "○A 11" is set to board bottom property (2). 1) “’word processor”
is set to plate bottom property (2). In other words, the actual operator who is performing the input operation using the user interface device has the f
The attribute value table of MJ6 is not visible.

このようにして、第6図[aJに示すような属性値テー
ブル内のデータベースが構築される。
In this way, a database of attribute value tables as shown in FIG. 6 [aJ] is constructed.

更に、この場合も各板底性(1)、(2)。Furthermore, in this case as well, each plate bottom property (1), (2).

(3)について第7図に示すようなインデックステーブ
ルが作成される。その作成の手法も館述の例と同様であ
る。
Regarding (3), an index table as shown in FIG. 7 is created. The method of creating it is the same as the example in the library.

ここで、例えば、 キーワード=゛ワープロ″ のファイルを検索する場合の処理を説明する。Here, for example, Keyword = ``word processor'' The following describes the process for searching for files.

この場合においても、「表形式任意指定検索」の場合と
同様に、各板底性(1)、(2>、(3)について夫々
ファイル番号とピット位置とを対応させたビットマツプ
メモリを有している。そして、上記のようなキーワード
指定に対し、各板底性(1)、(2)、(3)に対応し
たインデックステーブルを参照して、対応する各ビット
マツプメモリ上に゛ワープロ″の値を有するファイル番
号対応位置に夫々ピッド″1”を展開する。その状態は
第8図に示すように、板底性(1)に対応するビットマ
ツプメモリが同図(a)、板底性(2)に対応するビッ
トマツプメモリが同図(b)、板底+1(3)に対応す
るビットマツプメモリが同図(C)のようになる。その
接、上記各ビットマツプメモリのオア処理(OR)を同
様にファイル番号とビット位置を対応させた他のビット
マツプメモリ上で行なう(第8図(d)参照)。その結
果、上記キーワード指定に適合するファイル番号を1″
、“2”、“6”、・・・ に決定する。
In this case as well, as in the case of "tabular format arbitrary specified search", a bitmap memory is provided in which file numbers and pit positions are associated with each other for each plate bottom property (1), (2>, (3)). Then, in response to the above keyword specification, the index table corresponding to each board property (1), (2), and (3) is referred to, and a word processor is written on each corresponding bitmap memory. A pit "1" is developed in each position corresponding to the file number having the value "1".The state is as shown in FIG. The bitmap memory corresponding to bottom property (2) is shown in the same figure (b), and the bitmap memory corresponding to board bottom +1 (3) is shown in the same figure (c). OR processing (OR) is similarly performed on other bitmap memories in which the file numbers and bit positions correspond (see Figure 8(d)).As a result, the file number matching the above keyword specification is 1''.
, “2”, “6”, . . .

上記実施例では、r表形式任意指定検索Jと「キーワー
ド検索」の対象となるデータ構造が関係モデル構造とし
て共通化され、更に、検索モジュールたるインデックス
テーブル及び検索用のビットマツプメモリ等の共通化が
図られている。
In the above embodiment, the data structure targeted by the r-table format arbitrary specification search J and the "keyword search" is shared as a relational model structure, and furthermore, the index table as the search module and the bitmap memory for search are made common. is planned.

従って、当該ファイリングシステムでは、検索条件から
検索手順への変換に関するモジュール及びユーザーイン
タフェースに関するモジュールを各検索方式について備
えさえすれば、「表現形式指定検索」または「キーワー
ド検索Jの任意の選択が可能となる。即ち、管埋すべき
情報に応じた検索方式の選択が容易に行なえるようにな
る。
Therefore, in this filing system, as long as a module related to conversion from search conditions to a search procedure and a module related to user interface are provided for each search method, it is possible to arbitrarily select "express format specified search" or "keyword search J." In other words, it becomes possible to easily select a search method according to the information to be stored.

また、上記各検索処理において、キー属性の値となる“
社員番号″あるいは“ファイル番号″とピット位置を対
応ざばたビットマツプメモリを使用し、その検索過程で
の中間的な結果、アンド処理、オア処理後の最終結果等
を当該ビットマツプメモリ上に展開するようにしたため
、当該検索処理の高速化が図られる。
In addition, in each of the above search processes, “
Using a Zabata bitmap memory that corresponds to the "employee number" or "file number" and the pit position, intermediate results of the search process, final results after AND processing, OR processing, etc. are stored in the bitmap memory. Since the information is expanded, the speed of the search process can be increased.

尚、樹も1造のデータ、例えば、会社等におけるける「
部→課−係→・・・」にて分類されるデータでは、その
データベースを関係モデル構造に従ったものにすると、
キー属性と各属性が関数従属する他1、各属性自体が夫
々遷移従属することになる。
Furthermore, it is important to note that tree-based data, for example, information about companies, etc.
For data that is classified by section → division → section →..., if the database is made according to the relational model structure,
In addition to being functionally dependent on the key attribute and each attribute, each attribute itself is also transitionally dependent.

このような構造のデータベースに適した検索方式として
は、「巡航検索」があるが、この場合、データベースの
構造が基本的に関係モデル構造となることから、上述し
たデータベースの構造及び検索モジュールを共通化シス
テムにおいて、更に「巡航検索」を実現することは容易
に行なえる。
A search method suitable for a database with this type of structure is a "cruise search," but in this case, the database structure is basically a relational model structure, so the database structure and search module described above are common. In addition, it is easy to implement a "cruise search" in the system.

但し、検索指定から検索手順への変換に関するモジュー
ル及びユーザーインタフェースに関するモジュールは上
記の場合と同様に当該[巡航検索Jに適したものが必要
となる。。
However, the modules related to the conversion from search specifications to search procedures and the modules related to the user interface must be suitable for the [Cruise Search J] as in the above case. .

[発明の効果1 以上説明してきたように、本発明によれば、もともと「
表形式任意指定検索」が最適とされる関係モデル構造と
なるデータベースに関して「キーワード検索Jが可能と
なることから、ファイリングされる情報等に応じてユー
ザが使い勝手の良い検索方式を[表形式任意指定検索]
及び「キーワード検索」から自由に選択することが可能
となる。
[Effect of the invention 1 As explained above, according to the present invention, originally “
Regarding databases with a relational model structure for which ``table format arbitrary specification search'' is optimal, ``keyword search J is possible, so users can select an easy-to-use search method according to the information to be filed. search]
and "keyword search".

そして、このような検索方式の選択の自由度を増した場
合でも、そのデータベースが関係モデル構造として共通
化しているから、システム全体の規模を必要以上に増す
こともない。
Even when the degree of freedom in selecting a search method is increased, the scale of the entire system does not increase unnecessarily because the database has a common relational model structure.

【図面の簡単な説明】[Brief explanation of drawings]

第1図は本発明に係る方法に適用されたデータベースを
示す図、第2図は本発明に係る方法が実現されるファイ
リングシステムの一例を示すブロック図、第3図は表形
式任意指定検索がなされるデータベースの例を示す図、
第4図は第3図のデータベースに関したインデックステ
ーブルを示す図、第5図は検索処理におけるビットマツ
プメモリの状態を示す図、第6図はキーワード検索がな
されるデータベースの例を示す図、第7図は第6図のデ
ータベースに関したインデックステーブルを示ず図、第
8図は検索処理におけるどットマップメモリの状態を示
す図、第9図は関係モデル溝面 造に基づくデータベースを示す図、第1劇は第9図のデ
ータベースに間したインデックステーブルを示す図であ
る。 [符号の説明] 1・・・属性値テーブル 2 (1ン 、  2(2)、  2(3)・・・ドメ
インテーブル 3 (1)、 3 (2>、 3 (3)・・・インデ
ックステーブル 10・・・システム制御2il処理装置11・・・画像
入力装置 12・・・光デイスク装置 13・・・磁気ディスク装置 14・・・画像出力装置 15・・・ユーザインタフェース装置 特許出願人  富士ゼロックス株式会社代 理 人  
弁理士 中村 智廣(外2名)第1図 第2図 第3図 第4図 第5図 第6図 第7図 第8図 第9図 、1 第10図
Fig. 1 is a diagram showing a database applied to the method according to the present invention, Fig. 2 is a block diagram showing an example of a filing system in which the method according to the present invention is realized, and Fig. 3 is a diagram showing a table format arbitrary specified search. A diagram showing an example of a database created,
4 is a diagram showing an index table related to the database in FIG. 3, FIG. 5 is a diagram showing the state of the bitmap memory in the search process, FIG. 7 shows the index table related to the database in FIG. 6, FIG. 8 shows the state of the dot map memory in the search process, FIG. The figure is a diagram showing an index table interposed in the database of FIG. 9. [Explanation of symbols] 1... Attribute value table 2 (1, 2 (2), 2 (3)... Domain table 3 (1), 3 (2>, 3 (3)... Index table 10...System control 2il processing device 11...Image input device 12...Optical disk device 13...Magnetic disk device 14...Image output device 15...User interface device Patent applicant Fuji Xerox Co., Ltd. Company agent
Patent Attorney Tomohiro Nakamura (2 others) Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9, 1 Figure 10

Claims (1)

【特許請求の範囲】[Claims] 属性値テーブルと、この属性値テーブルの各属性に対応
してその許容し得る値の和集合を構成すべきドメインテ
ーブルとを有した関係モデル構造に基づくデータベース
の管理方法であって、任意の属性に対応したドメインテ
ーブルにキーワードとしての値の和集合を予め構成し、
情報の保存に際して指定されるキーワードを上記ドメイ
ンテーブルを参照して属性値テーブルにおける任意の属
性の値として設定する一方、情報の検索に際して、指定
されるキーワードに対応した値を属性値テーブルの各属
性について検索し、その検索の結果から得られた各属性
について同一値を有する情報の和集合を当該キーワード
に対する検索結果としたことを特徴とするデータベース
の管理方法。
A database management method based on a relational model structure having an attribute value table and a domain table that configures the union of allowable values corresponding to each attribute of this attribute value table, the method comprising: Configure the union of values as keywords in advance in the domain table corresponding to
When saving information, the keyword specified is set as the value of any attribute in the attribute value table by referring to the above domain table, while when searching for information, the value corresponding to the specified keyword is set as the value of each attribute in the attribute value table. 1. A database management method characterized in that a search result for the keyword is set as a union of information having the same value for each attribute obtained from the search results.
JP61191618A 1986-08-18 1986-08-18 Managing method for data base Pending JPS6347826A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP61191618A JPS6347826A (en) 1986-08-18 1986-08-18 Managing method for data base

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP61191618A JPS6347826A (en) 1986-08-18 1986-08-18 Managing method for data base

Publications (1)

Publication Number Publication Date
JPS6347826A true JPS6347826A (en) 1988-02-29

Family

ID=16277630

Family Applications (1)

Application Number Title Priority Date Filing Date
JP61191618A Pending JPS6347826A (en) 1986-08-18 1986-08-18 Managing method for data base

Country Status (1)

Country Link
JP (1) JPS6347826A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0212565A (en) * 1988-06-30 1990-01-17 Toshiba Corp Relational data base system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0212565A (en) * 1988-06-30 1990-01-17 Toshiba Corp Relational data base system

Similar Documents

Publication Publication Date Title
USRE40235E1 (en) Data processing system and method for detecting mandatory relations violation in a relational database
US7013307B2 (en) System for organizing an annotation structure and for querying data and annotations
US6920460B1 (en) Systems and methods for managing partitioned indexes that are created and maintained by user-defined indexing schemes
US9043365B2 (en) Peer to peer (P2P) federated concept queries
US5960423A (en) Database system index selection using candidate index selection for a workload
US6944619B2 (en) System and method for organizing data
US6356901B1 (en) Method and apparatus for import, transform and export of data
US5913207A (en) Database system index selection using index configuration enumeration for a workload
US5950186A (en) Database system index selection using cost evaluation of a workload for multiple candidate index configurations
US5926813A (en) Database system index selection using cost evaluation of a workload for multiple candidate index configurations
US6122644A (en) System for halloween protection in a database system
JP3318834B2 (en) Data file system and data retrieval method
US5913206A (en) Database system multi-column index selection for a workload
CN1987861A (en) System and method for processing database query
JPH08235195A (en) Method for storage and retrieval of digital data transmission
MXPA05012291A (en) Complex data access.
US8086568B2 (en) Peer to peer (P2P) concept query notification of available query augmentation within query results
CN103473324A (en) Multi-dimensional service attribute retrieving device and method based on unstructured data storage
US20080250003A1 (en) Peer to peer (p2p) concept query abstraction model augmentation with federated access only elements
US8112458B1 (en) User segmentation user interface
US20050080820A1 (en) Method and system for generating, associating and employing user-defined fields in a relational database within an information technology system
JPS6347826A (en) Managing method for data base
JP2004192657A (en) Information retrieval system, and recording medium recording information retrieval method and program for information retrieval
CN108241624A (en) The generation method and device of a kind of query script
US20020138464A1 (en) Method and apparatus to index a historical database for efficient multiattribute SQL queries