KR20010034516A - Method and system for typesafe attribute matching - Google Patents

Abstract

The present invention discloses a database system in which one or more entry databases store a plurality of entries. Each entry is of a type that defines a field of the entry. Each field includes or identifies an object with associated attributes or data. Each entry type can define an action in the form of a method that the entry can implement. An entry type, which is a subtype of another entry, inherits all fields, and the behavior of its supertype, includes additional fields and / or defines new / modified behavior. Entries may be expressed in the Java ^TM programming language. The database system may use a search engine that allows for querying entries in the database. In one embodiment, the query includes a read operation, a take operation, and a notification operation. Each query request includes a template, which is an entry object having instructions indicating the type of operation, and some or all of its fields set to specific values that must be matched correctly. The other fields of the template entry must be specified as wildcards whose values do not matter. The search engine may be configured to generate an index for caching entries with properties commonly specified by the query. In one embodiment, the database may also store a set of entries and perform operations on them. Incidentally, by associating attributes with the fields of the entry, the system can achieve typesafe attribute matching.

Description

Type safe attribute matching method and system {METHOD AND SYSTEM FOR TYPESAFE ATTRIBUTE MATCHING}

Database systems are becoming increasingly important in today's society. The amount of data that can be stored by typical database systems is growing rapidly, and it is important to provide fast and flexible access to the data. However, designing a database system that performs optimally is difficult.

A particularly important consideration in database design is to store the data so that it can be used for a variety of applications and the way it can be used can be changed quickly and easily. It is also desirable to allow data types or categories to be added without significantly affecting other parts of the database system.

Unfortunately, in many database systems it is extremely difficult to change the way data is used and organized and to enable additional data types and categories. Modifications can result in a chain reaction of changes to programs and other components of the database system, and therefore can be expensive to achieve. After all, data processing tends to harden into its old data structures. Incidentally, the designer of the database system tends to make a lot of tradeoffs between the design and the features of the others, resulting in less than optimal design.

To be more sophisticated, storing information in a database system is often done by the correct type: records stored in the database system are typically of random numbers, and fields such as tuples in the relationships of the relational database. Has a type. Each field may be defined to store a particular type of data, such as string data, integer data, Boolean data, or some other data type as needed. If the user wants to look up information in the database, the user must look up the correct record type (ie, different types of records are typically retrieved independently). Thus, if the searcher is present in any type of record of some other type, the searcher must know in advance which record type exists or have an explicit way of requiring all types. do. The searcher then needs to examine all the possible record types explicitly to find a particular record. This complicates the software associated with the search engine and can actually limit the number of different record types that can be maintained.

Also, fields in a record in the database typically do not refer to other records. This reduces the amount and type of information that a single record typically holds. After all, databases are limited by their inability to store and manipulate records, which are sets of records.

Incidentally, records in a typical database are often not associated with any characteristics other than the actual data on their own. For example, if data is found, any method that associates the behavior with records that vary by record type and allows the program to use the various records returned by the match in a simple way to achieve record type-specific results. does not exist.

With respect to other features of the database system, a common way of specifying attributes or properties in a database is by a simple set of <name, value>, where values are limited by strings or any type (type, "any ")to be. There is no way to limit the type in these <name, value> pairs, and therefore there is no rule that a particular name must always have a value of a particular type. For example, in a hypothetical printer, the "speed" attribute, which indicates how many pages per minute the printer can print, is to ensure that the user can set it to some extent, such as "about 10 ppm" or "8 to 10". Must be implemented as an integer. The same kind of problem exists if the values can be any type of object. In this case, the user can set the attribute to an integer object instead of a string object, but still prevents other users from incorrectly storing the string object as an attribute that should only be set to an integer.

Moreover, the previous system does not have any rules for the relationship between different attributes (ie, if one attribute must exist and if another attribute exists). For example, suppose there are three exemplary attributes for a printer: resolution (dots per inch), speed (pages per minute), and color (black and white). In fact, many printers have many different combinations of these attributes. Can be done. For example, a typical color printer can be described as follows:

5 pages per minute at 600 dots per inch in black and white;

7 pages per minute at 300 dots per inch in black and white;

1 page per minute at 300 dots per inch in color.

On the other hand, if a given attribute has multiple values, some conventional systems allow the attribute to have multiple values, and these systems may represent a given attribute as follows:

Speed = {1,5,7}

Resolution = {300,600}

Color = {true, false}

However, this does not represent an interrelationship between attribute pairs. That is, there are no expressions and rules of the three interrelationships:

{Speed: 1, Resolution: 300, Color: True}

{Speed: 7, Resolution: 300, Color: False}

{Speed: 5, Resolution: 600, Color: False}

Accordingly, it would be desirable to provide a database system that allows polymorphic entries, entry matching and manipulation, including a set of entries, to allow for more efficient retrieval and to enable simple software implementations with many different types. It would also be desirable to provide a system in which entries can define their own behavior depending on the type. Thus, it is desirable to have a type-safe attribute matching and relationship rule between attributes in a database system.

The present invention relates to a database system, and more particularly to entry storage in a database system. The invention also relates to query matching methodologies used in database systems.

1 is a distributed computer system using a database system according to the present invention.

2 illustrates exemplary communication between a plurality of clients and a plurality of entry databases in accordance with the present invention.

3 illustrates some entries each containing a particular type of field and an entry that is a subtype of another entry in accordance with the present invention.

4 illustrates various operations supported by a database system in accordance with the present invention.

5 illustrates an exemplary template entry in accordance with the present invention.

6 is a flow diagram illustrating one embodiment of a method for retrieving an entry in a particular entry database in response to a read request or take action in accordance with the present invention.

7 is a block diagram illustrating characteristics of a database system according to the present invention.

8 is a flow chart illustrating an implementation of a search method for processing a notify request in accordance with the present invention.

9A and 9B illustrate an implementation of an indexing method according to the present invention.

10 illustrates several multi-entries each with a field containing entries.

11 illustrates various multi-entry operations supported by a database system in accordance with the present invention.

12 illustrates an exemplary multi-template in accordance with the present invention.

13 is a flow chart illustrating a database search method for multi-entry in accordance with the present invention.

14 is a functional diagram illustrating characteristics of a database system relating to an example of multi-entry search in accordance with the present invention.

15 is a flowchart illustrating an implementation in accordance with the present invention of a search method for processing a notification request for multi-entry.

Figure 16 illustrates various operations for modifying in-place entries and multi-entries in a database in accordance with the present invention.

Figure 17 is a flow chart showing the steps of a single entry modify operation in accordance with the present invention.

18 is a flow chart illustrating the steps of a multi-entry add operation in accordance with the present invention.

19 is a flow chart illustrating the steps of a notification operation for an in-place modification operation in accordance with the present invention.

20 is a flow chart illustrating the steps of a notification operation for use in an in-place modification operation in accordance with the present invention.

Although the present invention may take various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and will be described in detail. However, the drawings and detailed description of the invention are not intended to limit the invention to the particular forms disclosed, but instead the invention is intended to cover the modifications, equivalents and equivalents of the invention as defined by the claims. To embrace substitution.

The problem is solved by a method and system for storing and retrieving entries in a database according to the invention. In one embodiment, the computer system implements a database system in which one or more entry databases store a plurality of entries. Each entry is of a type that defines a field of the entry. Each field includes or identifies an object with associated attributes or data. Each entry type can define an action in the form of a method that the entry can implement. The other subtype, the entry type, inherits all fields, and the supertype's behavior, includes additional fields and / or defines new / modified behavior. Entries may be expressed in the Java ^TM programming language. Similarly, in one embodiment, each field is represented by a defined class.

The database system may also use a search engine that allows for querying entries in the database. In one embodiment, the query includes a read operation, a take operation, and a notification operation. Each query request includes a template, which is an entry object having instructions indicating the type of operation, and some or all of its fields set to specific values that must be matched correctly. The other fields of the template entry must be specified as wildcards whose values do not matter. Polymorphic entry and entry matching techniques are advantageous, allowing queries to be made that can be entries of the same type as the template entry or a subtype of the template entry. This enables efficient search and simple implementation of the search engine. Moreover, the search engine does not need to know all possible subtypes that may exist. Finally, because each entry has an associated class, an entry can define its own behavior by supporting one or more methods. The methods of a particular entry can be called by programs that implement various functions, such as equivalence checking.

The search engine may be configured to generate an index for caching entries with properties commonly specified by the query. That is, the search engine may detect the usage pattern and generate an index that points to an entry having attributes commonly specified by the received template. As such, a convenient entry search can be achieved.

Incidentally, the search engine may also be configured to store a set of entries in a single record. These sets of entries are matched using a set of templates. In one embodiment, by associating an attribute with a field of an entry, a database system that utilizes entry matching and matching of entry of entries can achieve type-safe attribute matching. Type-safe attributes allow a database system to protect the type of an attribute and to strengthen the relationship between different types of attributes.

The method and system according to the present invention stores and retrieves entries in a database. Each entry is a certain type that defines fields of a type, and each field contains or identifies an object of a certain type. These entries can be expressed in the Java ^TM programming language. Incidentally, the method and system according to the present invention can also store and retrieve a set of entries in a database. In general, these searches are performed using a set of templates. In one embodiment, the attributes are associated with fields of the entry. This association enables type-safe attribute matching and strengthening relationships between the types of different attributes.

Distributed system

Referring now to FIG. 1, FIG. 1 shows a distributed system 100 utilizing entries, entry matching, and entry manipulation in accordance with the present invention. 1 illustrates a plurality of computer systems 101-103 interconnected by a network 105. Network 105 shows a local area network (LAN), a broadband network (WAN), or the Internet, for example, among other possible communication channels. Each computer system includes microprocessors and memory, such as the exemplary memory 120 and the CPU 122 of the computer system 101. Memory 120 represents various possible memory types, such as hard disk storage, floppy disk storage, and dynamic random access memory (DRAM). Installation media 126 is shown associated with computer system 101 that represents one or more CD ROM or floppy disks (or other storage media). Generally speaking, installation media 126 may store code and / or data that implements portions of a search engine and other features of a database system described below and may be used to install code and / or data within a particular computer system. Can be. In another embodiment, the database system according to the present invention may be implemented within a single non-network computer system.

As will be described in detail below, computer system 100 implements a database system using an object-oriented technique for storing entries of possible types or subtypes. The database can also store a set of entries, called multi-entries, as described after a single entry implementation. Entries in the database may be stored entirely in memory 122 of computer system 101 or may be distributed across memory of several different systems, such as memory 122 and similar memory of computer systems 102 and 103. . Each entry is a certain type that defines the fields of the entry. Each field contains or identifies an object associated with an attribute or data. Each type of entry may also define an action in the form of a method that the entry is configured to implement. An entry type, which is a subtype of another entry, inherits all fields and the behavior of that subtype, and includes additional fields and / or defines new and modified behavior.

The database system also utilizes a search engine, which can be implemented in software that allows for querying entries (or multi-entries described below) in the database. In one embodiment, each entry includes a template that specifies the value (or attribute) of the key field of a given entry that matches the corresponding field of the template that is successfully matched. Other fields of the template entry may be specified as wide cards whose values do not matter. The polymorphic entry and entry matching technique used by computer system 100 is advantageous in that queries can be made that can be of the same type as the template entry or a subtype of the template entry. Additional details regarding the polymorphic entry and entry matching technique are provided in detail below with reference to FIGS. 2-9.

2 is a diagram illustrating an exemplary communication flow between a pair of clients (or users) 202 and 204 and a plurality of entry databases 206-208. Each of the entry databases 206-208 may be distributed across one or more memory subsystems of the distributed system 100. Each client 202 and 204 is configured to generate a query that can be provided to one or more entry databases 206-208. Clients 202 and 204 may also be configured to store (write) entries in entry database 206-208 as described below. 2 finally shows an event catcher 210 as its function is described in detail below.

Entry Matching and Behavior

3 is a diagram illustrating a plurality of example entries that may be stored in any entry database 206-208. In one embodiment, each entry is a Java ^TM class of Java ^TM programming language. The Java ^™ programming language is described in Ken Arnold, James Gosling The Java ™ Programming Language (Addison-Wesley Publishing, 1996), which is incorporated herein by reference. Java ^TM is a registered trademark of Sun Microsystems, Inc. in the United States and other countries. However, in other embodiments, entries may be defined in classes of other programming languages.

Entry 1 of FIG. 3 illustratively includes a set of four fields (field A, field B, field C and field D) defined by the class type of entry 1. FIG. Entry 2 contains a set of five fields (field A, field B, field C, field D and field E) defined by the class type of entry 2. Note that entry 2 is a subtype of the type of entry 1 because entry 2 contains the same field type as entry 1 in addition to the others.

Entry 3 contains four sets of fields (field W, field X, field Y and field Z) defined by the class type of entry 3. Although entries 1 and 3 each contain four fields, it should be noted that they represent different types because they cannot identify the field type.

As many different types and subtypes can be associated with the database system, depending on the requirements of a particular application or database. Incidentally, it should be noted that entries that are subtypes of the subtype are possible. For illustrative purposes, the following code shows example specific entries defined in the Java ^TM programming language.

"Request For bid" object for book purchases:

public class RFB implements Entry {

public Integer order number; 구매자 Buyer's tracking number for this order

public String title; 의 Title of this book

public Integer count; ＼＼ The required number of turns

}

"Full" request for auction, including ISBN

public class FullRFB extends a RFB {

public String isbn; ＼＼ ISBN field title

}

Referring again to FIG. 3, each of the fields of the entry is configured to store values that indicate or identify typed objects. Each of these typed objects can similarly be represented in the Java ^TM programming language. For example, field A of entry 1 includes a value identifying object 310, and field B of entry 1 identifies object 312. Similarly, field A of entry 2 identifies object 314 and field B identifies object 316. etc. For the example entry of FIG. 3, since entry 2 is a subtie of entry 1, the object 310 associated with field A of entry 1 is the same class type as the class type of object 314 associated with field A of entry 2. Is represented by. However, the attributes and data associated with each of the objects 310 and 314 may be different. The objects identified by the fields of the various entries may also include integer data, Boolean data, string data, or other data types, as needed, depending on the defined type. In addition, because each field is associated with a typed object, methods may be supported and optionally invoked via external stimuli as needed to perform operations on the data. Similarly, each entry type may support one or more methods, as described in detail below.

Referring again to FIG. 2, as described, each of the entry databases 206, 207, and 208 can store countless entries of various types of subtypes. Entries may be stored in a given entry database 206-208 via a write operation called by the client. The entries may additionally be provided to the entry database via an installation media word (ie, installation media 126 of FIG. 1).

As shown by FIG. 4, several operations are supported by the system. In particular, in addition to the write operation, the client or user may initiate a "read" operation, a "take" operation and a "notify" operation.

Read, take, and notify operations are each used to determine whether an entry with any specified characteristics has been written to the entry database, and if so, to query a particular entry database to cause a particular action. In a particular embodiment, these queries are made through the use of a template that is included as part of an action request that defines the type of entry of interest with respect to the action. The take operation is similar to the read operation, but the take operation will remove entries that match the template from the entry database. Finally, the notification operation registers an interest in an incoming future entry of the specified entry database that matches the associated template. When a matching entry arrives, the client or the specified event catcher is notified. Further details regarding each of these operations are described below.

5 illustrates an example template. Generally speaking, a template specifies a particular entry type that a field can have values (reference to an object) or "wildcards". When considering a particular entry in the entry database as a potential match for a template, the attributes of the specified fields of the entry (ie, fields that do not correspond to the wild fields of the template) are specified by the corresponding fields of the template (or possible attributes). Must fall within the scope of. The field of the entry corresponding to the "wildcard" field of the template may have any attribute and does not affect the result of the match (ie, a wildcard in the template that matches any value in the same field of the entry). In one embodiment, wildcards are specified as null reference values. As described below, the type of entry matching the template may be a subtype of the type of template. That is, all fields of a particular entry defined by a subtype are considered wildcards. This allows the template to match an entry of any subtype. Note that an entry without any wildcard can be a valid template.

6 is a flowchart illustrating one embodiment of a method for retrieving entries in a particular entry database in response to either a take operation or a read operation in accordance with the present invention. As described above, the read request may be initiated by a client (or user) reading an entry that matches a given template. The take request may be initialized to remove entries that match a given template from the entry database.

(1) Entry matching method

The steps shown in FIG. 6 will be described with reference to FIG. 7 showing the functional features of the database system using the search method of FIG. The functional components of FIG. 7 may be implemented through a combination of software and hardware associated with one or more computer systems 101-103 of FIG. 1. During step 602, a read or take request is provided from the user 702 to the database manager 704. The predetermined request will include the specified template, which is illustratively shown as the template 706 of FIG. The search engine 708 of the database manager 704 then searches the entry database 710 during step 604 to determine whether a matching type or subtype of template exists in the entry database 710. . If no entry in entry database 710 is the same type or subtype of template (step 606), database manager 704 will return a null value to user 704 (step 608).

If the search engine 708 determines that there is more than one entry in the intra database 710 that matches the type or subtype of the template, the field of the selected entry (of the same type or subtype) is not specified as a wildcard. And compare with the corresponding field in template 706 (step 610). The search engine 708 ignores any field of the selected entry that corresponds to the wildcard of the template (step 612). In one particular embodiment, search engine 708 determines whether the attribute or data associated with each non-wildcard field of the entry exactly matches the attribute or data of the corresponding template entry. If an attribute of any field that is not a wildcard field does not exactly match the attribute of the template, then it is determined whether no match has occurred for that entry. In other embodiments, it should be appreciated that a field in a template may specify a range of values (rather than requiring an exact match) that the data of the corresponding field should not match.

(2) yes

In the example shown by FIG. 7, field C of template 706 is specified as a wildcard. Thus, if search engine 708 searches the entry database 710 to find an entry that matches, the search engine 708 first searches for an entry in the entry database 710 that is a type or subtype of the template 706. Determine if it exists. As shown, both Entry 1 and Entry 2 meet this qualification. The search engine 708 then selects one of these entries (such as entry 2 as shown) and compares the field of entry to the field of the template that is not specified as a wildcard. Search engine 708 determines whether an exact match for each non-wildcard field of the template occurs for an attribute of each of the corresponding entry fields. Since field C of template 706 of FIG. 7 is specified as a wildcard field, the attribute of field C of entry 2 is not ignored and does not affect the comparison operation. Similarly, the fields of any entry defined by the template type subtype are ignored (ie, matching may occur even if the attributes of the wildcard field match). If a match entry is found (all non-wildcard fields match), search engine 708 reads the match entry from entry database 710 and provides it to the user or whether the request is a read or take request. Accordingly, the entry is removed from the entry database 710. Search engine 708 searches entry database 710 until a match is found or until all entries are checked. If no matching entry is found after searching all entries in the database, the database manager 704 returns a null value to the user 702 (step 616).

(3) Notice

Referring next to FIG. 8, a flow diagram illustrating one embodiment of a method performed by search engine 708 to process a notification request entered from a user in accordance with the present invention. As discussed above, a notification request may be issued by a user to register an interest in a future incoming entry that matches a template. When a matching entry arrives, the database manager notifies the user or event catcher as needed (Figure 2). When a user invokes a notification request, a lease time is specified that indicates how long database manager 704 has registered for notification. After the specified time has elapsed, the notification registration is canceled.

As such, as shown in FIG. 8, when the database manager 704 receives a new notification request (step 802), an incoming entry is monitored until the registration time expires (steps 804 to 806). If the entry is written to the entry database 710 that is a type or subtype of the template (step 808), the fields of the entry are compared to determine if the attribute matches the non-wildcard field of the template (see step 808). Step 810). Similar to the previous description, the fields of the incoming entry defined by the wildcard or subtype of the template entry are ignored (step 812). If a match occurs, the user or event catcher is notified (steps 814 and 816). Incidental incoming entries will continue to be monitored as long as the registration time has not expired.

(4) indexing

Referring again to FIG. 7, search engine 708 may be configured to generate an index for entries having characteristics commonly specified by a query received by database manager 704. That is, the search engine 708 can detect the usage pattern and use the index 720 pointing to an entry having attributes commonly specified by the received template. As an example, assume that the database manager 704 receives several query requests using templates that are each the same type or subtype of the template 706 shown in FIG. In this situation, search engine 708 may detect that the same attribute value for field A, such as an integer value of 1,000, is specified in each of the templates of numerous requests. In one embodiment, database manager 704 Is the same type or subtype of template commonly received in response to detection of a common template usage specified by many queries, and is an index that points to all entries in the entry database 710 that all have a common attribute specified for each field A In turn, if a new query with a similar template is received (i.e., a template specifying a value of 1,000 again for field A), the search engine 708 uses the index 720, Quickly find a subset of entries that can match a template without searching all sets of entries in the database.

An implementation of the indexing method is shown in FIGS. 9A and 9B. As shown in FIG. 9A, an index into an entry corresponding to a particular template categorizer tracks the request template (step 910), and the pattern associated with the template (ie, the specific non-wildcard field (or fields) is the same. It can be generated by determining whether it is specified as an attribute or a value This determination can be made, for example, based on receiving a number of selected queries within a certain time having a similar template or any of the queries having a similar template. Can be determined based on receiving a percentage, if search engine 708 detects a common template usage pattern, it generates an index for an entry that is a particular template category, step 914. Thus, given the above example, a search Engine 708 may generate an index for all entries of the same type or subtype as template 706 with a field A value of 1,000.

As shown in Figure 9B, if a new request is received during step 920, a normal search is performed as to whether an index exists for a particular template category (steps 922 and 924). If an index category exists for the template of the new request, the index is used to find a subset of the potentially matching entries and compare only those entries. As such, a convenient entry search can be accommodated. Next, it should be appreciated that search engine 708 may remove any index as needed if common usage is no longer detected.

As mentioned above, an entry type may additionally define a method that can be called by an external stimulus (ie, a software program associated with the database system processing the entry) to cause a particular action to occur. This particular behavior may affect the data present in the entry. Incidentally, even if the format of the data is different, a method may be used that allows an efficient equivalence check to determine whether a particular entry is equivalent to another (or equivalent to a template) entry. For example, an entry that stores compressed video data may be considered equivalent to another entry that stores a compressed format of video data. Even if the data actually stored is different (i.e., a method can be called that determines whether the object refers to the same subpath name in the file system associated with the image), a method can be provided for determining such an entry equivalent.

In addition, it should be appreciated that an entry may be stored in an implementation specific representation that includes the class of the entry and the serialized form of each field of the entry. The serialized form of the template can then be compared to the serialized form of the entry. Finally, it should be understood that an entry can be specified by a field of another entry.

Multi-Entry and Multi-Template Matching

Alternate embodiments implement the operation and matching of items in a database where each item defines a set of entries. "Item" refers to "multi-entry" in the present invention, and "Multi-Template" (or "Item Template") is used to refer to a set of templates used to match items in a database. Term. This section will describe operations involving multi-entry to multi-templates, and multi-entry and multi-templates. Most of the behavior of multi-entry and multi-templates is similar to single entry and template behavior as described above.

10 is a diagram illustrating an exemplary plurality of multi-entries that may be stored in any entry database 206-208. In the method and system according to the present invention, each multiple-entry is a group of entries, and each entry might, for example, a group type of the object represented by a Java ^TM class of Java ^TM programming language. In other words, a multi-entry is a set of entries and does not have its own type.

Referring to FIG. 10, multi-entry 1 illustratively includes a set of four elements (element A, element B, element C and element D). Whereas multi-entry may be of variable length, exemplary multi-entry 2 includes a set of five elements (element E, element F, element G, element H and element I), and exemplary multi-entry 3 It contains three elements (element J, element K and element L). Each of the elements of the multi-entry is configured to store a typed entry. As mentioned above, each of these typed entries may be represented by a Java ^TM class, and the fields of the entry store values that identify the typed object. For example, element A of multi-entry 1 includes a value identifying entry 1010 and element B of multi-entry 1 identifies entry 1012. Similarly, element B of multi-entry 2 identifies entry 1014 and element F identifies entry 1016. etc. In the example multi-entry of FIG. 10, although any entry may be of the same type, the attributes or data associated with the field of the entry may be different. Although entries identified by elements of various multi-entries may have a particular type, it should be understood that multi-entries are simply a set of entries and do not themselves have a specific type.

Since multi-entry and multiple elements are set up directly, they can be represented using any suitable set of representations. For illustrative purposes, in many programming languages, including the Java programming language, a suitable representation is an array, where the size of the array is given by the number of entries in a multi-entry or the number of templates in a multi-template, each element of the array being Either an entry (for multi-entry) or a template (for multi-template).

Referring again to FIG. 2, as described above, each of the entry databases 206, 207, and 208 can store numerous multi-entries. Multi-entries may be stored within a given entry database 206-208 via a write operation called upon by the client. Multi-entries may additionally be provided to the entry database via the installation medium (ie, installation medium 126 of FIG. 1). As shown in FIG. 11, some additional operations similar to single entry operations are supported by the system. In particular, in addition to the write operation, the client or user may initiate the "read" operation, the "take" operation, and the "notify" operation.

Read, take, and notify operations manipulate multiple-entries in the same way that they manipulate a single entry. In one particular embodiment, such a query is made by using a multi-template included as part of an operation request that defines which multi-entry is problematic with respect to the operation. As in the single entry implementation, the read operation reads multi-entries in the database that match a given multi-template. Once again, the take operation performs the same operation as the read operation but also removes any multi-entry read from the database. The notification action used to register an interest in a future multi-entry notifies the client or event catcher when a matching multi-entry arrives in the database.

12 illustrates an example multi-template. Generally speaking, a multi-template specifies a particular multi-entry whose element contains a template previously defined. In the multi-template 1200 shown in FIG. 12, the multi-template may have any number of elements, but in an exemplary embodiment of the present invention, each element in the multi-template 1200 may be configured to have one template 1202. Even though it is included, it has four elements, W, X, Y and Z.

(1) Method for multi-entry and multi-template matching

In general, a multi-template will match a multi-entry if each template in the multi-template has a matching entry in the multi-entry. Each entry in the multi-entry may be used to match more than one template in the multi-template. For example, a single entry in a multi-entry can match all templates in a multi-entry, resulting in a match between a multi-entry and a multi-template. In the process of determining whether a multi-entry matches a multi-template, it is necessary to compare the individual entries of the multi-entry with the individual templates in the multi-template. Matching individual templates in such multi-templates to individual entries in the multi-entry is performed in the same manner as matching single entries to a single template as described above.

FIG. 13 is a flow diagram illustrating one embodiment of a method for searching for multi-entries in a particular entry database in response to either a read request or a take request. The steps shown in FIG. 13 will be described in conjunction with FIG. 14 showing the functional characteristics of the database system using the search method of FIG. The functional component of FIG. 14 may be implemented through a combination of software and hardware associated with one or more computer systems 101-103 of FIG. 1. During step 1302, a dominant or take request is provided from the user 702 to the database administrator 704. The predetermined request will include a particular multi-template, the example of which is shown as multi-template 1200 of FIG. 14. The search engine 708 of the database manager 704 then searches the entry database 710 to determine if there is any matching multi-entry of the multi-templates in the entry database 710.

To search the entry database 710, the search engine 708 selects a multi-entry in the entry database 710 and compares it to a predetermined multi-template (step 1304). Next, to determine if the multi-entry matches the specified multi-template, search engine 708 compares each template in the multi-template to an entry of the multi-entry (step 1306). If there is a matching entry for each and every template in the multi-template, then the multi-entry matches the multi-template (step 1308). Entries in the multi-entry may be used to match one or more templates in the multi-template. If all templates in the multi-template have matching entries in the multi-entry (step 1310), the multi-template matches the multi-entry and the multi-entry is returned (step 1312). This process continues until all entries in the database have been examined.

If a match is found between the selected multi-entry and the multi-template supplied by the operation, search engine 708 searches for another multi-entry in entry database 710 (step 1314). If no multi-entry matching the multi-template is found in the database, a null value is returned (step 1316). In one embodiment, if more than one is found, one multi-entry is returned, and in another embodiment, the number of requests of matching multi-entries is returned. If the original request from the client arrives in the form of a take request, the matching multi-entry is removed from the database. However, if the original request arrives as a read request, the matching multi-entry is removed from the database.

(2) yes

In the example shown by FIG. 14, search engine 708 selects one of the multi-entries (such as multi-entry 2 as shown) and converts the entries of this multi-entry into entries of the multi-template. Compare to template. In this example, search engine 708 receives a request that includes multi-template 120.

Search engine 708 determines whether a template in multi-template 1200 matches a selected multi-entry in entry database 710. Search engine 708 compares the template in element W of multi-template 1200 to entries in elements E, F, G, and H of multi-entry 2 in entry database 710 so that any entry Determine if it matches. If search engine 708 finds a match for a template in element W of multi-template 1200, then it may attempt to find a match for template in element X of multi-template 1200. This will again compare the template in element X of multi-template 1200 to each of the entries in multi-entry 2 until a match is found. Although each of these entries in elements E, F, G, H and I may have been compared to another template in the multi-template (ie, template in element W), they can be compared back to this template. If a match is found for a template in element X, search engine 708 checks the remaining templates in multi-template 1200 (templates in elements Y and Z) in the same manner. Since each entry can be compared to one or more templates, for example, an entry in element E of multi-entry 2 matches all templates in elements W, X, Y, and Z of multi-template 1200. If each template in the multi-template 1200 has a matching entry in multi-entry 2, then multi-entry 2 matches the multi-template 1200.

As with a single entry operation, if a matching multi-entry is found, the search engine 708 reads or removes the matching multi-entry from the entry database 710 and determines whether the request is a read or take request. Provide it to the user accordingly. Search engine 708 continues to search entry database 710 until a match is found or all multi-entries are checked. If no matching multi-entry is found after searching all multi-entries in the entry database 710, the database manager 704 returns a null value to the user 702.

(3) Notice

Referring next to FIG. 15, shown is a flow chart illustrating one embodiment of a method performed by a search engine 708 that handles a notify request received from a user. The notification operation works similar to the notification for a single entry, and as described above, a notification request can be issued by a user to register an interest in an incoming future multi-entry that matches the multi-template. have. When a matching multi-entry arrives, database manager 704 notifies the user or one of the event catchers (FIG. 2) as needed. When a user invokes a notification request, a lease time is specified that indicates how long the database manager 704 registers for the notification. After the specified time has elapsed, the notification registration is canceled.

As such, as shown in FIG. 15, when the database manager 704 receives a new notification request (step 1502), the incoming multi-entry is monitored until the registration time expires (step 504). If a multi-entry is recorded in the entry database 710, the search engine 708 determines whether the multi-entry matches the multi-template. Similar to the previous description, if each template of the multi-template has a matching entry in the multi-entry (steps 1508 and 1510), a match occurs and a user or event catcher is notified (step 1512). The incidental incoming multi-entry is continuously monitored unless the registration time expires (step 1504).

Modify In-Place Entries

Alternative embodiments additionally make modifications to entries and multi-entries in-place in the database. According to the invention, this implementation is an extension to entry / template and multi-entry / multi-template scenarios in which fields of entries can be modified in-place in the database, and in the case of multi-entry, entries within a multi-entry. Can be added, modified or deleted. The term "in-place" means that modifications occur within the database without removing entries or multi-entries from the database.

In-place modification operations in accordance with the present invention include "single entry modification", "multi-entry addition", "multi-entry modification / deletion", and "notification". 16 shows such in-place modifications and the information supplied by the user to request the corrections. The single entry modification operation changes the value in an individual field of an entry in the database. The multi-entry add operation adds an entry to a multi-entry present in the database, and the multi-entry modify / delete changes or deletes an entry in a multi-entry in the database. The notification operation for in-place modification notifies a match that occurs due to a change in an entry or multi-entry in the database. In general, as shown in FIG. 16, the first parameter of the operation request specifies which entry or multi-entry in the database should be modified, and the second parameter specifies the modification to be made.

(1) Single Entry Modify

17 is a flowchart illustrating the implementation of a single entry modification operation in accordance with the present invention. Reference will also be made again to FIG. 7 for structural characteristics. To invoke a single entry modification operation to change the value of individual fields in the entry, the user 702 makes a request that includes two templates (step 1700, see also FIG. 16). The first template 1602 is used to identify entries in the database to be modified, while the second template 1604 is used to modify entries and identify modifications to be made. Because these two templates manipulate the same entry by identifying and modifying it, the second template 1604 is the same type or the same subtype as the first template 1602. In some embodiments, the single entry modification operation may include type checking of the template.

First, the search engine 708 searches for an entry in the entry database 710 that matches the first template 1602 received in a request from the user (step 1702). When the entries in this database are compared to the first template, matching is performed according to a single entry and template matching as described above. If no entry exists in the entry database 710 that matches the first template 1602, the search engine 708 returns a zero to the user 702 indicating the number of entries changed due to this operation (step 202). 1712).

If a matching entry is found, the second template 1604 is used to modify the in-place entry in the database, ie the entry is not removed from the database for modification. Since the second template 1604 is of the same type or same subtype as the first template 1602 and the first template 1602 is the same type or subtype as the modified entry, the second template 1604 is also modified. It is of the same type or subtype as the modified entry, so the second template 1604 has the same or supertype as the field of the modified entry. Modify the matching entry to replace the value in the corresponding field of the entry using the value in the non-null field of the second template 1604 (step 1708). The field value of the entry corresponding to the null or wildcard field of the second template 1604 remains unchanged. After modification of an entry in the database, search engine 708 continues to search for other entries to be modified. If there are any more entries in the database that match the first template 1602, such entries are modified in the same manner (step 1708). Upon completion, search engine 708 returns a number indicating the number of entries modified by the operation (step 1712).

(2) multi-entry addition

18 is a flow chart illustrating the steps of a multi-entry add operation in accordance with the present invention. In general, a multi-entry add operation adds an entry to a specified multi-entry in a database. User 702 requesting such an operation supplies two parameters to search engine 708, multi-template 1606, and multi-entry 1608 (FIG. 16). The first parameter, multi-template 1606, is used to identify multi-entry entries in the entry database to be changed, and the second template, multi-entry 1608, is a set of entries to be added to the identified multi-entry database. Using matching multi-entry / multi-templates as described above, search engine 708 searches for multi-entries in the database that match the multi-templates presented by user 702 (step 1802). If no matching multi-entries are found (step 1804), search engine 708 returns zero to user 702 indicating the number of multi-entries to which entries have been added (step 1812).

If a matching multi-entry is found (step 1804), the entry of the specified multi-entry 1608 supplied by the user 702 does not remove the matching multi-entry from the entry database 710, and the entry database. It is added to the matching multi-entry found at 710 (step 1808). After adding to multi-entries in the database, search engine 708 continues to search for more multi-entries to change. If there are more multi-entries in the entry database 710 that match the multi-template 1606 presented as the first parameter in the operation request (step 1810), then the entries of the multi-entry 1608 in the operation request are the same. Is added to the multi-entry in a manner (step 1808). Finally, search engine 708 returns a number representing the number of multi-entries to which the entry has been added (step 1812).

(3) Modify / Delete Multi-Entry

19 is a flow chart illustrating a method for implementing a multi-entry modify / delete operation in accordance with the present invention. The multi-entry modify / delete operation modifies entries in the multi-entry in the database or deletes entries from the multi-entry from the database according to entries in the multi-entry in the request. When the search engine 708 receives a multi-entry modify / delete request, the request includes two multi-templates 1610 and a multi-template 1612 as its two parameters (step 1900). 16. The multi-template 1610 is used to identify multi-entries in the entry database 710 having entries that are to be modified or deleted, while the multi-templates supplied by the user 702 ( 1612 specifies the cut and deletes made for entries in the matching multi-entry.

The multi-template 1612 presented in the request includes the same number of templates as the multi-template 1610. Further, each individual template in multi-template 1612 is of the same type or subtype as the corresponding template in multi-template 1610 (ie, all templates (i) in multi-template 1612 are (i) The same type or subtype as the template in multi-template 1610). For example, if the first template in multi-template 1612 is the same type or subtype as the first template in multi-template 1610, then the second template is the same type or subtype as the corresponding template. Unlike common multi-templates, templates in multi-template 1612 of request parameters will also be null values, and these templates will be used to specify deletion from multi-entry as described below.

The search engine 708 searches for a multi-entry that matches the multi-template presented as the first parameter in the operation request (step 1902). If no match is found, zero is returned indicating the number of modified multi-entries (step 1914).

If a matching multi-entry is found in the entry database 710, it is modified using the multi-template 1612 from the operation request. To achieve this modification, for each non-null template in multi-template 1612, the corresponding entry in matching multi-entry in entry database 710 according to the non-null template in multi-template 1612. Is changed (step 1908). This change is modified using a single entry modification as described above, and the modification occurs in place within the entry database 710 without eliminating matching multi-entries. For example, if template i in multi-template 162 is non-null, entry i in multi-entry being changed is subject to template in multi-entry 1612 using a single entry modification. (Step 1708 of FIG. 17, where template i in multi-template 1612 is used as template 2). The value of the non-null field of template i is used to replace the value in the corresponding field of the existing entry being modified.

For every null template in a given multi-entry 1612, the corresponding entry in the matching multi-entry is deleted (ie, for every template i in the multi-template 1612 that is null, within the multi-entry to be modified. Entry i is deleted) (step 1910). If there is a multi-entry in the database that matches the multi-template 1610, the above steps are repeated to modify the remaining matching multi-entries in the entry database 710 (step 1912). When search engine 708 completes the modification, it returns a number representing the number of modified multi-entries (step 1914).

However, exceptions occur when dealing with multi-entry modify / delete operations. In multi-entry / multi-template matching, a multi-entry can match a multi-template, since the entry in the multi-entry can be used to match one or more templates in the multi-template, and the multi-template matches the template. You can have fewer entries than you have. If such a multi-entry matches the multi-template 1610 and is modified by the modify / delete operation according to the present invention, one or more templates in the multi-template 1612 modify a single entry in the modified multi-entry. To be used or deleted. In this case, if any such template in multi-template 1612 (ie, the template corresponding to the template of multi-template 1610 that matches the entry of the multi-entry to be modified) is deleted (ie null) If, then the entry in the multi-entry to be modified is deleted. Otherwise, if all such templates in the multi-template 1612 indicate a modification action, then all the templates are used to make the modifications, but the decision on the order in which the modifications are made depends on the implementation and the overall modification / It does not have much relation to the delete operation.

(4) Notice of Amendment

Regarding in-place modification, in another embodiment according to the present invention, a user may register an interest in an entry or multi-entry in a database and receive notification of the user or event catcher as before. can do. In this embodiment, if a user registers an interest in an entry or multi-entry in a database by supplying a template or multi-template, the search engine 708 does not monitor the incoming entry or multi-entry as described above. . When issuing a notification of in-place modification, it monitors entries or multi-entries that have been changed or modified in the database. Contrary to incoming entries into the database, monitoring of modified entries or multi-entries in the database is a major difference between previous notification operations and current notification operations for in-place modifications. As such, many basic features of the notification remain the same.

Generally, template 1614 or multi-template 1616 is used to register interest in changing entries and multi-entries. Upon changing a multi-entry or entry during in-place modification, the search engine 708 determines whether the changed entry or multi-entry matches a registered template or multi-template, or the modified multi-entry or entry matches. Check to determine if the template or multi-template has transitioned to a mismatched template or multi-template. That is, the notification operation searches for transitions in the matching state, from match to mismatch or from mismatch to match.

Referring next to FIG. 20, there is a flow diagram illustrating one embodiment of a method implemented by search engine 708 that processes a notification request received from a user to monitor changes in a modified entry or multi-entry. . In this case, the notification request is for a user to register an interest in the specified entry or multi-entry to determine whether to change the registration status with respect to the supplied template 1614 or multi-template 1616. Can be issued. If an entry or multi-entry is modified, its registration state can transition by changing from registration to template 1614 or multi-template 1616 to mismatch to it or from mismatch to match. If an entry or multi-entry changes its matching status for template 1614 or multi-template 1616 in a notification action request, database manager 704 notifies the user or event catcher (see FIG. 2) as needed. . When a user invokes a notification request, a lease time is specified that indicates how long the database manager 704 will register for notifications. After the specified time has elapsed, the notification registration is canceled.

As such, referring to FIG. 20, when the database manager 704 receives a new notification request (step 2002), entries or multi-entries are monitored as they are modified until the registration time expires (steps 2004 and 2006). ). If an entry or multi-entry is modified within the entry database 710, the search engine 708 matches the template 1614 or multi-template 1616 with which the entry or multi-entry was received in the notification request. It is determined whether the state has changed (steps 2008 and 2010). Search engine 708 determines whether the modified entry or multi-entry has changed from matching to template or multi-template in a mismatch or vice versa. If a transition of the mating state occurs, the user or event catcher is notified (step 2012). As long as the registration time has not expired, any additional entries or multi-entries modified in place are still monitored (step 2004).

Type-Safe Attribute Matching

Another embodiment according to the present invention includes attributes representing various values of a database entry represented as an object. In this embodiment, by associating an attribute with a field of the entry and using the entry, multi-entry and its operation type-safe attribute matching can be achieved. Type-safe attribute matching involves retrieving various types of attributes in the database, and allows the attributes to be typed strongly. It also enables the strengthening of relationships between attributes and enables efficient reference and manipulation of attributes by type.

By using type-safe attribute matching, attributes and names are closely related to each other (i.e., pages of attributes per minute are associated only with printers) as well as to attributes and their values (i.e., pages per minute are only integers). Type-safe attributes also allow for strengthening the relationships between pairs of attributes and their values. It also enables efficient retrieval of objects by type while allowing many different types of objects to be stored in a single database. Incidentally, this allows modifications that affect only the specified types of objects in the database, even though the database can store many different types of objects.

According to the present invention, type-safe attribute matching is achieved by associating attributes with fields of the entry. The value stored in the entry's field is the value of the associated attribute. Because a set of attributes, in this case an entry, can be an instance of a Java ^TM class, the class provides strong typing of both sets and individual attributes. As one example, the following example illustrates an entry representing a typical printer that represents attributes of the printer (ie pages per minute, resolution, etc.), as well as entries representing fields beyond general information such as name, product data, and physical location.

public class Printer implements Entry {

Integer ppm; // pages per minute

Integer dpi; // dot resolution per inch

Boolean duplex; // support duplex printing

Boolean color; // color or black only

}

public class Name implements Entry {

String name; // user friendly name of the service

String description; // free form description of service

String language; // language used above (ie English, French)

}

public class Type implements Entry {

String type; // general type of service

String vendor; // provider of service

String model; // model number / name of the product

String version; Product version number

}

public class Location implements Entry {

Integer floor; // which layers provide services

String building; // what buildings can enter

String room; // what room you can enter

}

As shown, there are strict typing of fields as well as entries, and such fields and their types will always be associated with such entries and their types. For example, "ppm" or "pages per mimute" is a type of "Integer".

Further description of the items may be achieved using multi-entry. By using multi-entry, a typical printer can also be described as a set of attributes. Such typical printer descriptions may include additional features that may be represented by other entries in the multi-entry, such as location, name, or machine type. The set of entries in this example form an exemplary multi-entry representing the attributes of a typical printer.

Entry and multi-entry operations may be used to retrieve and manipulate the type-safe set of such attributes. Such associations include take, record, notification, read, entry modification, multi-entry addition, multi-entry modification / deletion, and modification notification. It should be appreciated that other known database operations may be performed in the database system according to the present invention.

For illustrative purposes, assume that there are two different printers described by the following multi-entries stored in a database. Each printer will have any property described by the attribute associated with the field of entry in the multi-entry. In the hypothetical example, the first printer has an English name "quick" and a German name "schnell", associated with the description. As shown in the example, it is located in the first floor room 1202 of the ABC building and also has associated printing characteristics (ie, ppm = 10, dpi = 600, etc.). Such a printer can be represented by a multi-entry such as:

Multi-Entry 1 =

{Name [name = "quick",

description = "yahda1",

language = "English"],

Name [name = "schnell",

description = "yahda1",

language = "German"],

Location [floor = 1,

building = "ABC",

room = "1202"],

Printer [ppm = 10,

dpi = 600,

duplex = color

color = false]}

The second printer, with the English name "slow" and located in room 101 of the XYZ building, also has associated printing characteristics (ie, ppm = 3, dpi = 300, etc.). The second printer can be represented by a multi-entry as follows:

Multi-Entry 2 = {Name [name = "slow",

description = "yada2",

language = "English"],

Location [floor = 2,

building = "XYZ",

room = "101"],

Printer [ppm = 3,

dpi = 300,

duplex = false

color = true]}

From now on, assume that a search is needed that returns all printers with any attribute expressed as a field of the entry. For example, if the user looks for a printer represented in a database located in the "XYZ" building and is a color printer, the multi-template in the search can be expressed as follows:

Multi-Template 1 = {Location [floor = null,

building = "XYZ",

room = null],

Printer [ppm = null,

dpi = null,

duplex = null,

color = true]}

The user may invoke the read operation as a parameter supplying multi-template 1. If applied to a database containing multi-entries 1 and 2, since multi-template 1 shown here matches multi-entry 2, multi-entry 2 representing the second printer from the previous example will be returned. . Search engine 708 bypasses the incorrect type of item to search the database and compares the value stored in the field of the entry to the value of the template in the request. As a result, only those with the correct attribute values are returned. This type-safe match allows objects of different types to be stored in the same database for efficient retrieval.

Regarding the operations performed in a database using type-safe attribute matching, it is assumed that type-safe modifications are required for all items represented in the database owning any property. In such cases, entry / multi-entry modification operations may be used to modify items in the database. For example, suppose a request to change all printers in black and white (color = flase) at a particular arbitrary location to a resolution (i.e., dpi 100) is formalized and removes its location attribute. Given that a multi-entry modify / delete operation takes two parameters, a multi-template indicating that a multi-entry in the database will be modified, and a multi-entry indicating a change to be made, these two parameters may cause such a change. Can be supplied to indicate. Referring back to the previous example, the first parameter of the multi-entry modify / delete operation may be represented as a multi-template as follows:

Multi-Template 2 = {Location [floor = null,

building = null,

room = null],

Printer [ppm = null,

dpi = null,

duplex = null,

color = false]}

This multiple template searches for all black and white printers regardless of location. Finally, to modify all multi-entries with a resolution of 100 and remove their location attributes, the modify / delete operation is initiated using the following request:

Multi-Entry modify / delete (Multi-template 2,

{null,

Printer [ppm = null,

dpi = 100,

duplex = null,

color = null]})

Search engine 708 finds all multi-entries in the database that match multi-template 2 and modifies them according to the second parameter in the operation as described in the multi-entry modify / delete operation method. Multi-entry 1 from the previous example matches the multi-template 2 used in the operating parameters, so that multi-entry 1 is changed according to the second parameter of the operation. This action deletes the location attribute, replaces the dpi attribute with a value of 100, and creates a modified multi-entry 1:

Multi-Entry 1 =

{Name [name = "quick",

description = "yada1",

language = "English"],

Name [name = "schnell",

description = "yahda1",

language = "German"],

Printer [ppm = 10,

dpi = 100,

duplex = true,

color = false]}

That is, the search engine implements type-safe attribute matching by finding all items in the database that handle attributes of the requested type and modifying them in a type-safe manner. It should be understood that the illustrated example is for illustration.

Many variations and modifications will be apparent to those skilled in the art upon a full understanding of the disclosure. The following claims are intended to be interpreted to cover such modifications and variations.

Claims (14)

In a method of type-safe attribute matching in a database having a plurality of entries each defined by a class type and each having a plurality of typed fields, Providing a template of a class type, defining a set of attributes; Comparing the attributes of the template to corresponding fields of one or more entries; Determining whether the template matches the one or more entries based on the comparison; And Identifying a match entry based on the determination. 2. The method of claim 1, wherein the comparing step includes comparing only entries of the same class type as the template or a supertype of the template. 2. The method of claim 1 including modifying the database in response to identifying the match entry. The method of claim 3, wherein the providing step includes providing a second template of the same class type as the first template or a supertype of the first template, wherein the second template defines a set of attributes. and, The method further includes modifying the matching entry to reflect an attribute of the second template. 4. The method of claim 3 including deleting the matching entry. The method of claim 1, wherein the template has a wildcard attribute that matches any value in a corresponding field of an entry. 7. The method of claim 6 wherein the value of the wildcard attribute is a null value. In data processing autonomy for type-safe attribute matching in a database having a plurality of entries each defined by a class type and each having a plurality of typed fields, A providing component configured to provide a template of a class type, defining a set of attributes; A comparison component configured to compare an attribute of the template to a corresponding field of one or more plurality of entries; A decision component configured to determine whether the template matches the one or more entries based on the comparison; And And an identification component configured to identify a match entry based on the determination. 9. The data processing apparatus of claim 8, wherein the comparison component comprises a comparison component configured to compare only entries of the same class type as the template or a supertype of the template. 9. The data processing apparatus of claim 8, including a modification component configured to modify the database in response to identifying the match entry. A computer readable medium having internally implemented computer readable code for processing data in a database having a plurality of entries each defined by a class type and each having a plurality of typed fields. In a computer program product comprising: Provide a class type template that defines a set of attributes, Compare attributes of the template to corresponding fields of the one or more entries; Based on the comparison, determine whether the template matches the one or more entries, And a computer program product identifying a match entry based on the determination. 12. The computer program product of claim 11, wherein the comparison compares only entries of the same class type as the template or a supertype of the template. The computer program product of claim 11, wherein the database is modified in response to identification of the match entry. A computer readable medium having internally implemented computer readable code for processing data in a database having a plurality of entries each defined by a class type and each having a plurality of typed fields. In a computer program product comprising: Means for providing a template of a class type, defining a set of attributes; Means for comparing an attribute of the template to a corresponding field of the one or more entries; Means for determining whether the template matches the one or more entries based on the comparison; And Means for identifying a match entry based on the determination.