Patent Application
20170169076
Embodiments of the invention generally relate to data processing, and more particularly to a system to perform impact analysis of objects.
Enterprises use Business Intelligence (BI) tools or applications such as reports, web intelligence, etc., to enable transforming raw data to useful analytics. Typically, BI tools are extensible, open-framework platform hosting both enterprise applications and third-party products. BI applications enable various functionalities such as reporting, online analytical processing, data mining, predictive analysis, etc. BI applications and tools may be used to process and analyze enormous amount of inter-related data inter-related to each other. A change or modification to one of entity such as database connections, queries, etc., in a BI application may impact various other related entities like report, chart, etc. It is challenging to identify the granular impact created by changing or modifying an entity in BI application.
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 system to perform impact analysis of objects 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.
In a BI platform, individual entities are represented as objects or ‘Info Objects’. For example individual entities such as users, servers, documents, universes, applications, etc., are represented as ‘Info Objects’. Objects may be rows in a repository that store information about entities they represent. Objects may be collection of name-value pairs called properties in the repository.
By way of example, an algorithm to perform impact analysis of objects is illustrated below with reference to
SELECT * FROM TABLE A, TABLE B, TABLE C WHERE NAME LIKE ‘%-Type A’ AND RELATION_TABLE_NAME =RELATIONSHIP13 TABLE
Query 404 is formulated to select relationship objects from various BI tables such as table A, table B and table C, that matches the type of the object ‘type A’. The formulated query is executed, and the relationship objects ‘555 Usergroup-User (Relationship)’ 406, ‘559 ServiceA-ServiceB (Relationship) 408’ and ‘564 EventA-EventB (Relationship) 410’ are retrieved as shown in list 412. For the individual relationship objects retrieved, nested properties associated with the relationship objects are determined. For one such relationship object ‘555 Usergroup-User (Relationship)’ 406, the nested properties are identified as shown in list 414. The nested properties in the list 414 are parsed to determine whether value of the nested property is of type ‘type A’. In the nested properties 414 identified, ‘relation_clause’ 416 is determined to be of type ‘type A’ 418 as ‘relation_clause=type- type A’. This determination assures that the relationship object retrieved is of type ‘type A’. Upon determining that the value of the nested property is of type ‘type A’, the nested properties in the list 414 are parsed to identify a value of parent property as ‘parent B’ 420. A query is formulated to fetch dependent values corresponding to the parent property ‘parent B’ 420. The fetched dependent values for the parent property ‘parent B’ 420 are as shown in list 422 in
Query 426 is formulated to select object names from BI table ‘table D’ where the dependent values in the list 422 are specified in the query. The impacted objects 424 are displayed as a result of execution of query 426. The impacted objects 424 can also be displayed in the form of a spider chart or radar chart as objects resulting from impact analysis of selected object ‘object B’.
In one embodiment, object can be selected for impact analysis in a user interface of the BI application. The request is processed at a database layer such as in-memory database layer, and the results of the analysis are returned to the user interface of the BI application. In one embodiment, algorithm and the functionalities associated with the impact analysis feature can be packaged as add-on application and shipped with enterprise application such as BI applications. Users may choose to deploy or install impact analysis add-on application along with the BI application, and perform impact analysis from a user interface associated with the add-on application.
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 maybe 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. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory 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 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 Data Base Connectivity (ODBC), produced by an underlying software system (e.g., 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 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 detail.
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 one or more embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
