A data table includes various data fields. For example, a data table for alerts may include the data fields such as alert name, alert status, person responsible for alert, risk value, risk sore, etc. Some of the data fields are critical and are more frequently analyzed. For example, ‘person responsible for alert,’ ‘risk score,’ and ‘risk value’ may be the critical data fields. The critical data fields are displayed along with other data fields in the data table. Therefore, it might be difficult to focus on the critical data fields. Further, each data field has one or more values or data. If the data table includes large volume of critical data corresponding to the critical data fields, a user may be required to scroll up-and-down or move between screens to see and analyze the critical data which might be inconvenient and time consuming.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for representing critical data fields of data tables are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
The following terminology is used while disclosing various embodiments. One skilled in the art will recognize that these terms and examples they are used in are merely illustrative.
Critical data fields are those fields of data tables which can be of more interest to a user or otherwise emphasized. What is critical may vary depending on the context. In one context, data fields of a data table which are more frequently analyzed by a user may be critical. For example, the data table related to laptops may include data fields such as brand name, RAM size, model, price, quantity sold, etc. For laptop dealers, the data fields namely brand name, model, and quantity sold may be more frequently analyzed and therefore critical. In some embodiments, the critical data fields are predefined. For example, if the data table is generated for the laptop dealers, then the data fields namely brand name, model, and quantity sold may be predefined as the critical data fields. In some embodiments, the critical data fields may be automatically determined at runtime, based upon the user's behavior, for instance. For example, the critical data fields may be determined at runtime by recording those data fields which are more frequently accessed by the user. In one embodiment, an access count of the data field is recorded and if the access count reaches a predefined number, the data field is automatically defined as the critical data field.
Non-critical data fields are data fields which are not often analyzed by the user, i.e., less frequently analyzed data fields. For example, taking the same example of the data table related to laptop, the data fields namely RAM size and price may not be frequently analyzed by the laptop dealers. Therefore, the data fields RAM size and price may be non-critical data fields for the laptop dealers. In those embodiments where the critical data fields are automatically determined at runtime, a non-critical may be converted to a critical data field based upon the user's behavior or access count.
Once the critical data fields C1-CN are identified, the graph generating module 110 reads the data related to the critical data fields C1-CN. The data table 120 includes values or data related to the critical data fields C1-CN and the non-critical data fields NC1-NCN. For example, the critical data field C1 has the values E1-E5, the critical data field C2 has the values U1-U5, the critical data field C3 has the values V1-V5, and the critical data field CN has the values W1-W5. The graph generating module 110 reads the data E1-E5, U1-U5, V1-V5, and W1-W5 related to the critical data fields C1, C2, C3, and CN, respectively.
Once the data of the critical data fields C1-CN are read, the graph generating module 110 generates the graphical representation 130 of the data related to the critical data fields C1-CN. In one embodiment, the graph generating module 110 identifies the axis or coordinates associated with the critical data fields C1-CN. The axis for critical data fields C1-CN may be predefined. For example, it may be predefined that the critical data field C2 is to be represented on an X axis, the critical data field C3 is to be represented on a Y axis, and the critical data field C1 is to be represented relative to the critical data fields C2 and C3. For example, the critical data field C1 may be represented as (x, y) coordinate on an X-Y plane. In one embodiment, some critical data fields, e.g., the critical data field CN may be represented as different colors or shades on the graphical representation 130. In one embodiment, some rules may be predefined for assigning the axis to the critical data fields C1-CN at runtime. For example, a rule may be defined as “represent a highest accessed data field on the X axis” and “represent a second highest accessed data field on the Y aris.”
Once the axis associated with the critical data fields C1-CN are identified, the graph generating module 110 represents the data related to the critical data fields C1-CN on their identified axis. For example, as illustrated in
In one embodiment, the data related to the critical data fields C1-CN are rendered as geometrical shapes on the graphical representation 130. For example, as illustrated in
In one embodiment, the circles, representing the data E1-E5, may be colored to show which data E1-E5 is assigned to which user W1-W5. For example, it can be identified that the data E1 is assigned to the user W1, the data E4 is assigned to the user W4, etc. In another embodiment, the circles may be tagged with their respective user name W1-W5 to indicate which data or circle is assigned to which user.
The user can analyze the graphical representation 130 to analyze the critical data fields (e.g., the risk score C6, the timeframe C2, and the user C3) related to the alerts A1-A10. For example, all unassigned alerts (blank circles in
In one embodiment, as illustrated in
In one embodiment, the graphical representation 130 of the critical data fields C1-C6 is displayed automatically when the data table 120 is opened. In another embodiment, as illustrated in
In one embodiment, the user can select an area including a subset of data on the graphical representation 130. For example, as illustrated in
In one embodiment, the graphical representation 130 may be modified based upon a modification in the data table 120. For example, if the alert A1 having the highest risk value 5.00 Euro is ‘closed’ then the risk score C6 of all other alerts A2-A10 would be affected or changed. A new risk score C6 would be calculated based upon the next highest risk value, i.e., 4.50 Euro. Now, 4.50 Euro would corresponds to the risk score 100. Therefore, the risk score C6 of all the alerts A2-A10 would increase and the circles would move vertically (upward) on the Y axis of the graphical representation 130. The circles would not move horizontally, as the timeframe C2 within which the alerts A2-A10 are due is still the same. Therefore, according to one embodiment, the graphical representation 130 can be modified based upon the modification in the data table 120. In one embodiment, the graphical representation 130 is modified on the fly or instantly.
In one embodiment, the same method may be applied for representing the non-critical data fields NC1-NCN graphically. In another embodiment, a combination of critical data fields C1-CN and the non-critical data fields NC1-NCN may be represented graphically using the above described method.
The data table 120 may be modified based upon the selection of areas on the graphical representation 130. The area including the subset of data, e.g., A5-A7, may be selected by the user on the graphical representation 130 related to the critical data fields C1-C6. At step 1105, the user's selection of the subset of data A5-A7 is received on the graphical representation 130 of the critical data fields C1-C6. Once the user's selection of the subset of data A5-A7 is received, the data table 120 is updated to display only the selected subset of data A5-A7. Typically, the subset of the data table 120 (e.g., rows related to the data A5-A7) is displayed based upon the selected subset of the data at step 1106. Therefore, the user can further drill down the critical data represented on the graphical representation 130. The further drilling of data enables users to clearly and efficiently analyze or focus on the selected subset of data A5-A7 of their interest.
Embodiments described above enable rendering critical data fields separately. The critical data fields can be viewed together. Therefore, a user can focus on the critical data fields without being distracted. Further, the critical data fields are displayed in a graphical representation which makes analysis clear, easy, less time consuming, and efficient. A relationship between various critical data fields can also be easily analyzed on the graphical representation. The graphical representation may be rendered along with a data table. The graphical representation may be positioned in a vertical orientation or in a horizontal orientation relative to the data table. Users can select the orientation based upon their convenience. Further, the user can make selection on the graphical representation and based upon the selection, the data table is modified on the fly. Also, the graphical representation can be modified on the fly based upon the modification in the data table. Therefore, such modification of the graphical representation and the data table makes analysis more substantive.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components may be implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic indicator devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Database Connectivity (ODBC), produced by an underlying software system, e.g., an ERP system, and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the one or more embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the embodiment are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the embodiments, as those skilled in the relevant art will recognize. These modifications can be made to the embodiments in light of the above detailed description. Rather, the scope of the one or more embodiments are to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.