Patent Description:
A method of crux detection is provided herein. A dependency graph for a search definition set can be generated. The dependency graph can include nodes representing search definitions of the search definition set and the dependency graph can indicate dependency between search definitions in the search definition set. The dependency graph can be reduced for a given search definition. The reducing can remove search definitions on which the given search definition does not depend. The given search definition can be a root of a tree within the dependency graph. Elements can be removed in the given search definition of the reduced dependency graph based on context criteria. Elements can be removed in the remaining search definitions of the reduced dependency graph based on search definition criteria. One or more implementation crux elements can be identified in the search definitions of the reduced dependency graph.

One or more non-transitory computer-readable storage media storing computer-executable instructions for causing a computing system to perform a method of crux detection is provided herein. A request to identify implementation cruxes in a search definition set can be received. A hierarchical representation of the search definition set can be accessed. The hierarchical representation can be reduced based on an initial search definition. The reducing can include removing search definitions unrelated to the initial search definition based on the hierarchical representation. The reduced hierarchical representation can be focused. The focusing can include removing elements of the initial search definition based on context criteria and removing elements of remaining search definitions in the reduced hierarchical representation based on search definition criteria. One or more implementation cruxes can be identified in the search definitions of the reduced focused hierarchical representation based on crux criteria. The identified implementation cruxes can be provided.

A system capable of performing crux detection operations is provided herein. A request to identify implementation cruxes in a set of queries can be received. A hierarchical representation of the set of queries can be generated. The hierarchical representation can indicate dependencies between queries in the set of queries. The hierarchical representation of the set of queries can be accessed. A starting query in the set of queries can be identified. The hierarchical representation can be reduced. Reducing the hierarchical representation can include: identifying one or more extra queries unrelated to the starting query within the set of queries based on the hierarchical representation and removing the one or more identified extra queries. The reduced hierarchical representation can be focused. Focusing the reduced hierarchical representation can include: analyzing at least the starting query in the reduced hierarchical representation to determine relevant elements in the starting query based on context criteria, where the analyzing includes setting a given relevance indicator associated with a given query element to indicate relevance as determined based on the context criteria, removing elements in at least the starting query based on their respective associated context relevance indicators, where removed elements have associated indicators not indicating relevance, analyzing one or more queries in the reduced hierarchical representation to determine relevant elements based on search definition criteria, where the analyzing includes setting the given relevance indicator associated with the given query element to indicate relevance as determined based on the search definition criteria, and removing elements in the one or more queries based on their respective associated relevance indicators, where removed elements have associated indicators not indicating relevance. The queries in the reduced focused hierarchical representation can be analyzed to identify implementation cruxes in the queries based on crux criteria. A list of identified implementation cruxes can be generated. The generated list of identified implementation cruxes can be provided.

The ever-increasing amount of incoming data and transformation of the enterprise into a data-driven world creates many difficulties as data is indeed accumulated. In particular, accessing and finding relevant data by searching is a key component of modern data usage. Searching can be accomplished through search models, which can embrace most or all information necessary to execute a successful search. For example, such information can include: request fields (e.g. in which columns a search term should or could be found), freestyle search request fields (e.g. which columns to consider in a freestyle or user-defined search), relevance of freestyle search request fields (e.g. degree of relevancy of a hit in a given column), facetted search request fields (e.g. which columns are relevant to a facetted search), advanced search request fields (e.g. which columns should be enabled for an advanced search), auto-completion request fields (e.g. for which columns the auto-complete feature should be provided), response fields (e.g. which columns should be a part of the search result), title response fields (e.g. which columns are relevant to the title of a search hit), authorization checks (e.g. which authorizations are requested to access which data), boosts (e.g. which hits should be boosted, promoted, or highlighted), field semantics (e.g. which search configuration to use based on semantics related to the search fields or search), or others, in any combination thereof. A search model can include many different searches of many different types, which can work together, either directly, indirectly (e.g. by subject matter or conceptually).

A search can be expressed as a search definition. A search definition can be written in, in whole or in part, a database language or a search language, and generally includes different elements or operations. Some operations can be specific to a database language or search language, and can include "heavy or tricky" operations or elements, or other key or defining operations for a given search. Such operations or elements can be cruxes for their search, and can impact the search's execution, performance, accuracy, or results (or other aspects of the search in a search model). Thus, identifying such cruxes in a search can be important for accurately or efficiently developing or improving the search.

Further, whether or not a particular element or operation in a search is a crux can depend upon where in the search or in a set of interrelated or interdependent searches the particular operation is implemented. Thus, an element's position in a search stack can help determine if the element is an implementation crux for the search. Further, searches are often highly interdependent or interrelated, resulting in a deep search stack, while each search can include many potential crux elements. These reasons can make it very difficult for a search developer (or tester, etc.) to determine if a given element in a search is a crux for the search, to such a point it is often not feasible for a search developer to manually review searches or a search model to identify cruxes. However, identifying cruxes in a search can help to significantly improve search quality across many factors, such as accuracy, results, performance, and so on.

The crux detection functionality described herein can help alleviate these concerns by identifying implementation cruxes in a search model or set of search definitions. Once identified, a search developer, search administrator, or technical user (etc.) can make affirmative decisions on how to improve or alter the identified cruxes to improve the searches, and thereby improving search performance and functionality. Further advantages of crux detection, as described herein include providing an automated technique for scanning an entire search definition set for cruxes, reduce development and support time of searches, support late-stage changes to searches through automated checking and analysis, improve performance by reducing database engine workload through improved search definitions, reduce database operating expenses through executing more efficient searches which allow for a smaller database footprint (e.g. resource usage), avoid manual errors in search definition analysis and testing, and offering a test or analytical method independent of concrete or specific test data (and thereby avoiding the expense of generating test data).

Crux detection as described herein generally uses a structural approach to identify cruxes in searches and thereby improve search performance. A structural approach focuses on the elements in the searches, how they are connected, and how the searches are connected within a set (e.g. interdependent). By using a structural approach to identify crux elements in a search, the results are not dependent upon particular data sets or particular tests, but are broadly correct and useful in most, or in some cases all, scenarios.

Crux detection functionality, as described herein, can be used as part of search definition development, testing, or maintenance. Generally, crux detection can be used to analyze and improve a search before executing the search, and so can supplement search optimization routines used during search execution by improving search quality before execution or optimization.

In some cases, in addition to providing crux detection results to developers, testers, or administrators, crux detection results can be provided to analytical software, similar to testing algorithms or compiler optimization routines, for making or recommending changes to the search definitions based on the identified cruxes.

Crux detection functionality, and other search analysis functionality as described herein, can be provided in integrated development environments (IDEs), data management software, data integration software, ERP software, database or database management systems, or other code or search analysis software systems. Examples of such tools are: SAP Enterprise Search™ technology, SAP NetWeaver Application Server™ technology, SAP S/4HANA™ technology, SAP S/4HANA Cloud™ technology, SAP S/4HANA On Premise™ technology, all by SAP SE of Walldorf, Germany.

<FIG> is a block diagram of an example system <NUM> implementing crux detection. A crux detector <NUM> can automatically generate crux detection results <NUM>, which can identify one or more cruxes in a search definition or a search definition set <NUM>. The crux detector <NUM> can provide crux detection functionality directly, or it may be integrated in an application, such as an integrated development environment (IDE) or with a user interface <NUM>.

The crux detector <NUM> can receive a crux detection request <NUM>. The request <NUM> can be a function call or can be made through an API or other interface (e.g. <NUM>) of the crux detector <NUM>. In some embodiments, the request <NUM> can be a trigger which initiates functionality in the crux detector <NUM>, such as based on an input or a context change.

The crux detection request <NUM> can include one or more variables for generating the requested crux results <NUM>. For example, the request <NUM> can include a reference to a search definition set <NUM> to analyze to detect cruxes. Such a reference can include a search definition set identifier or a location for the search definition set <NUM>, such as a database <NUM> housing or implementing the search definition set (and can further include identifiers or locations for such searches within the database), or a combination thereof. In some embodiments, the request <NUM> can include the search definition set <NUM> itself, such as stored in a data structure or file.

Further, the crux detection request <NUM> can include a reference to a hierarchical representation of the search definition set <NUM>, which can include an identifier or location for the hierarchical representation. In some embodiments, the request <NUM> can include the hierarchical representation <NUM> itself, such as stored in a data structure or file.

Further, the crux detection request <NUM> can include a reference to detection criteria <NUM>, or to the separate types of detection criteria 108a-c, which can include an identifier or location for the detection criteria. In some embodiments, the request <NUM> can include the detection criteria <NUM>, such as stored in a data structure or file.

In some embodiments, request <NUM> inputs such as the search definition set <NUM>, the detection criteria <NUM>, and/or the hierarchical representation <NUM> can be determined based on a context of the crux detector <NUM> when it receives the request. For example, if the request <NUM> is generated in an IDE to trigger the crux detector <NUM>, such inputs <NUM>, <NUM>, <NUM> (and/or other inputs) can be obtained for the request or the crux detector by the context of the request in the IDE.

The crux detection request <NUM> can also include one or more configurable configuration settings or options, such as a value indicating a preferred type of results <NUM> report, an indicator for availability of a hierarchical representation <NUM> applicable to the request <NUM>, or a threshold score for detected cruxes in the search definition set.

The crux detector <NUM> can access a search definition set <NUM> for generating crux detection results <NUM> as described herein. The search definition set <NUM> can be obtained from a database <NUM>, such as based on the crux detection request <NUM>. The search definition set <NUM> can include one or more existing search definitions, which can be identified individually or as a group or set of groups.

The crux detector <NUM> can access a hierarchical representation <NUM> of the search definition set <NUM> for analyzing to detect cruxes <NUM> as described herein. In some cases, the hierarchical representation <NUM> can be accessed based on the crux detection request <NUM>. In some embodiments, the crux detector <NUM> can generate the hierarchical representation <NUM> based on the search definition set <NUM>. For example, the crux detector <NUM> can determine if a hierarchical representation <NUM> of the search definition set <NUM> is available; if so, the crux detector can access the hierarchical representation to before crux detection analysis, whereas if a hierarchical representation is not available (or otherwise unsuitable), the crux detector can generate the hierarchical representation based on the search definition set for use in crux detection.

The crux detector <NUM> can analyze the search definition set <NUM> through the hierarchical representation <NUM> to generate crux detection results <NUM>. The crux detection results <NUM> can include one or more cruxes detected in the search definitions of the search definition set <NUM>. The crux detector <NUM> can use the detection criteria <NUM> to detect cruxes in the search definition set <NUM>. For example, the crux detector <NUM> can use context criteria 108a and/or search definition criteria 108b to focus on portions (e.g. elements) of the search definitions in the search definition set <NUM> that are likely to be or include cruxes. Further, the crux detector <NUM> can use crux criteria 108c to identify particular portions (e.g. elements) of the searches that qualify as cruxes. The detection criteria <NUM> can be used in conjunction with the hierarchical representation <NUM> to focus the search definitions in the search definition set <NUM> and detect cruxes therein.

The crux detection results <NUM> can be provided through a user interface / API <NUM>, such as by displaying a list or report of detected cruxes and the particular search definitions in which they are found, or by providing a file or data structure(s) of the detected cruxes via an interface, such as in a return from a service or function call, or a messaging system.

In practice, the systems shown herein, such as system <NUM>, can vary in complexity, with additional functionality, more complex components, and the like. For example, there can be additional functionality within the crux detector <NUM>. Additional components can be included to implement security, redundancy, load balancing, report design, and the like.

The described computing systems can be networked via wired or wireless network connections, including the Internet. Alternatively, systems can be connected through an intranet connection (e.g., in a corporate environment, government environment, or the like).

The system <NUM> and any of the other systems described herein can be implemented in conjunction with any of the hardware components described herein, such as the computing systems described below (e.g., processing units, memory, and the like). In any of the examples herein, the instructions for implementing the crux detector <NUM>, the input, output and intermediate data of running the crux detector <NUM>, or the database <NUM> or the user interface /API <NUM>, and the like can be stored in one or more computer-readable storage media or computer-readable storage devices. The technologies described herein can be generic to the specifics of operating systems or hardware and can be applied in any variety of environments to take advantage of the described features.

<FIG> is an entity diagram depicting a search definition set and hierarchical representation arrangement <NUM>. A crux detector, as described herein, can detect cruxes in search definition sets <NUM> using hierarchical representations <NUM>, as similarly described and shown in <FIG>.

A search definition set <NUM> includes one or more search definitions, such as Search Definition <NUM> through Search Definition n 203a-n. A search definition 203a-n can include one or more elements 205a-n, which define the search described by the search definition. A search definition 203a-n can further include one or more dependencies <NUM>, such as with other searches in the search definition set <NUM>. A dependency <NUM> can be an element 205a-n, or a portion of an element. Generally, a dependency can be found within an element 205a-n. A search definition 203a-n can also include metadata <NUM> about the search definition. The metadata <NUM> can include relevance indicators 206a-n for the elements 205a-n in the search definition 203a-n. A particular element 205a-n can have or otherwise be associated with one or more relevance indicators 206a-n. For example, a given element, e.g. 205a, can have a context relevance indicator and a search-definition relevance indicator, e.g. 206a. A search definition 203a-n can also include one or more crux indicators <NUM>, to indicate if a crux is found within the search definition or in the search definition set <NUM>. In some embodiments, the crux indicators <NUM> can be associated with particular elements 205a-n, to indicate if a given element is a crux.

A search definition set <NUM> can be represented by a hierarchical representation <NUM>. A hierarchical representation <NUM> can include one or more nodes 213a-n. Generally, a node 213a-n can be associated with (e.g. represent) a particular search definition 203a-n in the search definition set <NUM>. The nodes 213a-n can include search definition references 215a-n, which can indicate the search definition 203a-n represented by that node. For example, the Search Definition <NUM> Node 213a can represent the Search Definition <NUM>203a, and can include a reference to Search Definition <NUM>, SD reference 215a. The nodes 213a-n can include other information as well about their associated search definitions.

In some embodiments, the search definition metadata <NUM> can reside in the search definition (e.g. 203a), or can be closely linked or associated with the search definition. In other embodiments, the metadata <NUM> can be included in the search definition node 213an, or outside the search definition 203a-n and the hierarchical representation <NUM>, but associated with the search definitions and/or the hierarchical representation.

A search definition set <NUM> can have one or more copies or instances of itself (e.g. the search definitions 203a-n). Such copies or instances can include variations of the original search definitions 203a-n, such as may be generated or updated through or during crux detection as described herein. For example, a working copy of the search definition set <NUM> can be created for use in crux detection. A hierarchical representation <NUM> may also reference such copies of the search definition set <NUM>. For example, a node 213a-n, such as Search Definition <NUM> Node 213a, can include additional references 215a to such additional copies of its associated search definition, e.g. Search Definition <NUM>203a.

<FIG> is a flowchart of an example method <NUM> of analyzing a search definition set to detect one or more cruxes, and can be implemented, for example, by the system described in <FIG> and using data objects as described in <FIG>.

At <NUM>, a request for crux detection can be received. A crux detection request can include one or more variables or input arguments, such as described herein. For example, a crux detection request can include a search definition set or an identifier or location for a search definition set, a hierarchical representation or an identifier or location for a hierarchical representation, detection criteria, a target (e.g. starting or initial) search definition, or other settings for detecting cruxes in a search definition set.

At <NUM>, a hierarchical representation of the search definitions in the search definition set can be generated. Generating the hierarchical structure can include identifying the search definitions in the search definition set and arranging the search definitions based on dependencies between them. Generally, the hierarchical representation can include nodes or other data structure, which represent the search definitions, which are arranged based on the dependencies between their respective search definitions.

For example, generating the hierarchical representation at <NUM> can include identifying the discrete search definitions for analysis. Identifying the search definitions can include putting the search definitions into a queue (e.g. identifiers for the search definitions). For each of the identified search definitions (e.g. the definitions in the queue), generating the hierarchical representation at <NUM> can include identifying references to other search definitions within the current search definition. For example, an SQL search definition can reference other search definitions in a FROM clause or an ASSOCIATION-TO clause. Found search definition references can be recorded along with the dependency (e.g. a node can be created and linked to the current node based on the dependency), and further any search definition found that is not currently known (e.g. in the queue) can be added to the set to analyze (e.g. added to the queue). Analyzing the complete set of search definitions, including new search definitions discovered by reference within a search definition, and recording their dependencies, such as by generating and linking nodes, can result in a complete hierarchical representation of the search definitions in the search definition set.

At <NUM>, a hierarchical representation of the search definition set can be accessed. In some embodiments, the hierarchical representation can have been created at step <NUM>, and so accessing the hierarchical representation may be accomplished by completing the generation of the hierarchical representation. In other embodiments, the hierarchical representation may not have been generated at <NUM>, such as when it was already available at the start of the crux detection process <NUM>. In such scenarios, the hierarchical representation can be accessed at <NUM> based on the received crux detection request from <NUM>, which can include de-referencing an identifier or pointer, accessing a data storage facility or repository, data file, data structure, or memory location. In some cases, the hierarchical representation can be available in local memory, and so readily accessible.

At <NUM>, the hierarchical representation can be reduced. Reducing the hierarchical representation at <NUM> can include removing search definitions (e.g. nodes) from the hierarchical representation which are not related to a target (e.g. starting, initial, root) search definition. For example, for a given starting search definition (e.g. node), the hierarchical representation can be reduced to include only search definitions (e.g. nodes) upon which the target search definition depends, either directly or indirectly. Removing an unrelated search definition can include deleting the search definition (e.g. node) from the hierarchical representation, or setting a flag (or other indicator) to show that the search definition should be ignored. Alternatively or additionally, removing unrelated search definitions can include setting a flag (or other indicator) to show that search definitions connected (e.g. related to the target search definition) should be analyzed. Such flags can be set by traversing the hierarchical representation starting from the target search definition.

Additionally or alternatively, each search definition in the hierarchical representation can be analyzed. If the target search definition does not depend (directly or indirectly) on a given search definition, flag that given search definition for removal (e.g. set an indicator for deletion, set an indicator to ignore, or delete it from the hierarchical representation). Thereafter, any search definitions flagged for removal can be deleted from the hierarchical representation (if such is the embodiment).

Reducing the hierarchical representation at <NUM> can include generating a copy of the hierarchical representation and reducing the copy.

Generally, reducing the hierarchical representation at <NUM> can improve the efficiency of detecting cruxes in the search definitions, such as by limiting the number of objects to be analyzed. Further, reducing the hierarchical representation can help increase the accuracy of the structural approach to crux detection by removing unnecessary structure, which could introduce incorrect analysis or results.

At <NUM>, the reduced hierarchical representation can be focused. Focusing the hierarchical representation at <NUM> can include removing irrelevant or unnecessary elements from the search definitions represented by the reduced hierarchical representation. Such elements can include elements known to be unrelated or inapplicable to crux identification (e.g. elements that won't be cruxes). Focusing the hierarchical representation at <NUM> can include identifying such inapplicable or irrelevant elements based on particular criteria. Once identified, the hierarchical representation can be focused by deleting or flagging the inapplicable or irrelevant elements to be ignored (skipped, or otherwise remain unanalyzed).

Focusing the hierarchical representation at <NUM> can include generating copies of the search definitions represented by the hierarchical representation and focusing the copies. The hierarchical representation can be updated to include references to the copies in place of or in addition to the original (e.g. previous) search definitions. In some embodiments, such copies of the search definitions can be generated in a special or different format, such as a structured representation, which can facilitate analysis (e.g. search and detection) and tagging of elements.

Focusing the hierarchical representation at <NUM> can include removing context-irrelevant elements at <NUM> and/or removing search-definition-irrelevant elements at <NUM>. In some embodiments, removing context-irrelevant elements <NUM> and removing search-definition-irrelevant elements <NUM> can be performed in order (e.g. one before the other). In other embodiments, removing context-irrelevant elements <NUM> and removing search-definition-irrelevant elements <NUM> can be done in parallel, or can be integrated, such as in a step-wise process (e.g. perform one or both for one node, traverse to the next node, perform one or both for this node, and so on).

Removing context-irrelevant elements at <NUM> can include analyzing one or more search definitions based on the hierarchical representation to identify inapplicable or irrelevant elements based on context. Identifying inapplicable or irrelevant elements based on context can include analyzing or comparing the elements to context criteria. Elements matching the context criteria can be removed, such as by deleting or tagging to delete (and later removed, such as in aggregate) or ignore, from the search definition. Alternatively, the context criteria can identify applicable or relevant elements, and elements not matching the criteria can be removed.

Generally, removing context-irrelevant elements at <NUM> is performed against the top-level search definition according to the hierarchical representation (e.g. against the search definition represented by the root node). In some additional or alternative embodiments, removing context-irrelevant elements at <NUM> can be performed against additional or further search definitions based on the hierarchical representation.

Removing search-definition-irrelevant elements at <NUM> can include analyzing one or more search definitions based on the hierarchical representation to identify inapplicable or irrelevant elements based on the search definition. Identifying inapplicable or irrelevant elements based on the search definition can include analyzing or comparing the elements to search-definition criteria. Elements matching the search-definition criteria can be removed, such as by deleting or tagging to delete (and later removed, such as in aggregate) or ignore, from the search definition. Alternatively, the search-definition criteria can identify applicable or relevant elements, and elements not matching the criteria can be removed.

Generally, removing search-definition-irrelevant elements at <NUM> is performed against all search definitions except the top-level search definition according to the hierarchical representation (e.g. against all but the the search definition represented by the root node). In some additional or alternative embodiments, removing search-definition-irrelevant elements at <NUM> can be performed against the top-level search definition according to the hierarchical representation, or against a subset of the search definitions in the hierarchical representation.

Focusing the hierarchical representation at <NUM> can include traversing the hierarchical representation and performing the analysis to remove inapplicable or irrelevant elements (e.g. <NUM> and/or <NUM> as applicable) during the traversal. Generally, the traversal includes analyzing parent (e.g. higher level) search definitions before child (e.g. lower level) search definitions. Performing steps <NUM> and <NUM> (e.g. including <NUM> and/or <NUM>) can result in a fully reduced hierarchical representation.

Generally, focusing the hierarchical representation at <NUM> can improve the efficiency of detecting cruxes in the search definitions, such as by limiting the number of objects to be analyzed. Further, focusing the hierarchical representation can help increase the accuracy of the structural approach to crux detection by removing unnecessary elements, which could introduce incorrect analysis or results.

At <NUM>, cruxes are identified in the reduced and focused hierarchical representation. Identifying cruxes at <NUM> includes analyzing the remaining elements of the search definitions based on the reduced and focused hierarchical representation. For example, the hierarchical representation can include traversing the hierarchical representation and analyzing the search definitions for cruxes during the traversal. Analyzing a search definition to identify cruxes includes analyzing or comparing elements of the search definition against crux criteria. Additionally or alternatively, the analysis to identify cruxes can include analyzing the elements against their location or place within the hierarchical representation, such as compared to a parent search definition.

When a crux is identified, the crux element can be flagged as containing a crux (e.g. a crux indicator associated with the element can be set to indicate the element is a crux). Further, the search definition can additionally or alternatively be flagged as containing a crux element. Further, the top-level search definition based on the hierarchical representation can be flagged to indicate the search definition set contains a crux (or the hierarchical representation can be flagged additionally or alternatively).

At <NUM>, the crux detection results can be provided. Providing cruxes at <NUM> can be performed based, at least in part, on crux indicators or other flags set at <NUM>. Providing the crux detection results can include displaying the search definitions determined to have cruxes, such as in a list. Alternatively or additionally, the cruxes (e.g. elements of the search definitions identified as cruxes) detected in the search definitions can be displayed, or can be highlighted in a display of the search definition(s). Additionally or alternatively, a report can be provided including the crux detection results, such as delineating the search definitions determined to have cruxes and/or listing the elements identified as cruxes for the various search definitions. In some embodiments, providing the crux detection results at <NUM> can include providing a data structure storing the results through an API, such as to another system, or through a messaging interface.

The crux detection results are provided to a code analyzer or optimizer. Such a code analyzer or optimizer (e.g. an optimizer in a compiler) changes one or more of the cruxes to an improved operation or set of operations (e.g. a less resource-intensive form). Alternatively or additionally, such a code analyzer or optimizer can provide suggestions for altering one or more of the cruxes to improve performance, or results, or the like. Such suggestions can be provided along with the cruxes, such as displayed in an IDE.

The method <NUM> and any of the other methods described herein can be performed by computer-executable instructions (e.g., causing a computing system to perform the method) stored in one or more computer-readable media (e.g., storage or other tangible media) or stored in one or more computer-readable storage devices. Such methods can be performed in software, firmware, hardware, or combinations thereof. Such methods can be performed at least in part by a computing system (e.g., one or more computing devices).

The illustrated actions can be described from alternative perspectives while still implementing the technologies. For example, "receive" can also be described as "send" from a different perspective.

<FIG> are an example <NUM> illustrating how a search definition set can be represented in a hierarchical representation, which can then be transformed for crux detection analysis. The example <NUM> illustrates, in part, the process <NUM> shown in <FIG> through the search definition set <NUM> and its hierarchical representation. <FIG> illustrates a search definition set <NUM> and an associated hierarchical representation <NUM>. A search definition set <NUM> can include Search Definition <NUM><NUM>, having Elements 404a, through Search Definition <NUM><NUM>, having Elements 408a.

The Search Definition Set <NUM> can be represented by the Hierarchical Representation <NUM>. The hierarchical representation <NUM> can include nodes SD01-SD16 <NUM>-<NUM> representing the Search Definitions <NUM>-<NUM><NUM>, <NUM>. The nodes <NUM>-<NUM> can be arranged based on dependencies between the search definitions <NUM>-<NUM><NUM>, <NUM>. The nodes <NUM>-<NUM> can reference their respective search definitions <NUM>, <NUM>. For example, node SD01 <NUM> can point to Search Definition <NUM><NUM>, such as through a name, location, other identifier, or combination thereof.

<FIG> continues the example <NUM>, illustrating a reduced hierarchical representation <NUM>. Based on the target search definition being Search Definition <NUM><NUM>, represented by SD01 <NUM>, the hierarchical representation <NUM> can be reduced by removing the nodes of search definitions unrelated to SD01 <NUM>, which are SD02 <NUM>, SD05 <NUM>, SD06 <NUM>, SD12 <NUM>, SD13 <NUM>, and SD16 <NUM>. Removing these unrelated nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can including flagging the nodes to be ignored or deleting them from the hierarchical representation <NUM>, as described herein.

<FIG> continues the example <NUM>, illustrating a reduced and focused hierarchical representation <NUM> with the altered search definition set <NUM>. Focusing the reduced hierarchical representation <NUM> can result in an altered search definition set, Search Definition Set' <NUM>, which can include altered search definitions, Search Definition <NUM>' <NUM> to Search Definition <NUM>' <NUM>. Generally, the focused search definitions <NUM>'-<NUM>' <NUM>, <NUM> include an altered set of elements. For example, Search Definition <NUM>' <NUM> includes Elements' 434a. Generally, the altered elements are a subset of the original elements for a search definition. For example, Elements' 434a of Search Definition <NUM>' <NUM> is a subset of Elements 404a of Search Definition <NUM><NUM>. The new element sets 434a, 436a are the elements not removed during focusing, e.g. are elements deemed relevant or applicable to the crux detection. The nodes in the hierarchical representation <NUM> can include additional references to the altered search definitions <NUM>, <NUM> in the focused search definition set <NUM>. Generally, the focused search definition set <NUM> only includes search definitions included in the reduced hierarchical representation <NUM>, and not search definitions in the original search definition set <NUM> which were removed (e.g. Search Definition <NUM><NUM> may not be included in the Search Definition Set' <NUM>).

In any of the examples herein, a search definition includes interpretable text, code, or pseudo-code detailing a search for data against a data source. A search definition can be executable by a data source, or data management system. A search definition can be, for example, a search string, query, search object or data structure, stored procedure, database view or materialized view, or the like. For example, a search definition can be an SQL query or a CDS-based search view (Core Data Services™ technology, from SAP SE of Walldorf, Germany).

In any of the examples herein, a search definition set is a collection of one or more search definitions. In some cases, a search definition set can represent a search model, which can express how to search or otherwise obtain one or more given classes or groupings of data. A search definition set can also be referred to as a stack, or search stack.

In any of the examples herein, an element of a search definition can include an operation, field, or other programmatic statement, or portion or clause of an operation or statement, in the search definition. In some cases or embodiments, an element can be defined, at least in part, by the line or lines of code in which the element is found.

In any of the examples herein, a hierarchical representation can include a data structure or collection of data structures capable of representing connections or relations (e.g. dependencies) between items (e.g. search definitions) within the data structure. For example, a hierarchical representation can include a tree, array or multiple array, or graph data structure. In some cases, a graph representation can be a directed graph. In some cases, a hierarchical representation can include multiple top-level or root items.

In any of the examples herein, a search definition can be dependent on another search definition. Such dependencies can be direct or indirect. For example, Search <NUM> referencing or otherwise using Search <NUM> (in whole or in part), is a direct dependency. Additionally, if Search <NUM> references or otherwise uses Search <NUM> (in whole or in part), then Search <NUM> is indirectly dependent on Search <NUM> (while Search <NUM> is directly dependent on Search <NUM>). A search definition can be dependent upon multiple searches, or no searches.

In any of the examples herein, a search implementation crux, or simply implementation crux or crux, can be defined or identified by the crux criteria, as described herein (e.g. at Example <NUM>). For example, a crux can include an element that is key to the execution or performance of the search, critical, performance-impacting, or the like. A crux can be an operation or combination of operations in a search definition. In some cases, a crux can be a particular expression or implementation in a search definition, such as a particular SQL expression or type of expression. Example operations that can be cruxes are:.

In some cases, a crux can be a particular combination of operations and operands, such as a JOIN between tables of a minimum size, or a GROUP BY across multiple tables, and the like. In some cases, a crux can be an element or operation in a particular location within the hierarchy of search definitions, such as an operation that will be widely invoked based on the hierarchy of search definitions. Such cruxes can be defined within the crux criteria, as described herein.

In some cases, a crux can be redundant operations, either within a search definition or within different search definitions in the same search definition set. A redundant operation can include two of the same operations, or two different operations or combinations of operations which provide the same results when executed.

Often cruxes are elements which are likely to require the most resources to execute or to optimize when the search is performed. For example, cruxes can be elements which are likely to impact the speed or efficiency of the search. In some cases, a crux can be an element which is likely to most impact the results obtained from performing the search, such as by over-producing or under-producing results. In some cases, cruxes can be defined based on a particular data schema, or particular database management system implementation or arrangement. In this way, cruxes can be customized (e.g. through crux criteria) for particular search implementations, data storage or database implementations, or particular network or system implementations.

In any of the examples herein, context criteria can include values, rules, or logic for identifying elements that are relevant (or, alternately, irrelevant) for a search context. For example, context criteria can be used to identify elements relevant for an Enterprise search (and elements not meeting such context criteria can be deemed irrelevant for an Enterprise search). Example context criteria for identifying relevant elements of an Enterprise search are:.

Context criteria can generally be available in a database or other data repository, data file, registry, or data structures or objects accessible by a crux detector. In some cases, context criteria can be directly implemented in a crux detector, as described herein, or can be passed to a crux detector as part of a crux detection request.

In any of the examples herein, search-definition criteria can include values, rules, or logic for identifying elements that are relevant (or, alternately, irrelevant) for a given implementation of a search definition. For example, search-definition criteria can be used to identify elements relevant for a search defined in a given language, such as SQL (and elements not meeting such search-definition criteria can be deemed irrelevant for a search in that language or implementation). Example search-definition criteria for identifying relevant elements in an SQL implementation are:.

Search-definition criteria can generally be available in a database or other data repository, data file, registry, or data structures or objects accessible by a crux detector. In some cases, search-definition criteria can be directly implemented in a crux detector, as described herein, or can be passed to a crux detector as part of a crux detection request.

In any of the examples herein, crux criteria can include values, rules, or logic for identifying elements that are cruxes of a search definition. For example, crux criteria can be used to identify elements in a search definition that are performance-impacting. In this way, crux criteria can define one or more cruxes, thereby enabling detection of cruxes within a search definition or search definition set. Example crux criteria for identifying implementation cruxes in an SQL implementation are:.

Crux criteria can generally be available in a database or other data repository, data file, registry, or data structures or objects accessible by a crux detector. In some cases, crux criteria can be directly implemented in a crux detector, as described herein, or can be passed to a crux detector as part of a crux detection request.

In any of the examples herein, crux detection can be performed through multiple cycles to detect cruxes across all search definitions in a search definition set. For example, as seen in example <NUM> shown in <FIG>, a hierarchical representation can include more than one top-level search definition in some cases. In such cases, crux detection, such as through process <NUM> shown in <FIG>, can be repeated for each of the top-level nodes in the hierarchical representation. Further, the process in such cases need not be the entire process <NUM> shown in <FIG>, but can be repeated starting from step <NUM> (accessing the hierarchical representation) or step <NUM> (reducing the hierarchical representation) through the end (step <NUM>, providing the crux detection results), for each of the top-level nodes. In this way, each "tree" within a hierarchical representation can be analyzed for cruxes through cyclical crux detection.

In some embodiments, a target or starting search definition can be provided in a crux detection request. In additional or alternative embodiments, a crux detector can identify all top-level nodes in a hierarchical representation, and perform crux detection for each top-level nodes. Such cases can include generating copies of the hierarchical representation for use in each cycle, or clearing indicators between each cycle.

The following is an example search definition (a CDS-based Search View):
@AbapCatalog. sqlViewName: 'ESH_U_BANK'
@AccessControl. authorizationCheck: #CHECK
@ObjectModel. serviceQuality: #P
@ClientHandling. algorithm: #SESSION_VARIABLE
@ClientHandling. type: #INHERITED
@AbapCatalog. compareFilter: true
@Metadata. allowExtensions: true
@EndUserText. label: 'Banks'
@Consumption. semanticObject: 'Bank'
@ObjectModel. semanticKey: ['BANKS', 'BANKL']
@Search. searchable: true
@EnterpriseSearch. enabled: true
@UI. headerInfo. title: {value: 'BANKL'}
define view ESH_S_BANK
with parameters
@Consumption. hidden: true
@Environment. systemField: #SYSTEM_LANGUAGE
P_Language: abap. lang
as select from ESH_N_BANK_BANK
{
@EndUserText. label: 'Bank Country'
@Consumption. semanticObject: 'BankCountry'
@Search. defaultSearchElement: true
@UI. identification: { position: <NUM> }
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
banks,
@EndUserText. label: 'Bank Key'
@Consumption. semanticObject: 'Bank'
@Search. defaultSearchElement: true
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
@EnterpriseSearch. defaultValueSuggestElement: true
@ObjectModel. element: ['BANKA']
@UI. textArrangement: #TEXT_LAST
bankl,
@EndUserText. label: 'Created on'
erdat,
@EndUserText. label: 'Created by'
ernam,
@EndUserText. label: 'Bank Name'
@Consumption. semanticObject: 'BankName'
@Search. defaultSearchElement: true
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
@EnterpriseSearch. defaultValueSuggestElement: true
banka,
@EndUserText. label: 'Region'
@Consumption. semanticObject: 'Region'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
provz,
@EndUserText. label: 'Street'
@Consumption. semanticObject: 'StreetAddressName'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
stras,
@Consumption. semanticObject: 'CityName'
@UI. identification: { position: <NUM> }
@EnterpriseSearch. filteringFacet: { default, displayPosition: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
ort01,
@EndUserText. label: 'SWIFT Code'
@Consumption. semanticObject: 'SWIFTCode'
@Search. defaultSearchElement: true
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
swift,
@EndUserText. label: 'Bank Group'
@Consumption. semanticObject: 'BankGroup'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
bgrup,
@EndUserText. label: 'Is Postbank Account'
xpgro,
@EndUserText. label: 'Is Bank Deleted'
loevm,
@EndUserText. label: 'Bank Number'
@Consumption. semanticObject: 'BankNumber'
@Search. defaultSearchElement: true
@UI. identification: { position: <NUM> }
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
@EnterpriseSearch. defaultValueSuggestElement: true
bnklz,
@EndUserText. label: 'Post Bank Account Number'
@Consumption. semanticObject: 'PostOfficeBankAccountNumber'
@UI. identification: { importance: #MEDIUM, position: <NUM> }
pskto,
adrnr,
@Consumption. semanticObject: 'Branch'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
brnch,
@EndUserText. label: 'Check Digit Cal. Method'
chkme,
@EndUserText. label: 'Bank Data Format'
vers,
@EndUserText. label: 'Bank Country Name'
@Consumption. semanticObject: 'CountryName'
@UI. identification: { position: <NUM> }
@EnterpriseSearch. filteringFacet: { default, displayPosition: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
_BANK2LAND1[ <NUM>: DOMALANGU = $parameters. P_Language ]. VALUE _TEXT as
VALUE_TEXT1,
@EndUserText. label: 'Region Name'
@Consumption. semanticObject: 'ReginOfOriginName'
@UI. identification: { position: <NUM> }
@EnterpriseSearch. filteringFacet: { default, displayPosition: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
_BANK2REGION[ <NUM>: spras = $parameters. P_Language ]. bezei,
@UI. identification: { position: <NUM> }
@EndUserText. label:'Internal Bank Category'
@Consumption. semanticObject: 'InternalBankCategoryDesc'
_BankAdditionFields. _BankCategory[ <NUM>:Langu =
$parameters. P_Language]. IntBankCateg,
@EndUserText. label: 'Created by'
_BANK2USER. _TO_USER_NAME. name_text,
@EndUserText. label: 'Post Bank Account'
@UI. identification: { position: <NUM> }
_POST_BANK_ACCT[ <NUM>: DOMALANGU = $parameters. P_Language
]. VALUE _TEXT as VALUE_TEXT2,
@EndUserText. label: 'Is Bank Deleted Text'
_BANK2XFELD[ <NUM>: DOMALANGU = $parameters. P_Language ]. VALUE _TEXT
}.

The following is the search definition above, with context-relevant fields flagged (underlined). @AbapCatalog. sqlViewName: 'ESH_U_BANK'
@AccessControl. authorizationCheck: #CHECK
@ObjectModel. serviceQuality: #P
@ClientHandling. algorithm: #SESSION_VARIABLE
@ClientHandling. type: #INHERITED
@AbapCatalog. compareFilter: true
@Metadata. allowExtensions: true
@EndUserText. label: 'Banks'
@Consumption. semanticObject: 'Bank'
@ObjectModel. semanticKey: ['BANKS', 'BANKL']
@Search. searchable: true
@EnterpriseSearch. enabled: true
@UI. headerInfo. title: {value: 'BANKL'}
define view ESH_S_BANK
with parameters
@Consumption. hidden: true
@Environment. systemField: #SYSTEM_LANGUAGE
P_Language: abap. lang
as select from ESH_N_BANK_BANK
{
@EndUserText. label: 'Bank Country'
@Consumption. semanticObject: 'BankCountry'
@Search. defaultSearchElement: true
@UI. identification: { position: <NUM> }
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
banks,
@EndUserText. label: 'Bank Key'
@Consumption. semanticObject: 'Bank'
@Search. defaultSearchElement: true
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
@EnterpriseSearch. defaultValueSuggestElement: true
@ObjectModel. element: ['BANKA']
@UI. textArrangement: #TEXT_LAST
bankl,
@EndUserText. label: 'Created on'
erdat,
@EndUserText. label: 'Created by'
ernam,
@EndUserText. label: 'Bank Name'
@Consumption. semanticObject: 'BankName'
@Search. defaultSearchElement: true
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
@EnterpriseSearch. defaultValueSuggestElement: true
banka,
@EndUserText. label: 'Region'
@Consumption. semanticObject: 'Region'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
provz,
@EndUserText. label: 'Street'
@Consumption. semanticObject: 'StreetAddressName'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
stras,
@Consumption. semanticObject: 'CityName'
@UI. identification: { position: <NUM> }
@EnterpriseSearch. filteringFacet: { default, displayPosition: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
ort01,
@EndUserText. label: 'SWIFT Code'
@Consumption. semanticObject: 'SWIFTCode'
@Search. defaultSearchElement: true
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
swift,
@EndUserText. label: 'Bank Group'
@Consumption. semanticObject: 'BankGroup'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
bgrup,
@EndUserText. label: 'Is Postbank Account'
xpgro,
@EndUserText. label: 'Is Bank Deleted'
loevm,
@EndUserText. label: 'Bank Number'
@Consumption. semanticObject: 'BankNumber'
@Search. defaultSearchElement: true
@UI. identification: { position: <NUM> }
@Search. ranking: #HIGH
@EnterpriseSearch. filteringAttribute: { default, displayPosition: <NUM> }
@EnterpriseSearch. defaultValueSuggestElement: true
bnklz,
@EndUserText. label: 'Post Bank Account Number'
@Consumption. semanticObject: 'PostOfficeBankAccountNumber'
@UI. identification: { importance: #MEDIUM, position: <NUM> }
pskto,
adrnr,
@Consumption. semanticObject: 'Branch'
@UI. identification: { position: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
brnch,
@EndUserText. label: 'Check Digit Cal. Method'
chkme,
@EndUserText. label: 'Bank Data Format'
vers,
@EndUserText. label: 'Bank Country Name'
@Consumption. semanticObject: 'CountryName'
@UI. identification: { position: <NUM> }
@EnterpriseSearch. filteringFacet: { default, displayPosition: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
BANK2LAND1[ <NUM>: DOMALANGU = $parameters. P Language ]. VALUE
TEXT
as VALUE TEXT1,
@EndUserText. label: 'Region Name'
@Consumption. semanticObject: 'ReginOfOriginName'
@UI. identification: { position: <NUM> }
@EnterpriseSearch. filteringFacet: { default, displayPosition: <NUM> }
@Search. ranking: #MEDIUM
@Search. defaultSearchElement: true
BANK2REGION[ <NUM>: spras = $parameters. P Language ]. bezei,
@UI. identification: { position: <NUM> }
@EndUserText. label:'Internal Bank Category'
@Consumption. semanticObject: 'InternalBankCategoryDesc'
BankAdditionFields. BankCategory[ <NUM>:Langu =
$parameters. P_Language]. IntBankCateg,
@EndUserText. label: 'Created by'
_BANK2USER. _TO_USER_NAME. name_text,
@EndUserText. label: 'Post Bank Account'
@UI. identification: { position: <NUM> } POST BANK ACCT[ <NUM>: DOMALANGU =
$parameters. P_Language ]. VALUE_TEXT as VALUE TEXT2,
@EndUserText. label: 'Is Bank Deleted Text'
_BANK2XFELD[ <NUM>: DOMALANGU = $parameters. P_Language ]. VALUE_TEXT
}.

The following is the search definition above, with inapplicable fields removed (e.g. not the context-relevant fields that are flagged above). @AbapCatalog. sqlViewName: 'ESH_U_BANK'
define view ESH_S_BANK_reduced
with parameters
P_Language: abap. lang
as select from ESH_N_BANK_BANK
{
banks,
bankl,
banka,
provz,
stras,
ort01,
swift,
bgrup,
bnklz,
pskto,
brnch,
_BANK2LAND1[ <NUM>: DOMALANGU = $parameters. P_Language ]. VALUE_TEXT as
VALUE_TEX. T1,
_BANK2REGION[ <NUM>: spras = $parameters. P_Language ]. bezei,
_BankAdditionFields. _ BankCategory[ <NUM>:Langu =
$parameters. P _Language]. IntBankCateg,
_POST_BANK_ACCT[ <NUM>: DOMALANGU = $parameters. P_Language
]. VALUE_TEXT as VALUE_TEXT2
}.

The following search definition is an example search definition (CDS-based search view) that is ready for search-definition criteria analysis, with the search-definition relevant fields highlighted (underlined):
@AbapCatalog. sqlViewName: 'ESH_L_BANK_BANK'
@AccessControl. authorizationCheck: #NOT _REQUIRED
@ObjectModel. serviceQuality: #P
@ClientHandling. algorithm: #SESSION_VARIABLE
@ClientHandling. type: #INHERITED
@AbapCatalog. compareFilter: true
@EndUserText. label: 'Bank master record'
define view ESH_N_BANK_BANK
as select from bnka
association [<NUM>. *] to ESH_N_LAND1_3_LAND1 as _BANK2LAND1
on $projection. banks = _BANK2LAND1. DOMVALUE_L
association [<NUM>. *] to t005u as _BANK2REGION
on $projection. banks = _BANK2REGION. landl and
$projection. provz = _BANK2REGION. bland
association [<NUM>. <NUM>] to ESH_N_USER_USER as _BANK2USER
on $projection. ernam = _BANK2USER. bname
association [<NUM>. *] to ESH_N_XFELD_3_XFELD as _BANK2XFELD
on $projection. loevm = _BANK2XFELD. domvalue_1
association [<NUM>. *] to ESH_N_XFELD_XFELD as _POST_BANK_ACCT
on $projection. xpgro = _POST_BANK_ACCT. domvalue_1
association [<NUM>. <NUM>] to I_BankAdditionalFields as _BankAdditionFields
on $projection. banks = _BankAdditionFields. BankCountry and
$projection. bankl = _BankAdditionFields. BankInternalID
{
key banks,
key bankl,
erdat,
concat(firsternam, lasternam) as ernam,
banka,
provz,
concat(street, housenr) as stras,
concat(cityprt1, cityprt2) as ort01,
swift,
bgrup,
xpgro,
loevm,
bnklz,
pskto,
adrnr,
brnch,
chkme,
concat(versprt1, versprt2) as vers,
BANK2LAND1,
BANK2REGION,
BANK2USER,
BANK2XFELD,
POST BANK ACCT,
BankAdditionFields
}.

The following search definition is the example search definition (CDS-based search view) from above with the inapplicable elements removed (the unflagged elements):
@AbapCatalog. sqlViewName: 'ESH_L_BANK_BANK'
define view ESH_N_BANK_BANK_reduced
as select from bnka
association [<NUM>. *] to ESH_N_LAND1_3_LAND1 as _BANK2LAND1
on $projection. banks = _BANK2LAND1. DOMVALUE_L
association [<NUM>. *] to t005u as _BANK2REGION
on $projection. banks = _BANK2REGION. land1 and
$projection. provz = _BANK2REGION. bland
association [<NUM>. <NUM>] to ESH_N_USER_USER as _BANK2USER
on $projection. ernam = _BANK2USER. bname
association [<NUM>. *] to ESH _N_XFELD_3_XFELD as _BANK2XFELD
on $projection. loevm = _BANK2XFELD. domvalue_1
association [<NUM>. *] to ESH_N_XFELD_XFELD as _POST_BANK_ACCT
on $projection. xpgro = _POST_BANK_ACCT. domvalue_1
association [<NUM>. <NUM>] to I_BankAdditionalFields as _BankAdditionFields
on $projection. banks = _BankAdditionFields. BankCountry and
$projection. bankl = _BankAdditionFields. BankInternalID
{
key banks,
key bankl,
banka,
provz,
concat(street, housenr) as stras,
concat(cityprt1, cityprt2) as ort01,
swift,
bgrup,
bnklz,
pskto,
brnch,
_BANK2LAND1,
_BANK2REGION,
_BANK2USER,
_BANK2XFELD,
_POST_BANK_ACCT,
_BankAdditionFields
}.

The following search definition is the search definition (CDS-based Search View) from above, with the cruxes highlighted (underlined):
@AbapCatalog. sqlViewName: 'ESH_L_BANK_BANK'
define view ESH_N_BANK_BANK_reduced
as select from bnka
association [<NUM>. *] to ESH_N_LAND1_3_LAND1 as _BANK2LAND1
on $projection. banks = _BANK2LAND1. DOMVALUE_L
association [<NUM>. *] to t005u as _BANK2REGION
on $projection. banks = _BANK2REGION. land1 and
$projection. provz = _BANK2REGION. bland
association [<NUM>. <NUM>] to ESH_N_USER_USER as _BANK2USER
on $projection. ernam = _BANK2USER. bname
association [<NUM>. *] to ESH_N_XFELD_3_XFELD as _BANK2XFELD
on $projection. loevm = _BANK2XFELD. domvalue_1
association [<NUM>. *] to ESH_N_XFELD_XFELD as _POST_BANK_ACCT
on $projection. xpgro = _POST_BANK _ACCT. domvalue_1
association [<NUM>. <NUM>] to I_BankAdditionalFields as _BankAdditionFields
on $projection. banks = _BankAdditionFields. BankCountry and
$projection. bankl = _BankAdditionFields. BankInternalID
{
key banks,
key bankl,
banka,
provz,
concat(street, housenr) as stras,
concat(cityprt1, cityprt2) as ort01,
swift,
bgrup,
bnklz,
pskto,
brnch,
_BANK2LAND1,
_BANK2REGION,
_BANK2USER,
_BANK2XFELD,
_POST_BANK_ACCT,
_BankAdditionFields
}.

<FIG> is a schematic diagram depicting an application environment for a crux detection module <NUM>, which may provide implementation crux detection functionality, as described herein. An application <NUM>, such as a software application running in a computing environment, may have one or more plug-ins <NUM> (or add-ins or other software extensions to programs) that add functionality to, or otherwise enhance, the application. The crux detection module <NUM> may be integrated with the application <NUM>; for example, the crux detection module may be integrated as a plug-in. The crux detection module <NUM> may add functionality to the application <NUM> for implementation crux detection functionality, which may be displayed in a user interface or otherwise provided to a user. For example, the application <NUM> may be a database, a database management application, or an integrated development environment, and the crux detection module <NUM> may be integrated with the database, data management application, or integrated development environment to provide implementation crux detection functionality.

<FIG> is a schematic diagram depicting a system environment for a crux detection module <NUM>, which may provide implementation crux detection functionality, as described herein. The crux detection module <NUM> may be integrated with a computer system <NUM>. The computer system <NUM> may include an operating system, or otherwise be a software platform, and the crux detection module <NUM> may be an application or service running in the operating system or platform, or the crux detection module may be integrated within the operating system or platform as a service or functionality provided through the operating system or platform. The system <NUM> may be a server or other networked computer or file system. Additionally or alternatively, the crux detection module <NUM> may communicate with and provide implementation crux detection functionality, as described herein, to one or more applications <NUM>, such as a database, database management applications, or integrated development environment, in the system <NUM>.

<FIG> is a schematic diagram depicting a network environment <NUM> for a crux detection module <NUM>, which may provide implementation crux detection functionality, as described herein. The crux detection module <NUM> may be available on a network <NUM>, or integrated with a system (such as from <FIG>) on a network. Such a network <NUM> may be a cloud network or a local network. The crux detection module <NUM> may be available as a service to other systems on the network <NUM> or that have access to the network (e.g., may be on-demand software or SaaS). For example, system <NUM><NUM> may be part of, or have access to, the network <NUM>, and so can utilize implementation crux detection functionality from the crux detection module <NUM>. Additionally, system <NUM><NUM>, which may be part of or have access to the network <NUM>, may have one or more applications, such as application <NUM>, that may utilize implementation crux detection functionality from the crux detection module <NUM>.

In these ways, the crux detection module <NUM>, <NUM>, <NUM> may be integrated into an application, a system, or a network, to provide implementation crux detection functionality, or other code or definition analysis functionality, as described herein.

<FIG> depicts a generalized example of a suitable computing system <NUM> in which the described innovations may be implemented. The computing system <NUM> is not intended to suggest any limitation as to scope of use or functionality of the present disclosure, as the innovations may be implemented in diverse general-purpose or special-purpose computing systems.

With reference to <FIG>, the computing system <NUM> includes one or more processing units <NUM>, <NUM> and memory <NUM>, <NUM>. In <FIG>, this basic configuration <NUM> is included within a dashed line. The processing units <NUM>, <NUM> execute computer-executable instructions, such as for implementing components of the processes of <FIG>, the systems of <FIG> and <FIG>, or the data, data representations, or data structures of <FIG>, and the examples of <FIG>. A processing unit can be a general-purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example, <FIG> shows a central processing unit <NUM> as well as a graphics processing unit or co-processing unit <NUM>. The tangible memory <NUM>, <NUM> may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit(s) <NUM>, <NUM>. The memory <NUM>, <NUM> stores software <NUM> implementing one or more innovations described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s) <NUM>, <NUM>. The memory <NUM>, <NUM>, may also store settings or settings characteristics, databases, data sets, search definitions or representations, or examples shown in <FIG> and <FIG>, the systems shown in <FIG> and <FIG>, or the steps of the processes shown in <FIG>.

A computing system <NUM> may have additional features. For example, the computing system <NUM> includes storage <NUM>, one or more input devices <NUM>, one or more output devices <NUM>, and one or more communication connections <NUM>. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system <NUM>. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system <NUM>, and coordinates activities of the components of the computing system <NUM>.

The tangible storage <NUM> may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing system <NUM>. The storage <NUM> stores instructions for the software <NUM> implementing one or more innovations described herein.

The input device(s) <NUM> may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system <NUM>. The output device(s) <NUM> may be a display, printer, speaker, CD-writer, or another device that provides output from the computing system <NUM>.

The communication connection(s) <NUM> enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use an electrical, optical, RF, or other carrier.

The innovations can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing system on a target real or virtual processor. Generally, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing system.

The terms "system" and "device" are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation on a type of computing system or computing device. In general, a computing system or computing device can be local or distributed, and can include any combination of special-purpose hardware and/or general-purpose hardware with software implementing the functionality described herein.

In various examples described herein, a module (e.g., component or engine) can be "coded" to perform certain operations or provide certain functionality, indicating that computer-executable instructions for the module can be executed to perform such operations, cause such operations to be performed, or to otherwise provide such functionality. Although functionality described with respect to a software component, module, or engine can be carried out as a discrete software unit (e.g., program, function, class method), it need not be implemented as a discrete unit. That is, the functionality can be incorporated into a larger or more general purpose program, such as one or more lines of code in a larger or general purpose program.

For the sake of presentation, the detailed description uses terms like "determine" and "use" to describe computer operations in a computing system. These terms are high-level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being. The actual computer operations corresponding to these terms vary depending on implementation.

<FIG> depicts an example cloud computing environment <NUM> in which the described technologies can be implemented. The cloud computing environment <NUM> comprises cloud computing services <NUM>. The cloud computing services <NUM> can comprise various types of cloud computing resources, such as computer servers, data storage repositories, networking resources, etc. The cloud computing services <NUM> can be centrally located (e.g., provided by a data center of a business or organization) or distributed (e.g., provided by various computing resources located at different locations, such as different data centers and/or located in different cities or countries).

The cloud computing services <NUM> are utilized by various types of computing devices (e.g., client computing devices), such as computing devices <NUM>, <NUM>, and <NUM>. For example, the computing devices (e.g., <NUM>, <NUM>, and <NUM>) can be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smart phones), or other types of computing devices. For example, the computing devices (e.g., <NUM>, <NUM>, and <NUM>) can utilize the cloud computing services <NUM> to perform computing operations (e.g., data processing, data storage, and the like).

Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth.

Any of the disclosed methods are implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media, such as tangible, non-transitory computer-readable storage media, and executed on a computing device (e.g., any available computing device, including smart phones or other mobile devices that include computing hardware). Tangible computer-readable storage media are any available tangible media that can be accessed within a computing environment (e.g., one or more optical media discs such as DVD or CD, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as flash memory or hard drives)). By way of example, and with reference to <FIG>, computer-readable storage media include memory <NUM> and <NUM>, and storage <NUM>. The term computer-readable storage media does not include signals and carrier waves. In addition, the term computer-readable storage media does not include communication connections (e.g., <NUM>).

Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable storage media. The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.

For clarity, only certain selected aspects of the software-based implementations are described. It should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Python, Ruby, ABAP, SQL, Adobe Flash, or any other suitable programming language, or, in some examples, markup languages such as html or XML, or combinations of suitable programming languages and markup languages. Likewise, the disclosed technology is not limited to any particular computer or type of hardware.

Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and sub combinations with one another. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.

Claim 1:
A computer-implemented method (<NUM>) comprising:
- generating (<NUM>) a dependency graph (<NUM>) for a search definition set (<NUM>), wherein:
the search definition set is a collection of search definitions, the search definitions including interpretable text, code, or pseudo-code detailing a search for data against a data source and one or more dependencies with other search definitions in the search definition set,
the dependency graph (<NUM>) comprises nodes (213a-213n) representing the search definitions (203a-203n) of the search definition set (<NUM>), and
the dependency graph (<NUM>) indicates dependency between search definitions (203a-203n) in the search definition set (<NUM>);
- reducing (<NUM>) the dependency graph (<NUM>) for a given search definition, wherein the reducing removes search definitions on which the given search definition does not depend, wherein the given search definition is a root of a tree within the dependency graph (<NUM>);
- removing (<NUM>) elements in the given search definition of the reduced dependency graph (<NUM>) based on context criteria;
- removing (<NUM>) elements in the remaining search definitions of the reduced dependency graph (<NUM>) based on search definition criteria;
- identifying (<NUM>) one or more implementation crux elements in the search definitions of the reduced dependency graph by comparing elements of the search definitions against crux criteria and/or by analyzing elements of the search definitions against their location within the dependency graph (<NUM>), wherein the one or more implementation crux elements are performance-impacting elements including SQL expressions; and
- providing the identified one or more implementation crux elements to a code analyzer or optimizer that changes the one or more implementation crux elements to an improved operation or set of operations that are less resource-intensive.