Enterprise software systems receive, generate, and store data related to many aspects of an enterprise. Users operate reporting tools to view and analyze such data. For example, a reporting tool may be used to submit a query to a system storing enterprise data. The system, which may be on-premise, cloud-based, or otherwise deployed, generates a result set based on the query and on the stored data, and returns the result set to the reporting tool for display and/or analysis.
In order to shield a user from the complexities of an underlying data storage schema, conventional systems associate intuitively-named logical objects with one or more physical entities (e.g., a physical database table, associated columns of one or more database tables) of the underlying data source. These objects may be classified as dimensions, along which one may want to perform an analysis or report (e.g., Year, Country, Product), or measures (e.g., Sales, Profit), whose values can be determined for a given combination of dimension members. For example, a user may operate a reporting tool to submit the query “Sales by Country”.
A user is therefore required to possess some familiarity with the defined logical objects and with a corresponding query syntax. As the complexity of the desired result set increases, the formulation of an appropriate query may quickly overwhelm the user. Time and resources are inefficiently expended while attempting to formulate an appropriate query, and while attempting to understand the semantic meaning of a thus-formulated query. Enhancements are desired to support the formulation and understanding of user-generated queries.
The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily-apparent to those in the art.
Generally, some embodiments identify tokens within a user query and provide a visual indication of a type of query entity associated with the identified token. Such embodiments may thereby allow a user to efficiently and seamlessly determine whether an input token is recognized as suitable for use in a query, and to determine whether the token has been recognized as a desired query entity type. Embodiments may include other features to further facilitate formulation of queries and understanding of formulated query semantics.
Interface 100 includes input field 110. A user may input tokens into field 110 using a keyboard or other input device. The tokens are intended to represent a query for retrieving desired data from a data source. In the present example, the user has input the tokens “sales”, “from” and “2014”.
Each token of field 110 is associated with a respective one of graphical indicators 112, 114 and 116. Each of graphical indicators 112, 114 and 116 provides a visual indication of a query entity type of its associated token. Each of graphical indicators 112, 114 and 116 is associated with a different level of shading. Therefore, in the illustrated embodiment, each token is associated with a different query entity type.
Embodiments may utilize any query entity types that are or become known. Entity types may comprise, for example, database schema attributes such as dimensions and measures, query keywords such as “by”, “for”, “with”, and named entities such as dates, numbers and currencies. In the present example, the token “sales” is of a Measure entity type, the token “from” is of a Keyword entity type, and the token “2014” is of a Date entity type.
Embodiments therefore comprise systems to identify an entity type associated with an input token. The systems may include various mapping components (e.g., keyword mapper, database entity mapper). Prior to mapping, syntactical analysis may be applied to identify parts of speech within input text. Identification of an entity type may include fuzzy matching. More than one entity type may be determined to match a particular token, with each matched entity being associated with a confidence value. In some embodiments, the entity type having the highest confidence value is graphically indicated as described herein. Entity matching may also incorporate a user profile (e.g., location) and user history (e.g., a user or group's most-used entities).
Embodiments may utilize any one or more graphical indications to indicate the entity type of a given token. According to some embodiments, each query entity type is associated with a color and the text of each token is colored based on the token's query entity type. Graphical indicators 112, 114 and 116 may also be presented in the appropriate colors. A graphical indication may be presented temporarily in order to provide visual feedback, and then be removed from interface 100. A graphical indication may include text, animation, font manipulation or any other means for conveying a query entity type of an input token.
It will now be assumed that the user presses Backspace, in which case the previously-typed letters “pro” are redisplayed as shown in
As shown in
As mentioned above, an input token may be determined to match more than one query entity.
In response to the pause, menu 430 is displayed in association with the token “category”. Menu 430 indicates two entities which have been determined to match the token with a high confidence level, and indicates a default query entity (i.e., Product Category) which will be selected upon pressing Tab or Enter. Indicator 435 also indicates that the token has matched more than one entity.
A user has input the token “furniture” into input filed 810. The token has been matched to a query entity and graphical indicator 812 indicates a type of the matched query entity. In response to the input token, the system determines and displays query suggestions 814 and 816. The query suggestions may be determined in real-time based on the tokens entered by the user.
In some embodiments, query suggestions are displayed only if the user pauses for greater than a predetermined interval while typing. This reduces the potential intrusiveness of displayed suggestions during input of a valid query. According to some embodiments, the user may request query suggestions by depressing the down arrow during typing. The query suggestions may be filtered by prefix matching, and sorted by match score, length, and alphabetically.
Query suggestions may be determined using a query suggestion model. Such a query suggestion model may be trained using full queries that were successfully executed. The full queries used for training the model include the input tokens and their determined query entity types (e.g., Measure, Dimension, Keyword). The training queries may be those input by a single user across multiple sessions or by multiple users across multiple sessions.
A compact tree data structure may be constructed to compresses the entire training data into the form of a tree. Each branch of the tree forms a sequence of words that translate into a query. An abstract version of the tree can be created using placeholder tokens (e.g., <measure>, <dimension>) instead of the actual attributes of the queries. This abstract version may be created from queries input by multiple users across multiple sessions. This tree may be used to predict abstract versions of the queries, where the placeholder tokens of the abstract versions are filled with most-used data attribute values for the current user.
Area 820 of interface 800 displays most-used data schema attributes for selection by the user. Selection of a displayed schema attribute may cause the selected attribute to be added to the tokens of input field 810. Determination of the most-used data schema attributes to display may be based on tracking of attribute usage within queries over multiple sessions and multiple users for the same data source.
The executed query is displayed within context box 840. Context box 840 allows the user to identify the currently-executed query. Moreover, the entities of context box 840 may be added to, removed or manipulated to support further exploration of the data source as will be described below.
Architecture 1200 includes data server 1210 and client 1220. Generally, data server 1210 receives requests from client 1220 and provides results to client 1220 based on those requests. Server application 1212 may be separated from or closely integrated with data store 1214. Server application 1212 may be executed completely on the database platform of data store 1214, without the need for an additional server. Architecture 1200 may be implemented using any client-server architecture that is or becomes known, including but not limited to on-premise, cloud-based and hybrid architectures.
In one specific example, client 1220 executes an application to present a user interface to a user. The user enters a query into the user interface, and client 1220 forwards a request based on the query to server 1210. Server application 1212 may further provide processing of input tokens as described above, to facilitate user formulation of the query.
Server application 1212 generates an SQL script based on the request and forwards the SQL script to data store 1214. Data store 1214 executes the SQL script to return a result set based on data of data store 1214, and client 1220 generates and displays a report/visualization based on the result set.
Data store 1214 stores metadata defining attributes such as dimensions and measures, keywords, dimension members, and measure values. All of the data of data store 1210 may be used as described above to identify matching query entities and query entity types.
The data of data store 1214 may comprise one or more of conventional tabular data, row-based data, column-based data, and object-based data. Moreover, the data may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof. Data store 1214 may support multi-tenancy to separately support multiple unrelated clients by providing multiple logical database systems which are programmatically isolated from one another.
Data store 1214 may comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Data store 1214 may comprise a relational database, a multi-dimensional database, an eXtendable Markup Language (XML) document, or any other data storage system storing structured and/or unstructured data. The data of data store 1214 may be distributed among several relational databases, dimensional databases, and/or other data sources. Embodiments are not limited to any number or types of data sources.
Data store 1214 may implement an “in-memory” database, in which a full database stored in volatile (e.g., non-disk-based) memory (e.g., Random Access Memory). The full database may be persisted in and/or backed up to fixed disks (not shown). Embodiments are not limited to an in-memory implementation. For example, data may be stored in Random Access Memory (e.g., cache memory for storing recently-used data) and one or more fixed disks (e.g., persistent memory for storing their respective portions of the full database).
Client 1220 may comprise one or more devices executing program code of an application for presenting user interfaces to allow interaction with server 1210. The user interfaces may be suited for reporting, data analysis, and/or any other functions based on the data of data store 1214.
For example, server application 1311 may provide a user interface such as interface 100 to client 1320. Client 1320 receives tokens input by a user and server application 1311 submits a request to identifier 1312 to identify the input tokens. As described above, identifier 1312 may identify several entities for a given token, each associated with a respective confidence level. Identifier 1312 may therefore return one or more matching entities and respective confidence levels to server application 1311.
Entity identifier 1312 according to the illustrated embodiments includes a parser to identify parts of speech within the input tokens. The example uses a lexical database for such parsing but embodiments are not limited thereto. The parser may also remove stop words from the tokens prior to passing the tokens to a token mapper. Generally, the token mapper, which may include sub-mapping components, maps entities to keywords of a keyword store, named entities from a knowledge base, and schema attributes specified in data schema 1313. Token mapping, and determination of confidence levels, may further be based on usage logs and user history and preferences as described above.
Server application 1311 may format the input tokens of the graphical interface using graphical indicators, inline suggestions, or the like as described above based on the identified matching entities. Once a query is formulated, the client 1320 submits the query to server application 1311, which in turn forwards the query to query server 1314. Based on the data schema 1313, query server 1314 queries data store 1315 and receives a result set. The result set is returned to the client 1320, in raw form, as a visualization, or otherwise.
Each element of systems 1200 and 1300 may be may be implemented at least in part in computer hardware, in program code and/or in one or more computing systems executing such program code as is known in the art. Such a computing system may include one or more processing units which execute processor-executable program code stored in a memory system.
Apparatus 1400 includes processor(s) 1410 operatively coupled to communication device 1420, data storage device 1430, one or more input devices 1440, one or more output devices 1450 and memory 1460. Communication device 1420 may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s) 1440 may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s) 1440 may be used, for example, to enter information into apparatus 1400. Output device(s) 1450 may comprise, for example, a display (e.g., a display screen), a speaker, and/or a printer.
Data storage device 1430 may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory 1460 may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory.
Server applications 1432 and services 1434 may comprise program code executed by processor 1410 to cause apparatus 1400 to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus.
Metadata 1436 and data 14314 (either cached or a full database) may be stored in volatile memory such as memory 1460. Metadata 1436 may include information regarding keywords, dimensions, dimension values, measures associated with the data sources of data 1438. Data storage device 1430 may also store data and other program code for providing additional functionality and/or which are necessary for operation of apparatus 1400, such as device drivers, operating system files, etc.
The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of a system according to some embodiments may include a processor to execute program code such that the computing device operates as described herein.
All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a hard disk, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software.
Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.
Number | Name | Date | Kind |
---|---|---|---|
6081774 | de Hita | Jun 2000 | A |
6959425 | Krauklis | Oct 2005 | B1 |
6999963 | McConnell | Feb 2006 | B1 |
7685116 | Pell | Mar 2010 | B2 |
8577913 | Hansson | Nov 2013 | B1 |
9116918 | Kim | Aug 2015 | B1 |
9529936 | Pankaj | Dec 2016 | B1 |
10198511 | Gupta | Feb 2019 | B1 |
10515625 | Metallinou | Dec 2019 | B1 |
10686736 | Jiang | Jun 2020 | B1 |
10846318 | McNabney | Nov 2020 | B1 |
10955255 | Yang | Mar 2021 | B2 |
11016964 | Hinegardner | May 2021 | B1 |
20030233224 | Marchisio | Dec 2003 | A1 |
20040119732 | Grossman | Jun 2004 | A1 |
20040210844 | Pettinati | Oct 2004 | A1 |
20050108024 | Fawcett | May 2005 | A1 |
20060247915 | Bradford | Nov 2006 | A1 |
20060294192 | Mao | Dec 2006 | A1 |
20070061703 | Kambhatla | Mar 2007 | A1 |
20080059898 | Deggelmann | Mar 2008 | A1 |
20090019356 | Deyab | Jan 2009 | A1 |
20090249198 | Davis | Oct 2009 | A1 |
20100094854 | Rouhani-Kalleh | Apr 2010 | A1 |
20100131869 | Adachi | May 2010 | A1 |
20100205121 | Quadracci | Aug 2010 | A1 |
20100205198 | Mishne | Aug 2010 | A1 |
20110270888 | Crochet | Nov 2011 | A1 |
20110307504 | Agrawal | Dec 2011 | A1 |
20120036145 | Tunstall-Pedoe | Feb 2012 | A1 |
20120259829 | Zhou | Oct 2012 | A1 |
20120303664 | Apacible | Nov 2012 | A1 |
20130173639 | Chandra | Jul 2013 | A1 |
20130218861 | Hong | Aug 2013 | A1 |
20130226892 | Ehsani | Aug 2013 | A1 |
20140040274 | Aravamudan | Feb 2014 | A1 |
20140172840 | Kumar | Jun 2014 | A1 |
20140244637 | O'Donnell | Aug 2014 | A1 |
20140279078 | Nukala | Sep 2014 | A1 |
20140279994 | Gulli | Sep 2014 | A1 |
20140282136 | Marantz | Sep 2014 | A1 |
20150026145 | Prakash | Jan 2015 | A1 |
20150039580 | Subhedar | Feb 2015 | A1 |
20150052115 | Sharifi | Feb 2015 | A1 |
20150074747 | Philip | Mar 2015 | A1 |
20150156061 | Saxena | Jun 2015 | A1 |
20150205858 | Xie | Jul 2015 | A1 |
20150212714 | Hua | Jul 2015 | A1 |
20150269153 | Fink | Sep 2015 | A1 |
20150269175 | Espenshade | Sep 2015 | A1 |
20150269176 | Marantz | Sep 2015 | A1 |
20150310491 | Kraft | Oct 2015 | A1 |
20150317354 | Andress | Nov 2015 | A1 |
20150324425 | Behzadi | Nov 2015 | A1 |
20150347433 | Bhagwan | Dec 2015 | A1 |
20160077708 | Han | Mar 2016 | A1 |
20160092506 | Liu | Mar 2016 | A1 |
20160094889 | Venkataraman | Mar 2016 | A1 |
20160179953 | Klotz, Jr | Jun 2016 | A1 |
20160196360 | Best | Jul 2016 | A1 |
20160224621 | Bousquet | Aug 2016 | A1 |
20160275148 | Jiang | Sep 2016 | A1 |
20160335787 | Martin | Nov 2016 | A1 |
20170011068 | Vashishtha | Jan 2017 | A1 |
20170017696 | Alonso | Jan 2017 | A1 |
20170039209 | Gupta | Feb 2017 | A1 |
20170097936 | Glover | Apr 2017 | A1 |
20170161262 | Bhatt | Jun 2017 | A1 |
20170168695 | Francis | Jun 2017 | A1 |
20170199943 | Steelberg | Jul 2017 | A1 |
20170206683 | Beckett | Jul 2017 | A1 |
20170220687 | Hawking | Aug 2017 | A1 |
20170242913 | Tijssen | Aug 2017 | A1 |
20170278514 | Mathias | Sep 2017 | A1 |
20170337202 | Arya | Nov 2017 | A1 |
20170364503 | Anisimovich | Dec 2017 | A1 |
20170372190 | Bishop | Dec 2017 | A1 |
20180018315 | Takei | Jan 2018 | A1 |
20180032503 | Swart | Feb 2018 | A1 |
20180039406 | Kong | Feb 2018 | A1 |
20180121480 | Jaikumar | May 2018 | A1 |
20180137124 | Konigsberg | May 2018 | A1 |
20180336272 | Garcia Santa | Nov 2018 | A1 |
20190005044 | Bell | Jan 2019 | A1 |
20190012060 | Moore | Jan 2019 | A1 |
20190018849 | Dong | Jan 2019 | A1 |
20190018884 | Wakankar | Jan 2019 | A1 |
20190034407 | Hagiwara | Jan 2019 | A1 |
20190129688 | Yao | May 2019 | A1 |
20190258963 | Guo | Aug 2019 | A1 |
20190272296 | Prakash | Sep 2019 | A1 |
20190340281 | Maiti | Nov 2019 | A1 |
20190377789 | Jegannathan | Dec 2019 | A1 |
20200090033 | Ramachandran | Mar 2020 | A1 |
20200234008 | Song | Jul 2020 | A1 |
Entry |
---|
Meschkat, Steffen, “Disambiguation of entity references in natural language interpretation”, Technical Disclosure Commons, Mar. 26, 2018, 7 pages. (Year: 2018). |
Number | Date | Country | |
---|---|---|---|
20200167432 A1 | May 2020 | US |