JP2004506963A - Directory search and system - Google Patents

Abstract

Methods and systems for coordinating data in a relational database and searching a directory service database are provided. In particular, but not exclusively, X.264 in relational databases. Systems and directories for implementing or implementing 500 or LDAP services are provided. The present invention encompasses a database arrangement that stores the data type as a component in a table and searches the component for the desired data entry.

Description

【００２０】
然しながら、このようなサーチにおいて、適用したフィルタが、例えば、高度に反復性のデータストリング、データストリングの一部又は構造化データタイプのコンポーネントに対するものである場合には、データベースは多数の値を介してスキャンせねばならない場合があるのでそのサーチは遅く且つ非効率的なものである場合がある。
【００２１】
このようなサーチの効率を改善する１つの態様は、サブサーチテーブルを使用し且つ格納されているデータと関連する１個又はそれ以上のコンポーネントをサーチすることである。このような場合においては、データベースはストリング又は構造におけるコンポーネントに対するインデックスを使用することが可能な場合があり、従って多数の値をスキャンすることを回避する。このようなサーチに対するＳＱＬステートメントの１つの例は以下のようなものである。
【００２２】
【数２】

【００２３】
この具体例においては、ベースオブジェクト及び全体的ツリーサーチ１１はサブサーチテーブル４を使用し、１レベルサーチ１２はＤＩＴテーブル１４及びサブサーチテーブル４を使用し、且つサブツリーサーチ１３はツリーテーブル１５及びサブサーチテーブル４３を使用する。この例においては、使用されるフィルタは格納されているデータのコンポーネントを参照し、そのことはインデックスを使用することを許容し且つより高速でより効率的なサーチとなる。この例において使用されるインデックスはＣＩＤ＝ｘを包含している。
【００２４】
構造化属性
本発明に基づく方法は種々のその他の適用例において使用することが可能である。１つの適用例はセキュリティ分野であり、その場合には標準化した証明書を格納するためにディレクトリが認証局によって益々使用されている。このような証明書の１つの例はＸ．５０９証明書である。Ｘ．５０９等の証明書は、多数のコンポーネントを包含しているので「複雑」な属性と呼ぶことが可能である。然しながら、本発明はこれらのタイプの証明書のみに制限されるべきものではない。本発明はコンポーネントを具備する任意の形態の情報と共に使用することが可能であることが理解される。
【００２５】
このような証明書を格納する場合には、証明書の検索が迅速且つ信頼性のあるものであるように（即ち、所望の証明書が実際に検索される）、どのようにして証明書を格納するかについての考慮がなされるべきである。本発明方法及びデータベース構成は、例えば連続番号、満了日及び発行者等の証明書内のデータのコンポーネントのうちの１つ又はそれ以上を見つけ出し且つ管理することによってこのことを達成する。
【００２６】
図４はＸ．５０９証明書への本発明の適用を示している。説明の便宜上、各テーブルの小さな部分のみを示してある。証明書２０は模式的に示してあり、且つ説明の便宜上、フィールド２１における発行者、フィールド２２における有効性情報、フィールド２３における連続番号、フィールド２４におけるバージョン番号、フィールド２５における主体情報（例えば、ｒｉｃｋ　ｈａｒｖｅｙ）等の情報のみを示してある。この例の場合には、サーチテーブル３が、証明書２０の各コンポーネント即ちフィールドの正規化した値を分離するスペース（好適には２個）と共に１つの行内に配列されている。このサーチテーブルは、更に、全体的な証明書を表わす正規化した値を包含している。サブサーチテーブル４が１つ又はそれ以上の行（２６，２７，２８，２９，３０）と共に配列されており、１つの行は証明書２０における１つのコンポーネント即ちフィールドに対応している。然しながら、注意すべきことであるが、サブサーチテーブル４は証明書２０において識別されているすべてのフィールドを包含することが必要なものではない。
【００２７】
この実施例に対する具体例を例示するために、簡単な証明書が、例えば連続番号、満期日、所有者名等の、クレジットカードを保持している場合と同様の情報から構成されているものと仮定する。この簡単な証明書は３個のコンポーネント即ちフィールドを有しており、即ち番号フィールドと、日付フィールドと、ストリングフィールドとを有している。この簡単化した例においては、サーチテーブル３（図１ｂにおける形態）で格納される証明書２０の正規化した値は以下の通りである。
【００２８】
【数３】

【００２９】
サーチテーブル４は、例えば、３個の行、即ち該証明書の各コンポーネントに対して１個づつを格納することが可能である。該サブサーチテーブルの各行は以下に示すように図１ｂの形態にある。
【００３０】
【数４】

【００３１】
尚、ｘｘ，ｙｙ，ｚｚは、例えばＥＩＤ、ＡＩＤ、ＶＩＤ等の特定のテーブル構成におけるフィールドに対応する整数である。
【００３２】
サーチテーブル３を使用する「ＲＩＣＫ　ＨＡＲＶＥＹ」に対して発行された証明書に対するサーチは以下のＳＱＬステートメントを使用することが可能である。
【００３３】
【数５】

【００３４】
尚、一般的なフィルタは「ＮＯＲＭ　ＬＩＫＥ　‘％ＲＩＣＫ　ＨＡＲＶＥＹ％’」である。然しながら、このようなサーチに対してサーチテーブル３を使用することは遅い場合がある。何故ならば、各エントリに対するストリングの各コンポーネントが検査されねばならず且つサーチされ且つ検索されているストリングが所望のエントリである確実性の程度のためである。何故ならば、平坦化させた表示は非構造化テキスト表示であり境界を有していないからである。
【００３５】
正確な又は初期的なフィルタを適用する場合にサブサーチテーブル４が使用され且つサーチ引数に対してコンポーネント識別子が付加される場合には「ＲＩＣＫ　ＨＡＲＶＥＹ」に対して発行された証明書に対するサーチはより効率的なものである。この場合には、以下のＳＱＬステートメントを使用することが可能である。
【００３６】
【数６】

【００３７】
尚、「ＮＯＲＭ＝‘ＲＩＣＫ　ＨＡＲＶＥＹ’」がフィルタであり、ＡＩＤ＝２７が証明書に対する属性識別子であり、且つＣＩＤ＝４が主体に対するコンポーネント識別子である。
【００３８】
上の例においては、コンポーネント識別子（即ちインデックス）ＣＩＤ＝４を有するサーチが使用されている。何故ならば、それはインデックスＣＩＤ＝４がカード保持者の名前を表わすストリングであることがサブサーチテーブル４のデザインから又はサブ属性テーブル６から既知であるからである。インデックスＣＩＤが４に設定される且つフィルタが「ＮＯＲＭ＝‘ＲＩＣＫ　ＨＡＲＶＥＹ’」である場合のクエリィはＲｉｃｋ　Ｈａｒｖｅｙの証明書をリターン即ち返すべきである。このクエリィはより良好なものであると考えられる。何故ならば、それはサーチをより高速なものとさせ且つそのサーチが正確な証明書を見つけ出す確実性の程度を増加させる適切なインデックスを利用することが可能だからである。注意すべきことであるが、サブサーチテーブルデザインにおけるキャラクタ／文字又は数字の実際の指定は任意であり、且つ特定の適用例に適するどのような態様にでも設計することが可能である。
【００３９】
再度図４を参照して、本発明に基づく方法の別の具体例について説明する。この具体例においては、サーチテーブル３Ａはチェックサム又はフィンガープリントを包含するように調整又は配列されたサーチテーブルである。サーチテーブル３Ａは何等かの属性タイプ、例えば二進に関する正確なマッチングのために使用されるので、このサーチテーブルにおける値はフィンガープリント又はチェックサムの値とすることが可能である。このことは格納することが必要とされるデータはより少ないので、サーチテーブルにおける格納をより効率的なものとさせる。
【００４０】
ストリング属性
本発明は、又、例えばストリングデータタイプ等の複雑でないデータタイプに対して使用することも可能である。ストリングデータタイプの例としては、マルチワード文章、テキストのマルチラインパラグラフ、及びマルチライン郵便アドレス等がある。この場合には、簡単な文章である属性値は以下の如くにしてサーチテーブルにおける単一の行内に格納することが可能である。
【００４１】
【数７】

【００４２】
尚、列（又はフィールド）は（ＥＩＤ，ＡＩＤ，ＶＩＤ，ＮＯＲＭ）として定義されている。「ＷＯＲＤ」に対するストリングデータタイプをサーチするクエリィは部分的なワード「％ＷＯＲＤ％」に対する行を探すことが関与し、そのことは比較的遅いサーチであると考えられる。このようなデータのサーチを改善するために、ストリングをサブサーチテーブル４内におけるコンポーネントとして格納し、従ってストリング「ＭＡＮＹ　ＷＯＲＤ　ＳＥＮＴＥＮＣＥ」は以下の如くにして３つの行内に格納される。
【００４３】
【数８】

【００４４】
尚、列は、夫々、（ＥＩＤ，ＡＩＤ，ＶＩＤ，ＣＩＤ，ＣＶＩＤ，ＮＯＲＭ）として定義されている。この例においては、適用されるフィルタはサーチテーブル３の代わりにサブサーチテーブル４を使用し、以下のＳＱＬステートメントを「ＷＯＲＤ」に対するサーチのために使用することが可能である。
【００４５】
【数９】

【００４６】
その結果は著しく速いサーチである。何故ならば、上述した如く、部分的なワード「％ＷＯＲＤ％」を探すのではなく「ＷＯＲＤ」の正確なマッチを探すものだからである。
【００４７】
別のインデックス
本発明は、又、あるタイプのクリエィに対する性能を増加させる目的のために与えられている属性に対して１個又はそれ以上のインデックスを付加することが可能である問題に対して一般的な適用可能性を有している。インデックスを付加することは、例えば、逆インデックス等の属性を見つけ出すための異なる経路を提供する。この場合には、サブサーチテーブル内に１つのコンポーネントが存在するに過ぎない場合がある。該コンポーネントは、事実上、その属性値の別の形態を表わす。
【００４８】
特に、このサブサーチテーブルは、「ｅｎｄ　ｉｎ」サーチ問題、即ち格納されているデータの初期的部分が比較的高度に反復性である（例えば、著名な名前、ＭＡＣアドレス、電話番号、完全に資格が与えられたファイル名等）である値に対してのサーチを行う場合に、その値の逆の形態を格納しそれにより属性に関して逆にしたインデックスを有する効果を与えることによって問題に対処することが可能である。例えば、図５を参照すると、電話番号３１がサーチテーブル３２内にエンターされ、且つその電話番号は、又、逆の形態でサブサーチテーブル３３内にエンターされる。勿論、本発明のこの側面は逆の形態に制限されるものではなく、それは、例えば電話番号のエリアコードを別個のコンポーネントとして取扱うこと等の与えられた状態又はサーチに対して適切な任意のその他の妥当なデータエントリ形態とすることが可能である。
【００４９】
典型的に電話番号の終わりの部分である電話の内線に対してのサーチを行う場合には、サーチは「＊１２３４」（＊はワイルドカード）に対するストリングサーチとして表わすことが可能である。サーチテーブル３２のみが使用される場合には、そのサーチの性能は遅い。何故ならば、インデックスは「ｂｅｇｉｎ　ｗｉｔｈ」（で開始）又は「正確」なサーチに対してのみ可能だからである。然しながら、サーチテーブル３３内に逆に格納されている属性の場合には、例えば「４３２１＊」等の等価なサーチを行うためにサブサーチテーブルを使用することが可能であり、そのことは非常に高速であると考えられる。
【００５０】
より詳細には、サーチテーブル３２は以下の如くにある人に対する電話番号を格納する場合がある。
【００５１】
【数１０】

【００５２】
且つ、サブサーチテーブル３３内には以下のものが格納される。
【００５３】
【数１１】

【００５４】
且つ「１２３４」で終了する電話番号を見つけ出すためのＳＱＬステートメントは以下の形態のものとすることが可能である。
【００５５】
【数１２】

【００５６】
サブサーチテーブル３３をサーチすることは、サーチテーブル３２をサーチすることよりも所望の記録をより速く検索することとなる。何故ならば、そのサーチは「４３２１」に対する初期的なマッチ（即ち「ｂｅｇｉｎ　ｗｉｔｈ」（で開始））に対するものであり、それはより速いサーチだからである。
【００５７】
別のインデックスの別の例は例えば写真又はオーディオ等の二進値のチェックサムの格納である。
【００５８】
別のインデックスの更に別の例は、例えば写真のより小さな表示等のデータのより小さな表示であるフィンガープリントの格納である。
【００５９】
本発明をＸ．５００ディレクトリサービスシステムを参照して開示したが、本発明はこのシステム及び本明細書に開示した方法に制限されるべきものではない。本明細書を全体的に読むことによって理解されるように、本発明は多数の異なるディレクトリサービスシステムにおいて適用又は実現することが可能であり又多様な方法を使用することが可能である。
【図面の簡単な説明】
【図１ａ】本発明に基づく例示的なデータベースの原理及び概念的構成を示した概略図。
【図１ｂ】サブサーチテーブル及びサブ属性テーブルを包含する本発明に基づく例示的なデータベースの論理的デザイン及び物理的デザインを示した概略図。
【図２】本発明に基づく高次サーチ方法を示した概略図。
【図３】本発明に基づく低次サーチ方法を示した概略図。
【図４】例示的なＸ．５０９証明書及び対応するサーチ及びサブサーチテーブルの例を示した概略図。
【図５】電話番号データコンポーネントに関連した例示的なサーチ及びサブサーチテーブルを示した概略図。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to the field of directory services. More specifically, the present invention relates to a table structure in a database array used in a search, such as X.264 in a relational database. The present invention relates to application of an electronic directory service such as 500 or LDAP and a database search method.
[0002]
[Prior art]
Relational database management systems (RDBMSs) provide facilities for applications to store and process data. Among the many features provided by the RDBMS are data integrity, consistency, concurrency, indexing mechanisms, query optimization, recovery, rollback, and security. RDBMS also offers a number of tools for performance tuning, import / export, backup, auditing and application development.
[0003]
RDBMS is a good choice for most large managers of data. RDBMSs are readily available and reliable and are known to include a number of useful management tools. There is a large base of installing RDBMSs, and thus a large amount of existing skill and investment in the personnel and procedures to run these systems, and thus the data manager uses them when acquiring new systems. Expect to do. Most relational database products support the industry standard SQL (Structured Query Language).
[0004]
There is also a move towards object-oriented systems, which provide the ability and data extensibility to handle arbitrarily complex data items. Further, many companies and government agencies have numerous database applications that are not interconnected. Data managers are looking for a solution that will allow them to integrate their data and simplify the management of the data. Electronic directories provide data managers with tools to achieve these goals. Some electronic directories have been standardized. X. 500 is an international standard for electronic directories (CCITT89 or ITU93). These standards define a very flexible and universal directory service, protocol and information model. X. 500 is applicable to information systems where data is fairly static (eg, phone books), but is distributed (eg, across an organization or set), and extensible (eg, names, addresses, titles, It may be necessary to store devices, etc.), be object-oriented (ie, enforce rules on data) and / or be accessed remotely. X. An electronic directory, such as 500 and its associated standards, provides a framework and some functionality that allows the data manager to achieve its purpose.
[0005]
Typically, data managers have all the flexibility of an object-oriented system, but the scalability inherent in relational systems combined with the stability, robustness, portability and cost effectiveness of current SQL products Using SQL products to enable the system to achieve performance and performance, e.g. It is desired to implement an electronic directory, such as a 500 directory.
[0006]
One example of an electronic directory embodiment is described in U.S. patent application Ser. No. 09 / 427,267 and its corresponding Austrian patent 712451, which are hereby incorporated by reference in their entirety. Take in. In the search strategy for this example, at a conceptual level, a hierarchical table such as NAME, DAT, TREE, etc., is used to maintain the relationships between objects in the hierarchy. These hierarchy tables are arranged according to one row per object. For example, object tables such as SEARCH (search) and ENTRY (entry) manage values in one object. These object tables are arranged according to one row per value. Every object has a corresponding row in the hierarchy table and every attribute value has a corresponding row in the object table. In this example, the object table used to search for objects contains a row of the form (EID, AID, VID, Norm), where EID identifies the object to which the value belongs and AID Identifies the attribute type of the value, VID identifies one of the possible number of attribute values in an entry, and Norm includes the syntax normalized value. For example, an attribute table such as an attribute defines information on the attribute type. The attribute table used contains rows of the form (AID, SYX, DESC, OBJECT @ ID).
[0007]
It has been found that improvements to electronic directory implementations can be achieved to adjust and search databases for complex data types.
[0008]
[Means for Solving the Problems]
The present invention uses one or more of the components included in the stored data, the identifier of the stored data, and / or the indication of the data using some form of processing, such as processing of the stored data. It concerns storage and / or search for types. This implementation helps to search for a particular entry in a database that contains information about data entries, such as, but not limited to, component identifier (CID) information representing individual components, or A new search and / or storing predetermined information considered useful and / or component value identifier information (CVID) representing one or more multi-valued components used for the search. Adding an attribute table simplifies searching of complex data types. These new tables are referred to herein as sub-search tables and / or sub-attribute tables, which serve to store the components of the values and separate components and / or multi-values. Simplify component search. However, such tables can be referenced by any name.
[0009]
In one embodiment, the present invention provides a method for arranging or aligning data in a database. The method creates a first table adapted to store data and having one row for each data entry, and adapted to store data components and of a stored data type. Includes creating a second table with one row for each component. Preferably, the data is of a structured data type or string data.
[0010]
The present invention also provides a database and / or directory having a data storage arrangement. Although reference is made to databases throughout the remainder of the specification, the invention applies equally to directory service systems. The data storage device is a first table oriented in a hierarchy defining the relationships between objects and having one row per object, defining one or more values in each object. A second table, directed to the object to be read and configured to have one row per value, one or more selected components or display of values, and for each component of each value And a third table configured to have one row. Preferably, the database is, for example, X.400. 500 or a part of a directory service system such as an LDAP service system. The present invention also provides a method for searching a database for a given data entry. In this embodiment, the database is adapted to store data and is adapted to store a first table having one row for each data entry, and a data component or display; There is a second table having one row for each component of the stored data. The search method determines a component or representation of a given data entry, performs one of an exact or initial match on the second table to find the component or representation, and Including returning a given data entry that matches.
[0011]
Throughout this specification, the term "component" may alternatively or additionally refer to a value such as an inverted index or a pointer or a fingerprint or a checksum or any suitable smaller representation of any of the relatively large data. "Indication" can be included.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1a shows an exemplary implementation of a database configuration and is just one type of database to which the method and apparatus of the present invention can be applied. A more detailed description of this database configuration can be found in US patent application Ser. No. 09 / 427,267, which is hereby incorporated by reference in its entirety. FIG. 1b shows a more detailed example of the database configuration of FIG. 1a. Normally, when searching a directory that has a database, where the search arguments start the search (base object), the scope of the search (subset), the conditions to apply to the search (filter), and how to search Defines what information should be returned (selection). The filter is a combination of one or more filter items (ie, conditions) connected by operators such as, for example, AND, OR, NOT, and the like.
[0013]
In the case of a normal search service, filters are applied to values and attributes in an object table, for example a search table. One example of a common filter is "NORM @ LIKE @% RICK @ HArvEY%". In the case of a particular search service (described in more detail below), it is possible to add a clause to the SQL statement that contains a component identifier that addresses a particular component of the data type, and to specify the exact or initial ( Or "start with") filters are applied to components in the sub-search table instead of the search table. One example of such a clause is "AND @ CID = N", and one example of an accurate filter is "NORM = @ RICK @ HARVEY".
[0014]
Referring to FIG. 1B, the table structures of the logical design 1 and the physical design 2 include a search table 3, a sub-search table 4, an attribute table 5, and a sub-attribute table 6. The search table 3 and the attribute table 5 are similar to the search table and the attribute table described in US patent application Ser. No. 09 / 427,267, and a detailed description thereof will be omitted. The sub-search table 4 can be configured to include one or more components used to improve the speed and reliability of the search. For example, sub-search table 4 may include CID field 7 and CVID field 8. The CID field 4 acts as a tool (or index) for searching for a component of the data type, and the CVID field 8 acts as a tool (or index) for a multi-valued component search. The method according to the invention can be used with one or more of the tables described above, but preferably each table is provided such that a selection exists for a particular search query. .
[0015]
The attribute table 5 describes or refers to the information in the search table 3, and the sub-attribute table 6 describes or refers to the information in the sub-search table 4. The sub-attribute table 6 has the same fields as the attribute table 5, but replaces the CID field 9 with the AID field 10. The CID field 9 is used to identify one or more components in the sub search table 4.
[0016]
The subsearch table 4 preferably stores components of complex data types or information that improves search performance. Other components stored in the sub-search table may improve the management capabilities of the database. In other words, it is not a condition that all the values in the data entry are included in the sub search table.
[0017]
A method for searching a database will be described with reference to FIGS. Examples of the search include a base object and all three searches 11, a one-level search 12, and a subtree search 13. A more detailed description of these searches can be found in US patent application Ser. No. 09 / 427,267. Searches with a range of base objects and an overall tree 11 use the search table 3. Searches that have a range of base objects or an entire tree 11 and that can utilize the stored components use the sub-search table 4. A search having a range of one level 12 uses a join between DIT table 14 and search table 3. Searches that have a range of one level 12 and that can utilize the stored components use a join between the DIT table 14 and the subsearch table 4. Searches that have a range of subtree 13 use a join between tree table 15 and search table 3. Searches that have components of the subtree 13 and utilize stored components use a join between the tree table 15 and the subsearch table 4.
[0018]
If, by way of example, the desired search arguments consist of general filters, the base object and global tree search 11 uses search table 3, and the one-level search 12 uses DIT table 14 and search table 3 , And the subtree search 13 uses the tree table 15 and the search table 3. One example of an SQL statement for such a search could be:
[0019]
(Equation 1)

[0020]
However, in such a search, if the applied filter is, for example, for a highly repetitive data string, a portion of a data string, or a component of a structured data type, the database may use multiple values. The search may be slow and inefficient because it may have to be scanned.
[0021]
One way to improve the efficiency of such a search is to use a sub-search table and search for one or more components associated with the stored data. In such cases, the database may be able to use the index for the component in the string or structure, thus avoiding scanning a large number of values. One example of an SQL statement for such a search is as follows:
[0022]
(Equation 2)

[0023]
In this embodiment, the base object and global tree search 11 uses the sub search table 4, the one level search 12 uses the DIT table 14 and the sub search table 4, and the sub tree search 13 uses the tree table 15 and the sub search table 4. The search table 43 is used. In this example, the filters used refer to components of the stored data, which allows the use of the index and results in a faster and more efficient search. The index used in this example includes CID = x.
[0024]
Structured attributes
The method according to the invention can be used in various other applications. One application is in the security field, where directories are increasingly being used by certificate authorities to store standardized certificates. One example of such a certificate is X.C. 509 certificate. X. Certificates such as 509 can be called "complex" attributes because they contain many components. However, the invention should not be limited to only these types of certificates. It is understood that the present invention can be used with any form of information comprising a component.
[0025]
If such a certificate is stored, how can the certificate be retrieved so that the certificate search is quick and reliable (ie, the desired certificate is actually retrieved). Consideration should be given to whether to store. The method and database arrangement of the present invention accomplish this by finding and managing one or more of the components of the data in the certificate, such as, for example, a serial number, expiration date, and issuer.
[0026]
FIG. 509 illustrates the application of the present invention to a 509 certificate. For convenience of description, only a small portion of each table is shown. The certificate 20 is schematically shown, and for convenience of explanation, an issuer in a field 21, validity information in a field 22, a serial number in a field 23, a version number in a field 24, and subject information in a field 25 (for example, rick harvey) is shown. In this case, the search table 3 is arranged in one row with spaces (preferably two) separating the normalized values of each component or field of the certificate 20. This search table further contains normalized values representing the overall certificate. The subsearch table 4 is arranged with one or more rows (26, 27, 28, 29, 30), one row corresponding to one component or field in the certificate 20. It should be noted, however, that sub-search table 4 need not include all fields identified in certificate 20.
[0027]
To illustrate a specific example for this embodiment, it is assumed that a simple certificate is composed of the same information as when a credit card is held, for example, a serial number, an expiration date, and an owner name. Assume. This simple certificate has three components or fields: a number field, a date field, and a string field. In this simplified example, the normalized values of the certificate 20 stored in the search table 3 (the form in FIG. 1b) are as follows.
[0028]
(Equation 3)

[0029]
The search table 4 can store, for example, three rows, one for each component of the certificate. Each row of the sub-search table is in the form of FIG. 1b as shown below.
[0030]
(Equation 4)

[0031]
Note that xx, yy, and zz are integers corresponding to fields in a specific table configuration such as EID, AID, and VID.
[0032]
The following SQL statement can be used for a search for a certificate issued for “RICK @ HARVEY” using the search table 3.
[0033]
(Equation 5)

[0034]
Note that a general filter is “NORM LIKE‘% RICK HARVEY% ’”. However, using search table 3 for such a search may be slow. This is because each component of the string for each entry must be examined and the degree of certainty that the string being searched and searched for is the desired entry. This is because the flattened display is an unstructured text display and has no boundaries.
[0035]
If the sub-search table 4 is used when applying an accurate or initial filter and a component identifier is added to the search argument, the search for the certificate issued for "RICK @ HARVEY" will be more It is efficient. In this case, the following SQL statement can be used:
[0036]
(Equation 6)

[0037]
Note that "NORM = 'RICK \ HARVEY'" is a filter, AID = 27 is an attribute identifier for a certificate, and CID = 4 is a component identifier for a subject.
[0038]
In the above example, a search with a component identifier (ie, index) CID = 4 is used. This is because it is known from the design of the sub-search table 4 or from the sub-attribute table 6 that the index CID = 4 is a string representing the name of the cardholder. If the index CID is set to 4 and the filter is "NORM = 'RICK \ HARVEY'", the query should return a Rick \ Harvey certificate. This query is likely to be better. Because it makes it possible to use a suitable index that makes the search faster and increases the degree of certainty that the search finds the correct certificate. It should be noted that the actual designation of characters / characters or numbers in the sub-search table design is arbitrary and can be designed in any manner suitable for a particular application.
[0039]
Referring to FIG. 4 again, another embodiment of the method according to the invention will be described. In this example, search table 3A is a search table that has been adjusted or arranged to include a checksum or fingerprint. Since the search table 3A is used for exact matching with some attribute type, for example binary, the values in this search table can be fingerprint or checksum values. This makes the storage in the search table more efficient since less data needs to be stored.
[0040]
String attributes
The invention can also be used for uncomplicated data types such as, for example, string data types. Examples of string data types include multi-word sentences, multi-line paragraphs of text, and multi-line postal addresses. In this case, the attribute value, which is a simple sentence, can be stored in a single row in the search table as follows.
[0041]
(Equation 7)

[0042]
Note that a column (or field) is defined as (EID, AID, VID, NORM). A query searching for a string data type for "WORD" involves finding a row for the partial word "% WORD%", which is considered a relatively slow search. To improve the search for such data, the strings are stored as components in the subsearch table 4, so that the string "MANY \ WORD \ SENTENCE" is stored in three rows as follows.
[0043]
(Equation 8)

[0044]
The columns are defined as (EID, AID, VID, CID, CVID, NORM), respectively. In this example, the applied filter uses sub-search table 4 instead of search table 3, and the following SQL statement can be used for the search for "WORD".
[0045]
(Equation 9)

[0046]
The result is a significantly faster search. This is because, as described above, the search is not for the partial word "% WORD%", but for the exact match of "WORD".
[0047]
Another index
The present invention also has general application to the problem where it is possible to add one or more indices to attributes given for the purpose of increasing performance for certain types of queries. Has the potential. Adding an index provides a different path for finding attributes such as, for example, an inverted index. In this case, only one component may exist in the sub search table. The component effectively represents another form of its attribute value.
[0048]
In particular, this sub-search table indicates that the "end @ in" search problem is that the initial portion of the stored data is relatively highly repetitive (eg, well-known names, MAC addresses, telephone numbers, fully qualified Addressing the problem when performing a search for a value that is a given filename, etc.) by storing the reverse form of that value, thereby giving the effect of having an inverted index on the attribute. Is possible. For example, referring to FIG. 5, a telephone number 31 is entered in a search table 32, and that telephone number is also entered in a sub-search table 33 in a reverse manner. Of course, this aspect of the invention is not limited to the reverse form, which may be a given condition, such as treating the area code of a telephone number as a separate component, or any other suitable for a search. Can be a reasonable data entry form.
[0049]
When performing a search for telephone extensions, typically at the end of a telephone number, the search can be expressed as a string search for "* 1234" (* is a wildcard). When only the search table 32 is used, the performance of the search is slow. This is because the index is only possible for "begin @ with" (starts with) or "exact" search. However, in the case of attributes stored in reverse in the search table 33, it is possible to use a sub-search table to perform an equivalent search such as "4321 *", which is very important. Considered to be fast.
[0050]
More specifically, the search table 32 may store telephone numbers for certain people as follows.
[0051]
(Equation 10)

[0052]
The following are stored in the sub search table 33.
[0053]
(Equation 11)

[0054]
The SQL statement for finding the telephone number ending with "1234" can be in the following form.
[0055]
(Equation 12)

[0056]
Searching the sub-search table 33 will search the desired record faster than searching the search table 32. Because the search is for an initial match for "4321" (ie, "begin @ with"), it is a faster search.
[0057]
Another example of another index is the storage of a checksum of a binary value, such as a photo or audio.
[0058]
Yet another example of another index is the storage of a fingerprint that is a smaller representation of the data, such as a smaller representation of a photo.
[0059]
The invention is described in X. Although disclosed with reference to a 500 directory service system, the present invention should not be limited to this system and the methods disclosed herein. As will be understood by reading this entire specification, the present invention can be applied or implemented in a number of different directory service systems and use a variety of methods.
[Brief description of the drawings]
FIG. 1a is a schematic diagram illustrating the principles and conceptual configuration of an exemplary database according to the present invention.
FIG. 1b is a schematic diagram illustrating the logical and physical design of an exemplary database according to the present invention that includes a sub-search table and a sub-attribute table.
FIG. 2 is a schematic diagram illustrating a higher-order search method according to the present invention.
FIG. 3 is a schematic diagram showing a low-order search method according to the present invention.
FIG. FIG. 5 is a schematic diagram illustrating an example of a 509 certificate and corresponding search and sub-search tables.
FIG. 5 is a schematic diagram illustrating an exemplary search and sub-search table associated with a telephone number data component.

Claims (28)

In a method of arranging data in a database,
Creating a first table adapted to store data and having one row for each data entry;
Creating a second table adapted to store data components and having one row for each component of the data;
The method that encompasses that. The method of claim 1, wherein the data is of a structured data type. The method of claim 1, wherein the data is of a string data type. 2. The method of claim 1, wherein the data is X. A method that is or represents a 509 certificate. The method of claim 1, wherein the component of the data is a checksum or fingerprint. The method of claim 1, wherein the database is part of an electronic directory service system. The electronic directory service system of claim 6, wherein 500 and a method comprising an LDAP service system. In a database that has a data storage array,
A search table containing at least one row having a plurality of columns,
A sub-search table containing at least one row having a plurality of columns containing a component identifier column;
A database that has 9. The method according to claim 8, wherein the column of the search table has a form of "EID, AID, VID, Norm", the EID identifies an object to which the value belongs, and the AID identifies an attribute type of the value. , VID is a database that identifies one of the possible number of attribute values in one entry. 9. The method according to claim 8, wherein the columns of the search table are in the form of "EID, AID, VID, CID, Norm", the EID identifies the object to which the value belongs, and the AID identifies the attribute type of the value. , VID identifies one of the possible number of attribute values in one entry, and CID identifies the component identifier. 9. The database of claim 8, further comprising a sub-attribute table including at least one row having a plurality of columns provided with descriptions or references to the sub-search table. 12. The database according to claim 11, wherein columns of the sub-attribute table are in the form of "CID, SYN, DESC, OBJECT @ ID, FLAGS". In a database that has a data storage array,
A first table, oriented to a hierarchy defining relationships between objects, and configured to have one row per object;
A second table directed to the object defining one or more values in each object and configured to have one row per value;
A third table directed to the values of the one or more selected components and configured to have one row for each component of each value;
A database that has In a directory service system that implements a directory service request for a database,
A first table configured to store data and having one row for each data entry;
A second table configured to store data components and having one row for each component of the data;
A directory service system having 15. The directory service system according to claim 14, wherein the data is of a structured data type. 15. The directory service system according to claim 14, wherein the data is a string data type. 14. The method according to claim 14, wherein Directory service system that is 500 or LDAP. In a directory service system that has a data storage array,
A first table, oriented to a hierarchy defining relationships between objects, and configured to have one row per object;
A second table directed to the object defining one or more values in each object and configured to have one row per value;
A third table directed to one or more selected components of the value and configured to have one row for each component of each value;
A directory service system having 19. The directory service system according to claim 18, wherein the data is of a structured data type. 19. The directory service system according to claim 18, wherein the data is a string data type. Claim 18. Directory service system that is 500 or LDAP. In a method of searching a database for a given data entry, the database stores a first table adapted to store data and having one row for each entry, and a data component. A second table adapted to have a single row for each component of said data.
Determine the components of a given data entry,
Performing one of an exact or initial match on the second table to locate the component;
Returning the given data entry that matches the located component;
The method that encompasses that. 23. The method of claim 22, wherein the database is part of an electronic directory service system. 23. The electronic directory service system of claim 22, wherein 500 and a method comprising an LDAP service system. 23. The method of claim 22, wherein the data is X.D. 509 A certificate and / or a checksum of the data and / or a fingerprint of the data. 24. The method of claim 23, wherein the component is a checksum or fingerprint of the data. 27. The method of claim 26, wherein the search is performed using a search table to find the fingerprint or checksum. 28. The method of claim 27, further comprising searching for the checksum or fingerprint component.

Images