Patent Application
20060149712
The description relates in general to searching based on relationships between data objects.
In many applications, such as, for example, in enterprise resource planning (ERP), master data management (MDM), customer relations management (CRM), for instance as implemented within the products of SAP Aktiengesellschaft “R/3,” “mySAP.com,” “mySAP,” and “SAP NetWeaver,” data is stored within databases as data objects. The data objects can be, for example, business objects.
Insofar as data objects in general can be structured data, having properties and property values describing a respective real-world item, a company's information can be represented using data objects.
Business objects can be, for example, business partners, products, plants, machines, or any other real world objects being mapped into the respective data structure of the business objects. Various different types of data of a company, for example, information about persons and products, can be stored within the business objects.
Moreover, data objects can be related, virtually, to each other using relationships. These relationships can represent, for example, relationships between business partners or any other items within a company. For example, one business object representing a particular company can be related to other business objects representing persons, for example, employees of the company. The relationship can be, in this case, an “employer-employee” relationship. Another example can be a business object representing a communication, e.g., an email, and a business object representing persons, for example, the person who wrote the email and the person to whom the email was addressed. In the first case, the relationship between the email and the author can be an “author-document” relationship and in the second case, the relationship can be a “recipient-document” relationship. It is also possible to have relationships between business objects of the same type.
In some computer systems, for example, an ERP system, information about a company may be stored in business objects. Users working with the system may face the problem that they need to search for certain business objects but do not have enough information relating to the object of their search to find it. Users may have only partial information about what it is they are searching for.
For example, a user may want to find a particular company but only knows that this company is located in Germany. In a particular system, a search of all companies in Germany may yield too many search results for the user to review. The user may also know that the company he or she is looking for delivers screws and that a person named “Otto Maier” works for the company. In this example, business objects for screws may be stored, and those business objects may have a “relationship” with the supplying company. Moreover, information about contact persons may be stored in business partner objects, which may also be related to a company business object representing the company for which the persons work. However, this information may be distributed in different types of business objects. The user may not have any way of creating a search that includes several partial but related search criteria.
In common search engines, users may only be able to search in unstructured documents, which may be indexed to support a a full-text index. An index can be a physical representation of the data in the search engine, e.g., attributes and their values can be stored and accessed in fields. The index, as used by common search engines, may not allow searching for business objects with only partial information about attributes or pieces of content relating to the business objects. Insofar as search engines have the benefit of providing search results very quickly, search engines may be preferred over database searches; however, search engines may not provide any information about business object relationships. Thus, search engines may not be suitable for locating objects based on relationship information.
Mapping of business objects into an unstructured document is described in application Ser. No. US 60/476,496, which is incorporated herein by reference. It has also been described how to search for business objects using search engines in application US 2004-0162816, application Ser. No. 10/367,661, which is also incorporated herein by reference.
Known methods may not allow searching for business objects using search engines with attributes or pieces of content of related business objects.
In order to overcome one or more of the above-mentioned problems and to enable a search engine to search for data objects (e.g., business objects) using relationships between different business objects, one embodiment provides a method for searching data objects using indexes within a search engine, with creating a first index of a search engine, wherein creating the first index comprises indexing data objects of at least a first type; creating a relationship index, wherein creating the relationship index comprises indexing relationships of data objects of at least the first type, wherein indexing the relationships comprises mapping relationship-type data objects representing the respective relationships into documents and indexing the documents; determining relationships of data objects from at least the relationship index; and searching within related data objects for data objects that meet at least one search criterion.
One embodiment comprises searching within the first index for data objects of the first type with content that at least partially meets a first search criterion and obtaining a first set of data objects.
Determining relationships of the data objects comprises, according to one embodiment, determining relationships of the data objects of the first set of data objects.
One embodiment also comprises creating at least a second index of a search engine, wherein creating the at least second index comprises indexing data objects of at least a second type.
Determining relationships of the data objects of the first set of data objects comprises, according to one embodiment, finding related data objects within an index.
One embodiment also comprises providing a data object as a search result directly using one single search request.
Indexing the relationships of the data objects can comprise indexing the relationships in the first index according to one embodiment. Indexing the relationships of the data objects can also comprise indexing the relationships in the second index, according to one further embodiment.
Determining relationships of data objects can comprise, according to one embodiment, searching within at least one of the relationship indexes: the first index, or the second index.
One embodiment can further comprise creating a join index, wherein creating the join index can comprise indexing a relationship index for a particular type of data object together with the related data objects.
Another embodiment can comprise creating an overview index, wherein creating the overview index comprises combining the join indexes of the different types of data objects. The overview index can be, according to one embodiment, a joined index of all join indexes. The overview index may allow searching whether any relationships between particular data objects exist.
One embodiment can further comprise searching within the join index for relationships between the data objects of the first type and related data objects and obtaining a join path between the data object of the first type and related data objects.
The search engine can automatically find data objects based on attributes of related data objects by using join conditions. One embodiment provides using a join path to obtain the search result. The join path may allow searching automatically for data objects having a relationship with other data objects with attributes in compliance with a search statement.
The search engine may facilitate fast searching within indexes. Indexes, which represent data objects, may be separated from each other inasmuch as each index may represent data objects of one particular type only. One embodiment can provide indexing within the first index solely data objects of the first type. Another embodiment can provide creating the second index by indexing solely data objects of the second type.
One embodiment can also provide searching for a data object by receiving user-inputted search statements for a first type of data object or for a second type of data objects. The user may be enabled to enter search criteria for the data objects and the relationship between the data objects within one query with several text fields. The user may carry out “One-Click-Searching,” for example, and may not have to execute multiple queries separately.
Business objects may be stored in databases with appropriate data structures. These data structures can be mapped onto unstructured documents and indexed thereafter. A relationship-type data object may have a particular data structure. One embodiment provides storing within the relationship-type data objects at least one of a relationship type, a relationship identifier, a data object identifier of the related data objects, data object types of the relate data objects, and/or an object role of the related objects. The data object identifiers can identify the related data objects unambiguously.
According to one embodiment, searching for a data object can comprise receiving, within a search request or query, information about a type of relationship and searching for relationships between data objects only of the respective type. The user may specify the type,of relationship between the searched data objects.
Searching for a data object can comprise, according to one embodiment, using a search engine to execute the search within its indexes.
Creating the at least first index can comprise mapping data objects in unstructured documents and indexing the unstructured documents for each type of object into the respective index, according to another embodiment.
Searching for a data object can comprise searching for data objects of a first type within the first index in compliance with a first search statement, determining from the join index related data objects, and providing as a search result all data objects that are related to a data object of the first type in compliance with the first search statement, according to one embodiment. This embodiment may allow a search for data objects that are related to other data objects. The search results can be described as “referred-to” or “referred by.” A list of data objects resulting from a search may all be referred to or referred by data objects in compliance with a search statement.
Searching for a data object can comprise searching for the data object in compliance with the search statement within at least one index using a full-text search, according to one embodiment.
Another aspect of the disclosure is a search engine arranged to search for data objects using indexes with at least a first index that indexes data objects of at least a first type; a relationship index indexing relationships of data objects of at least the first type where relationship-type data objects representing the respective relationships are mapped into documents and the documents are indexed; a search module arranged for determining relationships of data objects from at least the relationship index, and for searching within related data objects for data objects in compliance with at least one search statement.
A further aspect of the disclosure is a computer program product tangibly embodied in an information carrier, the computer program product comprising instructions that, when executed, cause at least one processor to perform operations comprising creating a first index of a search engine, wherein creating the first index comprises indexing data objects of at least a first type; creating a relationship index, wherein creating the relationship index comprises indexing relationships of data objects of at least the first type, wherein indexing the relationships comprises mapping relationship-type data objects representing the respective relationships into documents and indexing the documents; determining relationships of data objects from at least the relationship index; and searching within related data objects for data objects in compliance with at least one search statement.
Yet a further aspect of the disclosure is a data structure for representing relationships between data objects of at least one type having at least a relationship type, a relationship identifier, and an object identifier of the related data objects.
The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects and advantages will be apparent from the description and drawings, and from the claims.
In the FIGS:
Computer 900 can communicate with computers 901 and 902 over network 990. Computer 900 has processor 910, memory 920, bus 930, and, optionally, input device 940 and output device 950 (I/O devices, user interface 960). As illustrated, the invention is implemented by computer program product 100 (CPP), carrier 970 and signal 980. With respect to computer 900, computer 901/902 is sometimes referred to as “remote computer,” computer 901/902 is, for example, a server, a peer device or other common network node, and typically has many or all of the elements described for computer 900.
Computer 900 is, for example, a conventional personal computer (PC), a desktop device or a hand-held device, a multiprocessor computer, a pen computer, a microprocessor-based or programmable consumer electronics device, a minicomputer, a. mainframe computer, a personal mobile computing device, a mobile phone, a portable or stationary personal computer, a palmtop computer or the like.
Processor 910 is, for example, a central processing unit (CPU), a micro-controller unit (MCU), digital signal processor (DSP), or the like.
Memory 920 is comprised of elements that temporarily or permanently store data and instructions. Although memory 920 is illustrated as part of computer 900, memory can also be implemented in network 990, in computers 901/902 and in processor 910 itself (e.g., cache, register), or elsewhere. Memory 920 can be a read-only memory (ROM), a random access memory (RAM), or a memory with other access options. Memory 920 is physically implemented by computer-readable media, for example: (a) magnetic media, like a hard disk, a floppy disk, or other magnetic disk, a tape, a cassette tape; (b) optical media, like optical disk (CD-ROM, digital versatile disk—DVD); or (c) semiconductor media, like DRAM, SRAM, EPROM, EEPROM, memory stick.
Optionally, memory 920 is distributed. Portions of memory 920 can be removable or non-removable. For reading from media and for writing in media, computer 900 uses well-known devices, for example, disk drives, or tape drives.
Memory 920 stores modules such as, for example, a basic input output system (BIOS), an operating system (OS), a program library, a compiler, an interpreter, and a text-processing tool. Modules are commercially available and can be installed on computer 900. For simplicity, these modules are not illustrated.
CPP 100 has program instructions and, optionally, data that cause processor 910 to execute method steps of the present invention. In other words, CPP 100 can control the operation of computer 900 and its interaction in network system 999 so that it operates to perform in accordance with the invention. For example and without the intention to be limiting, CPP 100 can be available as source code in any programming language, and as object code (“binary code”) in a compiled form.
Although CPP 100 is illustrated as being stored in memory 920, CPP 100 can be located elsewhere. CPP 100 can also be embodied in carrier 970.
Carrier 970 is illustrated outside computer 900. For communicating CPP 100 to computer 900, carrier 970 is conveniently inserted into input device 940. Carrier 970 is implemented as any computer readable medium, such as a medium largely explained above (cf. memory 920). Generally, carrier 970 is an article of manufacture having a computer-readable medium with computer-readable program code to cause the computer to perform methods of the present invention. Further, signal 980 can also include computer program product 100.
Having described CPP 100, carrier 970, and signal 980 in connection with computer 900 is convenient. Optionally, further carriers and further signals embody computer program products (CPP) to be executed by further processors in computers 901 and 902.
Input device 940 provides data and instructions for processing by computer 900. Device 940 can be a keyboard, a pointing device (e.g., mouse, trackball, cursor direction keys), microphone, joystick, game pad, scanner, or disc drive. Although the examples are devices with human interaction, device 940 can also be a device without human interaction, for example, a wireless receiver (e.g., with satellite dish or terrestrial antenna), a sensor (e.g., a thermometer), a counter (e.g., a goods counter in a factory). Input device 940 can serve to read carrier 970.
Output device 950 presents instructions and data that have been processed. For example, this can be a monitor or a display, cathode ray tube (CRT), flat panel display, liquid crystal display (LCD), speaker, printer, plotter, and vibration alert device. Output device 950 can communicate with the user, but it can also communicate with other computers.
Input device 940 and output device 950 can be combined to a single device. Any device 940 and 950 can be provided optionally.
Bus 930 and network 990 provide logical and physical connections by conveying instruction and data signals. While connections inside computer 900 are conveniently referred to as “bus 930,” connections between computers 900902 are referred to as “network 990.” Optionally, network 990 includes gateways, which are computers that specialize in data transmission and protocol conversion.
Devices 940 and 950 are coupled to computer 900 by bus 930 (as illustrated) or by network 990 (optionally). While the signals inside computer 900 are mostly electrical signals, the signals in network are electrical, electromagnetic, optical or wireless (radio) signals.
Networks are commonplace in offices, enterprise-wide computer networks, intranets and the Internet (e.g., the world wide web. (WWW)). Network 990 can be a wired or a wireless network. To name a few network implementations, network 990 can be, for example, a local area network (LAN), a wide area network (WAN), a public switched telephone network (PSTN); an Integrated Services Digital Network (ISDN), an infra-red (IR) link, a radio link, like Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communication (GSM), Code Division Multiple Access (CDMA), or a satellite link.
A variety of transmission protocols, data formats and conventions is known, for example, transmission control protocol/internet protocol (TCP/IP), hypertext transfer protocol (HTTP), secure HTTP, wireless application protocol (WAP), unique resource locator (URL), a unique resource identifier (URI), hypertext markup language (HTML), extensible markup language (XML), extensible hypertext markup language (XHTML), wireless markup language (WML), and Standard Generalized Markup Language (SGML).
Interfaces coupled between the elements are also well known in the art. For simplicity, interfaces are not illustrated. An interface can be, for example, a serial port interface, a parallel port interface, a game port, a universal serial bus (USB) interface, an internal or external modem, a video adapter, or a sound card.
In the illustrated ERP system 200 two different types of business objects 202, 208 are illustrated: business partner business objects 202 and the master data framework (MDF) objects 208. The master data framework can be understood as a generic model for any type of business objects. Both types of business objects 202, 208 are stored in respective database tables 202a, 204a, 206a. The business partner business objects 202 are stored in database table 202a. The MDF objects 208 are stored in table 206a. The relationships between the business partner business objects 202 and the MDF objects 208 are stored as relationship objects in a separate database table 204a.
The database tables 202a, 204a, 206a may allow searching for particular business objects using search statements, such as structured query language (SQL) statements; however, the search in the database tables 202a, 204a, 206a may be slow. A search using a search engine may not be possible within the database, as the data structure may not allow such a type of search. One requirement of a particular search engine, according to one embodiment, may be that all data that can be searched must be indexed into indexes of the search engine. Without indexing the relevant data, it may not be possible to search for the data using the search engine.
A database may allow accessing objects using attributes only. The search for attribute values may be an exact search; in other words, databases may not allow searching for values using a “fuzzy” search-that is, an approximate search or a similarity search. The search within a database can be significantly slower than within a search engine. One reason is that databases are often optimized for read and write access and for reducing storage size. The search engine, in contrast, may be optimized for read access only. The index of a search engine may be provided within main memory, whereas the index of a database may be stored in more permanent, slower memory, for instance on a hard disk. The data may be cached in main memory only if necessary. The search engine's index may also provide a dictionary for searching documents, whereas the database only provides attribute access using SQL.
A significant difference between a database and a search engine, according to one embodiment, is the dictionary. The dictionary may enable accessing the objects using a full-text search. When searching for search terms, the search engine can, in addition to the full-text index, provide an attribute index. The search engine can provide a fault-tolerant search. The search statements may not need to be exact matches of the searched attributes—a so-called “fuzzy search.” The dictionary may allow quick full-text searches. In contrast to database queries, the search engines may also allow diffuse, or fuzzy, searches, where the attribute values of the found data objects do not exactly match the search statements. The search engines may be optimized for quick read access, whereas, in contrast, databases may be optimized for quick read/write access. The data used for the search may be stored in main memory, whereas databases may use caching of currently used data objects.
In addition, the search engine 201 according to one embodiment, can provide an index 204b for relationship-type data objects representing relationships between data objects. The relationships between the data objects can be stored in the relationship-type data objects, which will be described in more detail in
A search over multiple indexes may be supported by a join of indexes, e.g., by following a join path, which enables providing a search within different indexes simultaneously. The join of indexes can be provided by a join index, which is an aggregation of a relationship index for a particular type of data object and all related data object indexes.
The search module 205 can be operated using a computer program product 100. Users can access the search engine 201 through the user interface 260. The search module 205 can provide a search request or query-input function and may display search results through the user interface 260.
Searching for data objects that are related to each other with search statements concerning both the searched data object and the data object being related to the searched one can be provided.
The search statement can be, for example, a string of characters. For example, a user can search with a search statement, “Germany,” used for business objects of the type “company,” which relates to the location of the company, and with a search statement, “Otto Maier,” used for a business object of the type “business partner person.” Further, the search can be delimited to companies delivering “screws” by providing a further search statement for business objects of the type “delivered items.”
The search engine 201 can use the search statements to search within its indexes for relevant documents or data objects. Additionally, to allow searching for data objects by way of information about related data objects, users can be required to enter at least two different search statements. Users can define a search statement for data objects of at least the first type. The data objects of the first type can be related to other data objects of the first type or to data objects of at least a second type. The search engine may be, however, unable to resolve which search statement relates to which type of data objects.
Users can decide which search statement belongs to which type of data object. One example can be a search for a company in Germany with an employee named Otto Maier. The user can enter “Germany” and can decide that this search statement is relevant for data objects of the type “company.” The user can further enter “Otto Maier” as the user is searching only for companies in Germany that employ persons named.“Otto Maier.” The search statement “Otto Maier” can be assigned by the user to the data object type “business partner person.” Having this information, the search engine 201 can search for “Germany” in a company index. The search results can be used to query a relationship index and determine data objects which have a relationship with the found ones for “Otto Maier” as a business partner person. Only those data objects that are related to the found one may be searched.
In the above example, search results may also include all companies in Germany, whose CEOs are named Otto Maier. The user might know that the company he is searching for, however, has only an employee called Otto Maier. The user can limit the search to relationships between the objects he or she is aware of.
The search can be conducted on the data object inasmuch as it can be determined whether at least pieces of content or pieces of attributes of the data objects meet the search criteria.
The search engine 201 can be a TREX search engine as provided by SAP Aktiengesellschaft, or another search engine capable of providing a join of indexes. Embodiments may provide mapping every database table 202a, 204a, 206a into flat documents, and indexing these as separate indexes 202b, 204b, 206b for the search engine. Every entry in the business partner business object table 202a may be mapped into a document, and the documents may be indexed into a business partner business object index 202b. The same may be done for the MDF business objects 206a, which are indexed within the index 206b.
According to one embodiment, the relationship objects, which are stored in table 204a, are also mapped into documents and indexed separately within index 204b of the search engine 201.
The relationship objects store a link to each of the related business objects. The business objects themselves may not store any information about the relationship object or about the relationship. Relationship objects can be mapped into flat documents. The documents thus may only represent the relationships. The documents can be indexed into an index 204b for the search engine. The search within the search engine can thus be extended from searching for attribute values of one business object to attribute values of related business objects.
The search engine 201 may support joins of indexes, for example, by creating a join index 203. The join index 203 and the other indexes are further described in
The join feature of a search engine can provide creating join paths that represent links between two fields of different indexes. A unique identifier of each business object, which may be part of a relationship, can be stored in a reference field of a relationship object. In an exemplary case, two join conditions are defined to represent a relationship: one join condition represents a link between business object A and the relationship objects, e.g., one join condition between the identifier field of business object A and the ‘reference-to-business object-A’ and one join condition between the ‘reference-to-business object-B’ field and the identifier field or business object B. The two join conditions together build the join path, which can be followed by the search engine.
After a unique identifier of a business object has been found in the reference field of a relationship object, the search engine can follow the join of indexes to access and compare data from a related business objects with a search statement.
Users can search the relationship objects and the search engine may follow the join paths in both directions. The search engine 201 can search for property and attribute values of the business objects following the join path to a first business object and later following the join path to a second business object, which is related to the first business object. The second business object can be searched for with a second search statement.
Some Embodiments provide an object model for the relationship objects as illustrated in
Relationship objects 304 can have attributes as shown in the class diagram illustrated in
The attributes relationship type name, description, business object type A, business object type B, role A, and role B of table 500 in
As shown, The business objects 402, 406 only store attributes that represent their state, but neither contains a link to the related business object 402, 406 nor to the relationship object instance 404. All data about the relationship may be stored in the relationship object instance 404. The business objects 402, 406 may only store their own data.
To allow searching the information using a search engine, the data objects of each type, and even the relationship data model, can each be mapped into its own index. This can be done by mapping the structured data objects into unstructured documents and by creating indexes of the unstructured documents. The indexes can be attribute indexes and/or full-text indexes.
For example, at least parts of a data model of a relationship data object R01 that express a relationships between business object 001 and business object 002 can comprise:
After mapping this structured data object into a document, the document can comprise:
These relationship documents can be used to create the relationship index. The relationship index can comprise attributes and content of the relationship documents.
The result, according to one embodiment, no longer has any redundancies or ambiguities because the relationships can be mapped into separate objects. Each relationship can be represented by a unique identifiable relationship object. No information about the relationship needs to be stored in the related business objects.
To create join paths, with join conditions, a join index JA for the business objects of type A may be provided. For each type of business object, a separate join index can be provided. The join index JA may comprise information about the relationship conditions within the relationship index RA and the object information within the related object indexes OA, OB, OC. The join index can enable the search engine to follow paths to business objects, search within the business objects, track back paths of found business objects to searched types of business objects and search within the relevant searched types of business objects. An collection of join indexes can be provided within an overview index (not shown).
The join index can be a collection of the participating indexes, e.g., the object indexes of the respective types and the relationship index. A join index for data objects of a type A can comprise the relationship index for objects of the type A, the data object index for the type A and the related data object indexes of the related data objects. The join index can be a virtual table that contains all the data of the “participating” tables. The relationships of the data object relationship objects and the related business objects can be stored in the join index as join conditions. Each join condition can represent a relationships between two objects. A join index can comprise at least two join conditions: one to represent the relationships between a business object of a particular type and the relationship object, and a second to represent the relationships between the respective relationship object and the related business object.
In one data model, a join index can contain a relationship index for a particular type of data object together with the object indexes of the related data objects. The business objects may be indexed within their object index. The relationships may be indexed within their relationship index. While the object and the relationship indexes can be physical indexes, the join index can be a logical, or “virtual” index that provides an overall view across the physical indexes and their connections described as join paths.
The search engine can, for example, follow a track from a search business object back to related business objects using the join index. Within the related index, the search engine can search for objects, which meet the search condition. For any objects that are found, the search engine can track back the relationship with the relationship index and from there back to the index of the searched objects. Within this index, the search engine can search within the remaining objects for a second search condition to find the searched data object.
In one data model, a join path can define a connection between two object indexes along a relationship index: Object-Index-A-Relationship-Index-A-Object-Index-B. This allows searching for Objects of Type A by providing search criteria of related Objects of Type B. For each type of relationship, one join path can be defined. For example, one join path for the relationship type “is supplier of product” and one join path for the relationship type “is customer of product” can be defined. This allows searching for products based on supplier data.
By using the join path between a first data object and a second data object to obtain the search result, the search engine can automatically follow a link from one data object to related data objects and search within the index of the related data objects. For example, if a data object has been found for a first search statement, and the first data object is related to data objects of a second type, the search engine can follow a corresponding join path and search within the index relating to the second type for data objects in compliance with a second search statement. The search result then can contain those data objects that have a relationships to data objects in compliance with a search statement.
Business objects of a first type may be indexed within a first index of the search engine (702). Business objects of a second type may be indexed within a second index of the search engine (704). The relationships between the business objects of the first type and the business objects of the second type may be indexed within a relationship index of the search engine (706). In addition, a join index can be created, providing an overview of a relationship object and all related indexes of data objects. The creation of the join index is illustrated in
After indexing the values of the business objects in separate indexes and indexing the relationships between the business objects in a join index, the search engine can receive user inputs (708) of at least two search statements for values of attributes of business objects of different types, or of the same kind, for business objects that need to be related, according to one embodiment. The user can define within the search statement attributes that the searched data objects and the data objects related thereto must meet, at least partially. The search engine can allocate the data objects in compliance with the search statements.
The search statement may comprise search criteria for business objects of a first type and business objects of a second type and a relationship between the business objects. The relationships between the business objects, which can be of different types or of the same type, can be used for searching (710) within the join index to determine join paths between respective relationships of the corresponding business objects. The relationship type can also be specified by the user, to specify the search further. The type of the relationship, for example, could be “delivered items”. The join path can be determined by determining from the join index the relevant relationship object instances, determining the IDs of the related business objects and providing a link to each of the related business objects.
The join paths can be followed in one direction to search (712) for business objects of the first type that meet the first part of the search statement. The search can be conducted automatically in a first index or a representation of the first index in the join index for the data objects of the first type, for example of the type “company.”
The join paths of the found business objects of the first type can be followed in the other direction to search (714) within the second index or a representation of the second index in the join index for the data objects of the second type, for example of the type “business partner person.”
A join index can be a virtual representation of a relationship index for a particular type of business objects and all related business object indexes. For example, from object databases 202a, 206a, corresponding business object indexes 202b, 206b can be created (800). In addition, for each of the different types of business objects, one relationship index can be created. For example, the relationships of business objects of the type business partners, may be stored in relationship database 204a. This database can be used to create (802) a relationship index 204b for the business objects of the type business partner. For all other types of business objects, a corresponding relationship index can be created.
A join index 203 can be built (804) by determining from the relationship index 204b all related business object indexes 202b, 206b. The join index 203 may comprise references to all business object indexes, which are referenced by the relationship index of a particular type of business object. In addition, the join index may comprise the reference to the relationship index itself.
The join index 203 may be a virtual index without any data entries of the business object data. It may comprise only references to the indexes. At runtime, it can be used by the search engine, to retrieve the entries from the referenced indexes and from there the entries of the business objects. To avoid redundancy, data may only be stored in the business object and relationship index. The join index can comprise a mere reference to the corresponding indexes. The data can be retrieved from the corresponding indexes at runtime dynamically.
From the perspective of the application, e.g. the search engine, the join index already comprises the data sets. This enables the search engine to create join paths and to follow the join paths to search within related business objects.
For the table 910, a corresponding index 915 can be created. This index 915 can be an index of the attribute “Names” of the data objects stored in table 910. For example, the name “Smith” of the data objects in the table 910 may be indexed by having references 1003, 1004 to the entries in the table 910. The name “Davis” may be indexed with references to the table 910 entry 1001. Other indexes can be derived from the figure.
Further,
An index 953 for the data objects of the type organization in table 930 can also be created. The index 935 can index, for example, the attributes “Organization Name” of the data objects of the type organization stored in table 930. For example, the data objects having an entry with the string “SAP Aktiengesellschaft” can be indexed in the first row of index 935, where the reference 3001 refers to the entry in the table 930. Other examples can be seen or derived from the illustration.
For example, the table 1010 stores the relationships of business objects of the type person. Each relationship may be stored in one row. The relationship can be identified by the objectID. The relationship type can be stored together with the related data objectIDs. The related objectIDs can be referenced to by the A_Key and B_Key. The table 1010 has references to data objects of the type person, e.g. the objectIDs 1001, 1003, . . . and references to organizations, e.g. objectIDs 3002, 3001, 3003.
For example, a relationship “WorksFor” can be represented by the objectIDs 4001, 4002, 4004, 4005. 408. A relationship “Spouseof” can be represented by objectID 4003. This relationship represents a relation between the data objects with objectIDs 1004 and 1003.
For the relationship table 1010, a corresponding relationship index 1015 can be created. For each type of relationship, one row in the index 1015 can be provided. The relations of the type “WorksFor” may be indexed in the first row, having references to the entries 4001, 4002, 4004, 4005 and 4008 in the relationship table 1010. All of these entries are of the type “WorksFor”. Other types of relationship are also indexed in relationship index 1015, for example, the relationship of the type “FreelancerWorksFor”, which comprises the relationship entries in table 1010 with objectIDs 4006, 4007.
A user may wish to search for a person named “Peter” who works for a company located in New Zealand. The user may use a method, as described herein to locate additional information, based only on a first name, a country and a relationship. Referring to
The method may locate the correct person in the following manner. Based on the “works for” relationship, a search engine may, from the join index 1110, follow the pointer 1112c to the relationships index. The search engine may then search all of the “works for” relationships. Searching these relationships may comprise following the references in the index to ultimately find a person named “Peter” in a “works for” relationship with a company in New Zealand. In this example, after following the pointer 1112c to the relationships index 1010, the search engine may follow each of the references that relate to a “works for” relationship-that is, the search engine may follow 4001, 4002, 4004, 4005 and 4008. These references may point to relationship entries in the relationships table 1010. For example, the reference 4005 in the relationships index 1015 has a reference, or “join path,” to the row in the relationships table that relates 0001 and 3003. The references 0001 and 3003 point other indexes. For example, 0001 points to the row in the person index 915 that includes “Jackson” and 1001. The path followed by the pointer, 1116, is another join path. From the person index 915, a third join path links the aforementioned row with a row in the person table 910. This row in the Person table includes additional information about a Peter who lives in New Zealand, though at this point, the search engine has not identified a Peter who works for a company that is located in New Zealand.
Referring again to the relationships table 1010, an additional join path 1118 is associated with row 4005. In this example, this join path 1118 associates the person represented in the relationships table 1010 as “0001” with an organization named “Peter's Consulting.” The search engine may follow this join path 1118 to the organization index, and may similarly follow the join path 1122 to the organization table 930. From the row in the organization table 930, the search engine identifies that “Peter's Consulting” is located in New Zealand. Tracing the join paths (1122, 1118; 1120, 1116) to the relationship table 1010, the search engine identifies a result of the original search query-a Peter who works for a company that is in New Zealand. With this search result, the search engine can provide the user with additional information. For example, the search engine could provide the last name and street address corresponding to the search query.
With the foregoing method, a search engine may implement a join index to facilitate searching for data objects based on relationships in a manner that may not be possible with other search methods. Specifically, this method may allow relationship-based searches using only partial information.
The method enables searching for business objects using their relationships. The relationships of found data objects from a first index can be used to search within related data objects, for example, from a second index. The method provides only those data objects as search results that comply with the respective search statements and that have a relationship with data objects that complies with a second search statement. The method enables search engines to search for business objects based on data from related business objects.
A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other embodiments are within the scope of the following claims.
