KR20030045666A - Directory searching methods and systems - Google Patents

Abstract

A method of arranging data in a relational database and searching a directory service database and system is provided. In particular, but not exclusively, systems and directories are provided for running or executing X.500 or LDAP services in a relational database. The present application includes a database arrangement that stores the data types in a table as components and retrieves the components for the desired data entry.

Description

DIRECTORY SEARCHING METHODS AND SYSTEMS}

Relational Database Management System (RDBMS) provides facilities for applications in storing and manipulating data. Among the many features provided by RDBMSs are data integrity, consistency, concurrency, index mechanisms, query optimization, recovery, rollback, and security. The RDBMS also provides a number of tools for performance tuning, import / export, backup, editing and development of applications.

RDBMSs are the preferred choice of most large data managers. RDBMSs are known to be readily available, reliable, and include many useful management tools. There is a foundation of many RDBMS facilities and therefore there is a large amount of existing expertise to implement these systems and investments in people and processes to implement these systems, so data managers can use them when acquiring new systems. Look forward to that. Most relational database products support the industry standard Structured Query Language (SQL).

There has also been a move towards object-oriented systems, which provides data scalability and the ability to handle arbitrarily complex data items. In addition, many companies and government departments have many database applications, but they are not compatible with each other. Data managers are looking for solutions that allow them to integrate their data and simplify the management of that data. Electronic directories provide data managers with the tools to achieve this goal. Some electronic directories are standardized. X.500 is the international standard [CCITT89 or ITU93] for electronic directories. These standards define a very flexible and general-purpose directory service, protocol, and information model. X.500 can be applied to information systems where data is fairly static (e.g., telephone directories), but is distributed (e.g. across organizations or countries), scalable (e.g., name, Storage of addresses, job names, devices, etc.), object-oriented (ie, applying rules on data) and / or remotely accessed. Electronic directories, such as X.500 and related standards, provide a framework and significant functionality that enable data managers to obtain their objects.

Typically, data managers have object-oriented electronic directories, such as X.500 directories, to enable systems to achieve the scaling possibilities and performance inherent in relational systems combined with the stability, robustness, mobility, and cost-efficiency of current SQL products. You have all the flexibility of the system, but want to do it using SQL products.

One example of an electronic directory implementation is described in US Serial No. 09 / 427,267 and its Australian counterpart 712451, both of which are incorporated herein by reference in their entirety. Within the search strategy for this implementation, at a conceptual level, hierarchical tables such as name, DIT and tree are used to maintain the relationships between objects in one hierarchy. These hierarchical tables are arranged along one column per object. Object tables, such as searches and entries, manage values within objects. These object tables are arranged along one column per value. Every object has a column corresponding to the hierarchical table, and every attribute value has a column corresponding to the object table. In this implementation, the object table used to retrieve the object contains columns of types (EID, AID, VID, Norm), where EID specifies the object to which the value belongs, and AID specifies the attribute type of that value. The VID specifies one of the possible number of attribute values in one entry, and the norm contains a syntax normalization value. Attribute tables, for example attributes, define gks information for attribute types. The attribute table used contains columns of the type (AID, SYX, DESC, object ID).

It has been known that improvements to electronic directory performance can be obtained to sort and search the database for complex data types.

Summary of the Invention

The present application relates to storing and / or retrieving a data form using some form of index, such as one of the components included in the stored data, a designator of the stored data, and / or manipulation of the stored data. Such implementation may, for example, generate component identifier (CID) information representing a single component and / or component value identifier (CVID) information representing components used for multivalued components or search. Complex data types by adding new search tables and / or attributes that store information related to the data entry by way of limitation, including but not limited to including information that is determined to be useful or useful for searching a particular entry in the database. Make the search easier. This new table, referred to herein as the subsearch table and / or the subsidiary table, contributes to storing the components of the values and facilitates the retrieval of single components and / or multivalued components. However, such a table may be referred to by any name.

In one embodiment, the present application provides a method of arranging data in a database. The method comprises the steps of creating a first table adapted to store data and to have one column for each data entry, and to store data components and to have one column for each component of the stored data type. Generating a second table adapted for the purpose.

The present application also provides a database and / or directory having a data storage arrangement. Throughout the rest of the specification, references are made to the database, but the same applies to directory service systems. A data storage array is directed to a hierarchy that defines the relationships between objects and is set up to have a single column for each object, or a table that is directed to an object that defines one or more values within each object, with one column for each value. A second table, a third table directed to the representation of one or more selected components or values and set to have one column for each component of each value. Preferably, the database is part of a directory service system, such as an X.500 or LDAP service system.

The present application also provides a method of searching a database for a given database entry. In this embodiment, the database stores a first table and a data component or representation adapted to store data and to have one column for each data entry and has one column for each component of the stored data. Has a second table adapted for that purpose. The search method includes determining a component or representation of a given data entry, executing one of the exact or initial matching on the second table to locate the component or representation, and the located component or representation Returning a given data entry that matches.

Throughout the specification, references to components may alternatively or additionally include a representation of a value, that is, an inverse index or pointer or fingerprint or checksum, or a suitable smaller representation of relatively large data. .

Preferred embodiments of the present application will now be described with reference to the accompanying drawings.

This application is a serial application of US Serial No. 08 / 793,575 (currently US Pat. No. 6,052,681), filed Feb. 28, 1997, filed at the national stage of International Application No. PCT / AU95 / 00560, filed Aug. 30, 1995. Some continuing applications (CIP applications) of No. 09 / 427,267, each of which are incorporated herein by reference in their entirety.

This application relates to the field of directory services. More specifically, the present application relates to applications in electrical directory services, such as X.500 or LDAP, table structures in database sorting used for searches in relational databases, and methods for database searches. Related.

1A illustrates the principle and conceptual design of an exemplary database in accordance with the present application.

1B illustrates a logical or physical design of an exemplary database in accordance with the present application including a subsearch table and an appendage table.

2 is a schematic representation of a higher order search method according to the present application.

3 is a schematic representation of a sub-order retrieval method according to the present application.

4 illustrates a corresponding example of an exemplary X.509 authentication and search and subsearch table.

5 illustrates an exemplary search and subsearch table associated with telephone number data component.

1A illustrates an exemplary implementation of a database design and is the only one form of database to which the methods and arrangements of the present application can be applied. A more detailed description of this database design can be found in US Serial No. 09 / 427,267, incorporated herein by reference in its entirety. Figure 1B illustrates a more detailed implementation of the database design of Figure 1A. In general, when searching a directory that contains a database, the search arguments are where the search begins (the base object), the scope (set) of the search, the conditions (filters) to apply to the search, and what information comes from the search. Defines what should be returned (optional). A filter is a combination of one or more filter items (or conditions) connected by operators such as AND, OR, and NOT.

For a general search service, filters are applied to values and attributes in object tables, such as search tables. An example of a typical filter is "NORM LIKE '% RICK HARVEY%'." For the advanced search service (described in more detail below), a clause can be added to an SQL statement that includes a component specifier, which refers to a specific component of the data type, and the correct or initial (ie starting) filter is searched. Applies to components in subsearch tables instead of tables. An example of such a clause is "AND CID = n" and an example of a correct filter is "NORM = 'RICK HARVEY'".

Referring to FIG. 1B, the table structure of the logical design 1 and the physical design 2 includes a lookup table 3, a subsearch table 4, an attribute table 5, and an appendage table 6. . The lookup table 3 and the lookup table 5 are similar to the lookup and lookup table described in US Serial No. 09 / 427,267 and will not be described in more detail here. The subsearch table 4 may be set to include one or more components used to improve the speed and reliability of the search. For example, the subsearch table 4 may include a CID field 7 and a CVID field 8. The CID field 4 acts as a tool (or index) for searching for components in the form of data, and the CVID field 8 acts as a tool (or index) for searching for multivalued components. Although the method according to the present application can be used with one or more of the above specified tables, each table is preferably provided such that there is a choice for a refinement search query.

The attribute table 5 describes or references the information in the lookup table 3, and the appendage table 6 describes or references the information in the subsearch table 4. The appendage table 6 has a field similar to the attribute table 5, but replaces the AID field 10 with a CID field 9. The CID field 9 is used to specify one or more components in the subsearch table 4.

The sub-search table 4 preferably stores components in the form of information or complex data that improve search performance. Other components stored in the subsearch table may be to improve the manageability of the database. In other words, it is not a requirement that all values in the data entry be included in the subsearch table.

2 and 3, a database search method will be described. Examples of search include base object and full tree search 11, one-step search 12 and subtree search 13. A more detailed description of this search can be found in US Serial No. 09 / 427,267. Searches with a range of base objects or the entire tree 11 use the lookup table 3. Searches that have a range of base objects or the entire tree 11 and can use stored components use the subsearch table 4. A search with a range of one step 12 uses a join between the DIT table 14 and the lookup table 3. The search, which has a range of one step 12 and can use the stored components, uses a combination between the DIT table 14 and the subsearch table 4. The search with the range of the booties 13 uses a combination between the tree table 15 and the lookup table 3. The search using the stored components with a range of booties 13 uses a combination between the tree table 15 and the sub-search table 4.

For illustrative purposes, if the desired search factor is structured with a general filter, the base object and full tree search 11 uses a lookup table 3, and the one-step lookup 12 is a DIT table 14 and a lookup table. (3), the Booty Search 13 will use the tree table 15 and the lookup table 3. An example SQL statement for such a search is:

SELECT EID {different column} FROM SEARCH {different table} WHERE {filter}

However, in such a search, if the applied filter is to be a component of a highly repeatable data string, part of a data string, or a structured data type, the database may be slow and inefficient because it must be examined in detail through numerous values.

One way to improve the efficiency of such a search is to search for one or more components associated with the stored data using a subsearch table. In such cases, the database can use indexes on components in strings or structures, thus avoiding scrutiny of numerous values. An example SQL statement for such a search is:

SELECT EID {different column} FROM SUBSEARCH {different table} WHERE {filter} AND CID = x

In this implementation, the base object and full tree search 11 uses the subsearch table 4, the one-step search 12 uses the DIT table 14 and the subsearch table 4, and the Booty search. (13) will use the tree table 15 and the sub-search table 43. In this example, the filter used will refer to components of the stored data, which will allow the use of indexes and result in faster and more efficient searches. The index used in this example includes CID = x.

Structured properties

The method according to the present application can be used for a variety of different applications. One application is the security area in which directories are being used by a growing number of Certification Authorities to store standardized certificates. One example of such a certificate is an X.509 certificate. Authentication such as X.509 can be called a complex attribute because they contain many components. However, the present application should not be limited to only this type of authentication. It will be appreciated that the present application may be used with any form of information having components.

When storing such a certificate, consideration should be given to how the certificate is stored so that retrieval of the certificate is quick and reliable (ie, the desired certificate is actually retrieved). The method and database alignment of the present application is obtained by finding and managing one or more components of the data in the authentication, such as serial numbers, expired data and issuers.

4 illustrates the application of the present application to X.509 authentication. Only a small part of each table is shown for clarity. The authorization 20 is shown schematically, for the sake of illustration only information such as the issuer in field 21, expiration information in field 22, serial number in field 23, field 24. Only version number, and topic information in field 25 (eg, rick harvey). For this example, the lookup table 3 is arranged in one column with spaces (preferably two) separating the normalized value of each component or field of authentication 20. The lookup table also contains a normalized value representing the full certificate. The subsearch table 4 is arranged with one or more columns 26, 27, 28, 29 and 30, where one column corresponds to one component or field in the authentication 20. However, it should be noted that the subsearch table 4 does not have to include all the fields specified in the authentication 20.

To illustrate the implementation for this embodiment, assume that a simple authentication consists of information similar to what a credit card has, such as a serial number, expiration date, and cardholder name. This simple authentication has three components or fields: a number field, a date field, and a string field. In this simple example, the normalized value of the certificate 20 to be stored in the lookup table 3 (in the form of FIG. 1B) is as follows:

(xx, yy, zz, "123456 20000806123000 RICK HARVEY")

And the sub-search table 4 may store, for example, three columns, one for each component of the authentication. Each column of the subsearch table will be in the form of FIG. 1B:

(xx, yy, zz, 0, 0, "123456")

(xx, yy, zz, 1, 0, "20000806123000")

(xx, yy, zz, 2, 0, "RICK HARVEY")

Where xx, yy and zz are integers corresponding to fields in a particular table design, such as EID, AID and VID.

Searches for certificates issued to "RICK HARVEY" using the lookup table (3) can use the following SQL statement:

SELECT ... FROM ... SEARCH ... WHERE AID = 27 AND NORM LIKE '% RICK HARVEY%'

Here the general filter is "NORM LIKE '% RICK HARVEY%'". However, using the lookup table 3 for such a search can be slow because each component of the string for each entry must be tested and the degree of certainty that the string is examined and searched is the desired entry. This is because monotonous expression has no boundary when it is an unstructured sentence expression.

If the subsearch table 4 is used when applying the correct or starting filter and component specifiers is applied to the search factor, the search for the certificate issued to "RICK HARVEY" will be more efficient. In this case, the following SQL statement can be used as follows:

SELECT ... FROM ... SUBSEARCH ... WHERE AID = 27 AND CID = 4 AND NORM = 'RICK HARVEY'

Where "NORM = 'RICK HARVEY'" is a filter, AID = 27 is an attribute specifier for authentication, and CID = 4 is a component specifier for the subject.

In the above example, a search with component designator (or index) CID = 4 is used because index CID = 4 is known from subsearch table 4 or subsidiary table 6, which is a string representing the cardholder name. A query with index CID set to 4 and filter "NORM = 'RICK HARVEY'" should return Rick Harvey's certificate. Queries are considered better because they can make the search faster and use an appropriate index that increases the degree of certainty that the correct certificate or certificates are found. It should be appreciated that the actual designation of letters / symbols or numbers in the subsearch table design is arbitrary and can be devised in any way to suit a particular application.

Referring again to Figure 4, an alternative implementation of the method according to the present application will be described. In this embodiment, the lookup table 3A is a lookup table arranged to contain a checksum or fingerprint. Since the lookup table 3A is used to exactly match any attribute type, such as binary, the value in the lookup table may be a fingerprint or checksum value. This makes the storage in the lookup table more efficient since there is less data needed to be stored.

String attribute

The present application may be used for non-complicated data types such as, for example, string data types. Examples of string data types include multiword sentences, multi-line sentence paragraphs, and multi-row postal addresses. In this case, the simple statement attribute value can be stored in a single column in the lookup table like this:

(1122, 33, 0, "MANY WORD SENTENCE")

Here, the column (or field) is defined as (EID, AID, VID, NORM). A query that retrieves a string data type for WORD would involve looking at a column for the partial word "% WORD%", which is considered a relatively slow search. To improve the retrieval of such data, the string is stored as a component in the subsearch table 4 so that the string "MANY WORD SENTENCE" will be stored in three columns:

(xx, yy, zz, 0, 0, "MANY")

(xx, yy, zz, 0, 1, "WORD")

(xx, yy, zz, 0, 2, "SENTENCE")

Here, the columns are defined as (EID, AID, VID, CID, CVID, NORM), respectively. In this example, the applied filter will use the subsearch table (4) instead of the lookup table (3) and the following SQL statement can be used to search for "WORD":

SELECT ... FROM SUBSEARCH ... WHERE AID = 33 AND CID = 0 AND NORM = "WORD"

The result will be a faster search because you are searching for the exact match of "WORD" rather than searching for the partial word "% WORD%" as described above.

Selective index

The present application also has general applicability to the problem of adding one or more indices to a given attribute for the purpose of improving performance for some form of query. Adding an index provides a different path to find an attribute, for example an inverse index. In this case, only one component may exist in the subsearch table. In fact, a component represents an optional form of its attribute value.

In particular, the subsearch table stores the inverse of the values and thus has the effect of having an inverse index on the attribute, so that problems with "ends in" searches or the initial part of the stored data (such as distinguished names, MAC addresses, Addressing a relatively fairly repetitive value (such as a telephone number, fully qualified filename, etc.) can be addressed. For example, referring to FIG. 5, telephone number 31 is stored in lookup table 32; The telephone number is also put in the sub-search table 33 in reverse form. Of course, this feature of the application is not limited to the inverse form, but may be any other suitable form of data entry appropriate for a given situation or search, such as, for example, treating the area code of a telephone number as a separate component.

When searching for a telephone extension, typically the end of a telephone number, the search can be expressed as a string search for "* 1234" (wildcard is an asterisk). If only the lookup table 32 is used, the execution of the lookup can be slow because the index is only possible for "starting" or "exact" searches. However, with the attributes stored in the subsearch table 33 conversely, the subsearch table can be used to perform a corresponding search, for example "4321 *", which is considered very fast.

More specifically, lookup table 32 may store phone numbers for a given person as:

(1122, 44, 0, "98791234")

Then, it will be stored in the subsearch table 33 as follows:

(1122, 44, 0, 0, 0, "43219789")

And, the SQL command to find a phone number ending in "1234" can be of the form:

SELECT ... FROM SUBSEARCH ... WHERE AID = 44 and CID = 0 and NORM LIKE '4321%'

Searching the subsearch table 33 should bring up the desired record faster than searching the search table 32, which means that the search is for an initial match (i.e. starting with) for "4321", which is a faster search. Because it is.

Another example of an optional index is to store a checksum of a binary value, for example a picture or voice.

Another example of an optional index is to store fingerprints, which are smaller representations of data, such as smaller representations of photographs.

Although the present application has been disclosed with reference to an X.500 directory service system, the present application should not be limited to the systems and methods disclosed herein. As will be understood from reading the specification as a whole, the present application can be applied to or implemented in numerous other directory service systems, and can use a variety of methods.

Claims (28)

In a method of arranging data in a database, Creating a first table adapted to store data and have one column for each data entry; And A method of arranging data in a database, the method comprising storing a data component and generating a second table adapted to have one column for each component of the data. The method of claim 1 wherein the data is in the form of structured data. The method of claim 1 wherein the data is in the form of string data. The method of claim 1, wherein the data is or represents an X.509 certificate. The method of claim 1 wherein the component of data is a checksum or fingerprint. The method of claim 1 wherein the database is part of an electronic directory service system. 7. The method of claim 6, wherein the electronic directory service system comprises an X.509 and LDAP service system. A lookup table comprising at least one column having a plurality of columns; And A database with a data storage array that includes a lookup table that includes at least one column having a plurality of columns including component specifier columns. The method of claim 8, wherein the columns of the lookup table are of the form "EID, AID, VID, Norm", where EID is the object to which the value belongs, AID is the attribute type of the value, and VID is the number of possible attribute values in an entry. Database, characterized in that one. The method of claim 8, wherein the columns of the lookup table are of the form "EID, AID, VID, CID, Norm", where EID is the object to which the value belongs, AID is in the form of an attribute of a value, and VID is a number of possible attributes in an entry. One of the values, wherein the CID is a component specifier. 10. The database of claim 8, further comprising a subsearch table comprising at least one column having a plurality of columns in which a description or reference to the subsearch table is provided. 12. The database of claim 11, wherein the columns of the subsearch table are in the format "CID, SYN, DESC, OBJECT ID, FLAGS". A first table directed to a hierarchy defining relationships between objects and having one column per object, a second table directed to an object defined to define one or more values within each object and having one column for each value And a third table directed to one or more selected components of the value and set to have one column for each component of each value. A first table arranged to store data, a first table having one column for each data entry; And A directory service system for performing a directory service request in a database comprising a second table arranged to store data components, and a second table having one column for each component of data. 15. The directory service system of claim 14, wherein the data is in the form of structured data. 15. The directory service system of claim 14, wherein the data is in the form of string data. The directory service system of claim 14, wherein the directory service system is X.500 or LDAP. A first table for a hierarchy defining relationships between objects and having one column per object, a second table for an object defined to define one or more values within each object and having one column for each value, and A directory service system having a data storage arrangement comprising a third table for one or more selected components of a value, the third table being set to have one column for each component of each value. 19. The directory service system of claim 18, wherein the data is in the form of structured data. 19. The directory service system of claim 18, wherein the data is in the form of string data. The directory service system of claim 18, wherein the directory service system is X.500 or LDAP. A method of searching a database for a given data entry, The database includes a first table adapted to store data and to have one column for each entry, and a second table adapted to store data elements and to have one column for each component of data. Has a table, and the method Determining a component of a given data entry; Executing one of the correct or initial matching on the second table to locate the component; And Returning a given data entry that matches the located component 23. The method of claim 22, wherein the database is part of an electronic directory service system. 23. The method of claim 22, wherein the electronic directory service system comprises an X.500 or LDAP service system. 23. The method of claim 22, wherein the data is or represents a X.509 certificate and / or checksum of 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 lookup table to locate a fingerprint or checksum. 28. The method of claim 27, further comprising retrieving a component of a checksum or fingerprint.