Patent Application
20170357693
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Embodiments relate to storage and management of data, and in particular to methods and apparatuses implementing overlay visualizations utilizing a data layer. Specific embodiments allow different information types to be displayed along a same axis of a chart.
Databases and overlying applications referencing data stored therein, offer a powerful way of storing and analyzing large volumes of data that are related in various ways. In particular, discrete values of stored data may be organized into larger data structures comprising related fields.
Such larger data structures may also be referred to as data objects, and can be represented in the form of tables having rows and columns. Through the skillful and intuitive presentation of such data structures in the form of tables and charts, a user can describe complex issues and the factual/forecast data underlying those issues.
In analytics applications, data fields are generally divided into two categories: measures and dimensions. Measures are typically continuous numerical values, while dimensions are mostly categorical and discrete.
To create charts, a user can assign one or more fields to each of the axes. For example in a column chart a user can assign a dimension to the horizontal axis, and assign a measure to the vertical axis representing values of the measure for each distinct value of the dimension.
On occasion, it may be desired to plot one measure based upon two dimensions from the same value set. One example could be to plot a number of tasks for a first dimension representing task start date, and a second dimension representing task end date.
The underlying data that is to be visualized, may be present within a data layer in Structured Query Language (SQL) tabular format. However such a data layer allowing data visualizations by mapping dimensions and measures to chart axes, may not permit a same shared axis to be used for more than one set of values.
In an attempt to overcome this problem, conventional approaches may rely upon a visualization layer to separately generate charts, and then modify those charts to superimpose them. Such an approach may add complexity and expense by consuming significant processing resources in the visualization layer. This problem may be exacerbated where data in the data layer is being updated, and the visualization layer is forced to generate new visualizations and freshly superimpose them each time.
Embodiments implement overlay visualizations utilizing data of a data layer. A database table comprises a measure and two or more different dimensions mapping to a same value range. To promote visualization, the measure for those dimensions may be plotted along a common axis in a same chart. Accordingly, a query executes an operation (e.g., UNION, FULL OUTER JOIN) combining multiple subqueries. A first subquery aggregates the first dimension over the value range, injecting a constant formula field to identify the original first dimension. A second subquery aggregates the second dimension over the value range, again injecting the constant formula field to identify the original second dimension. The combination (e.g., UNION, FULL OUTER JOIN) of these subquery results presents one larger unified dataset for input to the overlying visualization layer. The constant formula field may be referenced to differentiate between the combined dimensions on the common axis, thereby allowing the measure values to be associated with the original dimensions in the displayed plot (e.g., via coloring, point shape, etc.)
An embodiment of a computer-implemented method comprises, referencing a dataset comprising a measure, a first dimension, and a second dimension, in order to display an option to combine the first dimension and the second dimension. In response to an input selecting the option, a query is formulated comprising an operation combining a first subquery aggregating the first dimension into a combined dimension and including a field indicating the first dimension, and a second subquery aggregating the second dimension into the combined dimension and including the field indicating the second dimension. The query is communicated to a data layer. A query result is received comprising the measure, the combined dimension, and the field. The query result is referenced to display a chart comprising the measure and the combined dimension on a common axis with an affordance of the first dimension and the second dimension based upon the field.
A non-transitory computer readable storage medium embodies a computer program for performing a method comprising referencing a dataset comprising a measure, a first dimension, and a second dimension, in order to display an option to combine the first dimension and the second dimension. In response to an input selecting the option, formulating a query comprising an operation combining a first subquery aggregating the first dimension into a combined dimension and including a field indicating the first dimension, and a second subquery aggregating the second dimension into the combined dimension and including the field indicating the second dimension. The query is formatted as a JavaScript Object Notation (JSON) query object. The JSON query object is communicated to a data layer. A JSON result object is received comprising the measure, the combined dimension, and the field. The JSON result object is parsed to display a chart comprising the measure and the combined dimension on a common axis with an affordance of the first dimension and the second dimension based upon the field.
An embodiment of a computer system comprises one or more processors and a software program, executable on said computer system. The software program is configured to cause an in-memory database engine to reference a dataset in an in-memory database and comprising a measure, a first dimension, and a second dimension, in order to display an option to combine the first dimension and the second dimension. In response to an input selecting the option, the software program is further configured to cause the in-memory database engine to formulate a query comprising an operation combining a first subquery aggregating the first dimension into a combined dimension and including a field indicating the first dimension, and a second subquery aggregating the second dimension into the combined dimension and including the field indicating the second dimension. The query is communicated to the in-memory database. A query result is received comprising the measure, the combined dimension, and the field. The query result is referenced to display a chart comprising the measure and the combined dimension on a common axis with an affordance of the first dimension and the second dimension based upon the field.
In certain embodiments the operation comprises a UNION operation.
According to some embodiments the operation comprises a FULL OUTER JOIN operation.
In particular embodiments the dataset further comprises a third dimension. The operation further combines a third subquery aggregating the third dimension into the combined dimension and including the field indicating the third dimension, and the chart is generated with the affordance of the third dimension based upon the field.
In various embodiments the first subquery aggregates the first dimension as a sum.
In particular embodiments the first subquery aggregates the first dimension as an average.
According to certain embodiments the affordance comprises a color, a point symbol, or a line type.
Some embodiments further comprise formatting the query as a JavaScript Object Notation (JSON) query object.
According to various embodiments the query result is received as a JSON result object, and the method further comprises parsing the JSON result object to display the chart.
The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of embodiments.
Described herein are methods and apparatuses that implement overlay visualizations in a data layer. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that embodiments of the present invention as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
Embodiments implement overlay visualizations utilizing data of a data layer. A database table comprises a measure and two or more different dimensions mapping to a same value range. To promote visualization, the measure for those dimensions may be plotted along a common axis in a same chart. Accordingly, a query executes an operation (e.g., UNION, FULL OUTER JOIN) combining multiple subqueries. A first subquery aggregates the first dimension over the value range, injecting a constant formula field to identify the original first dimension. A second subquery aggregates the second dimension over the value range, again injecting the constant formula field to identify the original second dimension. The combination of these subquery results presents one larger unified dataset for input to the overlying visualization layer. The constant formula field may be relied upon to differentiate between the combined dimensions on the common axis, thereby allowing the measure values to be associated with the original dimensions in the displayed plot (e.g., via an affordance such as coloring, a plot point shape, etc.).
Embodiments thus offer a mechanism for overlaying data from different dimensions along a common axis in a single chart, based upon data received from a data layer. Embodiments are scalable and can accommodate multiple measures and dimensions.
For example, where N columns of data in the data layer are to be combined on a common axis, N subqueries are executed. Each subquery has a measure accumulated along 1/N columns, together with a constant field utilized to trace the measure value back to the 1/Nth column. The UNION or FULL OUTER JOIN of the two query results produces one larger, unified dataset.
In particular, database table 112 comprises a ‘table_name’ dataset including a measure M and two dimensions D1 and D2. Measure M evidences different trends for each of the dimension D1 and the dimension D2. Those trends are sought to be displayed together in a same chart for viewing and analysis.
Accordingly, the visualization application provides an interface 114 which includes controls 116. Those controls allow user selection of M, D1, D2, and also for a combined dimension 118.
The controls of the user interface are in communication with a visualization engine 120. Upon receiving a selection of measure(s) and dimension(s) by a user, the visualization engine is configured to generate a query 122 for posing to the data in the underlying database.
In particular, in response where the visualization engine receives an input 123 from the interface (e.g., based upon a cursor 125) specifying the combined dimension option, the visualization engine generates a query including the following two subqueries (Q1, Q2) that can yield values for the two data trends evidenced by the dimensions D1 and D2:
Q1->SELECT AGG(M), D1, “D1” FROM ‘table_name’ GROUP BY D1
Q2->SELECT AGG(M), D2, “D2” FROM ‘table_name’ GROUP BY D2
Here, AGG is the aggregation method for measure. This aggregation method can comprise sum, average, etc.
The data trends for D1 and D2 reflected in these queries, can be combined using the following query:
The visualization engine injects into the query a constant formula field which may have a value of “D1” or “D2”. Having “D1” and “D2” as two SQL formulas returning a constant value, permits differentiating between rows of each sub query.
This extra column can later be used to distinguish the two trends for D1 and D2, e.g. via an affordance. Examples of such affordances can include but are not limited to color, plot point shape, line character (e.g., solid, dashed, dotted), etc. For example, the visualization engine can reference the constant formula field to recognize D1 in the query result and provide a dashed line for the dimension D1 data, and recognize D2 in the query result and provide a dotted line for the dimension D2 data.
To facilitate transfer of the query to the data layer, the visualization application formulates the query Q as a JavaScript Object Notation (JSON) object 122, and promulgates that JSON query object to the engine 124 of the underlying database layer.
The database engine receives this JSON query object and parses it. The database engine coverts the query object into a query 126 expressed in a language (e.g., Structured Query Language—SQL) that is understood by the database.
The database then interrogates the table and returns a responsive query result 128 to the database engine. This resultset comprises a dataset with a common column for a single combined dimension, and one column for the measure. Each row of this combined dataset results from either the Q1 or the Q2.
The database engine then converts the SQL query result into a JSON query result object 129, for transport back to the application layer.
The visualization engine receives the JSON result set, and stores it within memory 130 in the database layer. The visualization engine then parses the resultset to split the measure value according to the value of the constant formula field.
Based upon this parsed query result, the visualization engine generates a plot 132 of the D1 and D2 data along a same axis. That combined plot is displayed by the visualization application interface for review by the user.
While the above describes an approach for overlaying data from two dimensions, this is not required. Embodiments may be scaled to have several dimensions and several measures.
For example, assume that dimensions D_1 to D_N are sought to be overlaid for each of measures M_1 to M_J. Accordingly, the original simple SQL query presented above, may be extended as follows:
Q->(SELECT D_1, M_1, M_2, . . . , M_J FROM ‘table_name’ GROUP BY D_1) UNION
(SELECT D_2, M_1, M_2, . . . , M_J FROM ‘table_name’ GROUP BY D_1) UNION
(SELECT D_3, M_1, M_2, . . . , M_J FROM ‘table_name’ GROUP BY D_1) UNION . . .
(SELECT D_N, M_1, M_2, . . . , M_J FROM ‘table_name’ GROUP BY D_N)
Moreover, embodiments may add the constant formula to each of the sub-queries. The resulting constant value may serve to distinguish between data of different original dimensions that are the result of different sub-queries.
It is further noted that embodiments may achieve a same result using a FULL OUTER JOIN operation rather than a UNION operation. An example of a query under such circumstances may be as follows:
Q->(SELECT D_1, M FROM ‘table_name’ GROUP BY D_1) a FULL OUTER JOIN
(SELECT D_2, M FROM ‘table_name’ GROUP BY D_2) b ON a.D_1=b.D_2 AND a.M=b.M
At 204, in response to an input selecting the option, a query is formulated that comprises an operation combining a first subquery aggregating the first dimension into a combined dimension and including a field indicating the first dimension, and a second subquery aggregating the second dimension into the combined dimension and including the field indicating the second dimension.
At 206 the query is communicated to a data layer. At 208 a query result is received comprising the measure, the aggregated dimension, and the field.
At 210, the query result is referenced to display a chart comprising the measure and the aggregated dimension on a common axis with an affordance of the first dimension and the second dimension based upon the field.
An example is now presented in connection with visualization of task start dates and task end dates. The following table presents this data for five (5) different tasks.
A user may seek to know how many tasks are outstanding on a given date. In order to determine this information, ordinarily a user would be forced to count the number of tasks started by that date, and subtract the number of tasks that had been completed by that date.
A first step toward this goal would be to add a running sum for the number of started and completed tasks. This would result in the following table.
This table, however, offers little intuitive insight to a user. For example, the respective counts for started and ended tasks do not line up in a given row.
The information in the above table becomes easier to understand, if it is split up into the following two tables.
It is straightforward to visualize these tables as separate charts. Specifically,
The user's end goal, however, is to determine how many outstanding tasks exist on any given date. The two charts of
One possible solution would be to overlay together the existing two chart visualizations of
A hybrid chart could theoretically be constructed on a visualization level with an X-axis date range encompassing
It is further noted that that a conventional approach based upon overlaying already-existing visualizations, requires for the steps of:
1) breaking the tables apart manually
2) separately creating the visualizations and
3) overlaying the separate visualizations.
This process can be time-consuming and labor-intensive. Moreover, if splitting the original data table is not an option, the conventional approach based upon the already-existing visualizations themselves, is not feasible.
Accordingly, embodiments address this data visualization issue within the query layer and the data layer, rather than in the overlying visualization layer. Specifically, the original table within the data layer, is again reproduced below.
Here, it is sought to combine two columns (Start Date, End Date) on a common axis. In an embodiment, two subqueries may be executed, where each subquery has a measure (Count) accumulated along 1/2 columns, along with a constant field which may be used to trace the measure value back to the 1/2 column.
Armed with these two subqueries, a UNION operation may be executed on them. This combines the two subquery results to produce one larger, unified dataset. An example of such a query using industry-standard Structured Query Language (SQL) is as follows:
SELECT START_DATE AS “COMBINED_DATE”, RUNNING_SUM(COUNT(TASK)), CONSTANT(“START_DATE”) FROM FACT_TABLE
SELECT END_DATE AS “COMBINED_DATE”, RUNNING_SUM(COUNT(TASK)), CONSTANT(“END_DATE”) FROM FACT_TABLE
For purposes of illustration, the results of the sub-queries are shown below.
Execution of the UNION operation on these subquery results, combines them to produce the single, larger unified dataset below.
Sorting this table by date, produces the following.
Aligning the data points from the above sorted table on the combined date axis, produces the chart shown in
User understanding of this resultset could be based upon prior knowledge of which columns were combined into the same axis. This would allow the identification of the measures from the results, based on the constant formula field in the resultset.
Here, the shape of the points (e.g., triangular, circular) plotted in
A more specific example is now provided in the context of the Lumira Desktop data visualization business intelligence tool available from SAP SE of Walldorf, Germany.
The Lumira desktop system 600 is a client-server business intelligence (BI) tool. Here, the client is a Javascript-based Frontend 602 including a query generator 604.
The backend 606 comprises a Java application server that includes a query engine 608, which is configured to construct a query 614 a database 610 (in this example a Sybase database). Details of a query example are shown in
Here, the user accesses the user interface (UI) 612 on the Frontend in order to construct a visualization. In this example the user can specify time dimensions to combine into a common axis on a line chart.
The Time Dimension shelf of the user interface is occupied by a “Combined” token, which includes both the Start Date (create date) and End Date (close date) dimensions. These subqueries are combined through an operation as has been described above.
Based on the dimensions and measures that are selected in the UI, a query is constructed using the Query Generator in the client. This query 614 is specified in Javascript Object Notation (JSON) format.
One benefit of using a JSON-based query language, is that the query is agnostic of the specific database implementation. Thus while
Here it is noted that the specific JSON query object example of
Returning to
The query is then executed on the database to produce a database-dependent resultset. The query engine on the Backend converts the database-dependent implementation of the resultset into a JSON result object 616. That JSON result object is in a format readily allowing it be transported back to the client for subsequent reparsing.
Specifically, when the JSON result object is returned to the client, the constant formula field may be referenced to differentiate between the combined dimensions on the common axis (here, representing time). This allows the measures to be split back into the dimensions that were earlier combined on the common axis. Those dimensions can then be displayed as differentiated data trends actually plotted on the chart.
The examples just provided are given for purposes of illustration only, and embodiments are not limited to them. Thus while
In certain embodiments the visualization engine may be implemented by a database engine, for example as present in an in-memory database. One example of such an in-memory database engine is that of the HANA in-memory database available from SAP SE of Walldorf, Germany.
For example,
It is noted that in the specific embodiment of
An example computer system 900 is illustrated in
Computer system 910 may be coupled via bus 905 to a display 912, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. An input device 911 such as a keyboard and/or mouse is coupled to bus 905 for communicating information and command selections from the user to processor 901. The combination of these components allows the user to communicate with the system. In some systems, bus 905 may be divided into multiple specialized buses.
Computer system 910 also includes a network interface 904 coupled with bus 905. Network interface 904 may provide two-way data communication between computer system 910 and the local network 920. The network interface 904 may be a digital subscriber line (DSL) or a modem to provide data communication connection over a telephone line, for example. Another example of the network interface is a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links are another example. In any such implementation, network interface 904 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
Computer system 910 can send and receive information, including messages or other interface actions, through the network interface 904 across a local network 920, an Intranet, or the Internet 930. For a local network, computer system 910 may communicate with a plurality of other computer machines, such as server 915. Accordingly, computer system 910 and server computer systems represented by server 915 may form a cloud computing network, which may be programmed with processes described herein. In the Internet example, software components or services may reside on multiple different computer systems 910 or servers 931-935 across the network. The processes described above may be implemented on one or more servers, for example. A server 931 may transmit actions or messages from one component, through Internet 930, local network 920, and network interface 904 to a component on computer system 910. The software components and processes described above may be implemented on any computer system and send and/or receive information across a network, for example.
The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the invention as defined by the claims.
