Patent Application
20150293947
Enterprise business applications such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), Supplier Relationship Management (SRM) and the like are executed based on data models. Data models are used to describe data requirements, types of data and data computations that can be processed or stored in a database. Further, the data models include entities and relationships between the entities defined by one or more schemas.
Development tools for the types of applications mentioned above may include a set of Domain-Specific Languages (DSL) and services for defining and consuming semantically rich data models. Further, the development tools may include tools to view the entities and relationships between the entities in the data model. However, existing development tools may execute complex queries which are provided manually, thereby resulting in a tedious and error prone process.
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 to validate relationships between entities in a data model are described herein. Entities are abstractions of items in an information domain that are capable of independent existence or can be uniquely identified. For example, the entities include business data produced during the course of business activities taken place in an enterprise. Relationships capture how the entities may be related to one another in a data model to process enterprise business applications such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), Supplier Relationship Management (SRM).
According to one embodiment, the relationships between the entities associated with the data model are validated in real time by selecting an object or record of an entity associated with the data model. The entity can be referred as a source entity. Upon receiving the selection of the object in the source entity, the entity relationship parser dynamically provides a list of associations corresponding to the source entity, where each association defining a related other entity in the data model. This other entity can be referred to as a target entity. Further, upon receiving a selection of an association from the list of associations, entity relationship data corresponding to the selected object and the target entity based on the selected association is retrieved and rendered on display device. Since the relationships between the entities associated with the data model are viewed and validated by selecting associations, an intuitive experience of navigation from one entity to another related entity is experienced.
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 back-end component 110 includes data repository 130 storing entities (e.g., entities 115A to 115N) generated by business operating groups in an enterprise. The entities (e.g., entities 115A to 115N) include business data, also referred as transactional data or application data produced during the course of business activities taken place in the enterprise. For example, the entities (e.g., entities 115A to 115N) may include, but are not limited to, employee details of an enterprise, sales data generated by sales groups, production figures from manufacturing groups, and purchase orders of raw materials used for manufacturing, travel expenses, marketing and advertising costs.
Multiple entities (e.g., entities 115A to 115N) are modeled by applying database operations (e.g., Structured Query Language (SQL) operations such as SELECT, JOIN, SUM and the like) to define the data model 120 for executing business applications 180. For example, the business applications 180 can be enterprise resource planning (ERP), customer relationship management (CRM), supply chain management (SCM), supplier relationship management (SRM), and so on. Thereby, the data model 120 includes entities (e.g., entities 115A to 115N) related to one another.
The data model 120 may further associate with meta-model 135 identifying the entities (e.g., entities 115A to 115N) in the data model 120, specifying characteristics of the entities (e.g., entities 115A to 115N), and also describing how the entities (e.g., entities 115A to 115N) are stored. For example, the meta-model 135 may identify the entities (e.g., entities 115A to 115N) that the data model 120 references, table fields of the entities (e.g., entities 115A to 115N) that constitute the data model 120, the view definitions for generating views that include the data model 120, and so on. Further, the meta-model 135 may specify how the entities (e.g., entities 115A to 115N) relate to each other (e.g., primary key and foreign key relationships) in the data model 120. In some embodiments, the meta-model 135 may be stored in a metadata repository as a set of tables.
Furthermore, the meta-model 135 may specify constraints on the business data that include the data model 120. For example, data types (i.e., text, integers, date values, etc.), maximum values, valid data ranges, valid values, maximum number of characters, and so on. The meta-model 135 may include supplemental information such as, labels and textual information that may be displayed on a user interface or in a report when presenting views of the data model 120.
The computing system 105 includes processor 140 to execute software instructions or code stored on memory 145. According to an embodiment, the memory 145 includes development tools. For example, the development tool can be Advanced Business Application Programming (ABAP) 150 in Eclipse. ABAP is a computer programming language used in developing business applications. Eclipse provides a core of services for controlling a set of tools that work together to support programming tasks. Tool builders contribute to the Eclipse platform by wrapping their tools in pluggable components, called Eclipse plug-ins (e.g., 155), which conform to Eclipse's plug-in standard. Further, the Eclipse runtime environment provides an infrastructure to support the activation and operation of a set of plug-ins working together to provide a seamless environment to support programming activities.
The back-end computing system 110 stores the development tool dictionary in the library 160 of application server 175 or in an associated repository. The dictionary includes data describing the logical structure of application development objects and their representations. The development tool runtime environment components, such as application programs or a database interface, obtain information about these objects from the dictionary. Computer programs on the computing system 105 make use of information from the dictionary during application development. For example, the computer programs include an Eclipse program for running the Eclipse environment on the computing system 105, and an ABAP program for supporting ABAP programming on the computing system 105. Eclipse plug-in 155 (referred to as the “ABAP plug-in”) is provided on the computing system 105 to enable ABAP developers to program in an Eclipse environment and thereby to take advantage of tools provided in the Eclipse workbench.
In one embodiment, the development tools such as ABAP development tools include a set of Domain-Specific Languages (DSL) and services for defining and consuming semantically rich data models (e.g., data model 120), referred to as Core Data Services (CDS) 165 in ABAP development tools, for instance. The CDS 165 includes entity relationship parser 170 to validate relationships between the entities (e.g., entities 115A to 115N) associated with the data model 120 and to render entity relationship data on display device 195.
In some embodiments, components of the computing environment 100 may be instantiated across multiple servers. For example, the data repository 130 may be provided on a database server system and the data models (e.g., the data model 120) including the meta-model 120 may be provided on a separate application server (e.g., the application server 175). The application server 175 includes processor 185 to execute instructions stored in memory 190. The application server 175 may communicate with the data repository 130 via a suitable communication network (e.g., local area network (LAN), wide area network (WAN) and so on). Further, the entity relationship parser 170 in the CDS 165 of a data modeling tool may be provided on yet another server that communicates with the data repository 130 and the application server 175 over suitable communication networks (e.g., the network 125).
In other embodiments, the database server system storing the data repository 130 may be an in-memory database product that serves as the primary database for the business applications 180 (e.g., ERP, CRM, etc.). An example of an in-memory database is the SAP HANA® database product. Further, the entity relationship parser 170 may be implemented in the data modeling tool that runs on the in-memory database product.
The data table 210 defines entity “Employees” associated with an enterprise. The data table 210 includes data objects representing employees in the enterprise. Further, the data table 210 includes X attributes such as, “Identity Number” (e.g., 225), “First Name” (e.g., 230), “Last Name” (e.g., 235) and “Date of Joining” (e.g., 240). Similarly, the data table 220 defines entity “Managers” associated with the enterprise. The data table 220 includes data objects representing Managers in the enterprise. Further, the data table 210 includes Y attributes such as, “Identity Number” (e.g., 245), “First Name” (e.g., 250), “Last Name” (e.g., 255) and “Reportee” (e.g., 260).
Multiple entities are modelled or grouped to form a data model by defining association between one entity to another entity using Structured Query Language (SQL) operations such as JOIN, for instance. Further, defining associations can be referred to as defining relationships between entities in the data model. For example, consider a database with the data table 210 (e.g., representing the entity “Employees”) and the data table 220 (e.g., representing the entity “Managers”). Suppose the business application requires to identity managers for each employee. The “identity number” 225 of the data table 210 is joined or linked to “reportee” 260 of the data table 220 using JOIN (e.g., primary key and foreign key) to identity managers of the entity “Managers” corresponding to each employee of the entity “Employees” (e.g., 270). The relationships between the entities are determined by matching the primary key in one of the data tables with the foreign key in the second data table, for instance. The “Identity Number” 225 in the entity “Employees” points to the “Reportee” 260 in the entity “Managers”. The “Identity Number” 225 is the primary key in the entity “Employees” and the “Reportee” 260 is the foreign key in the entity “Employees.” Thereby, association between the entity “Employees” and the entity “Managers” is defined.
At step 310 of
At step 320 of
At step 330 of
At step 350 of
In one embodiment, the CDS data preview tool provides an option to input one or more filter criteria to refine the entity relationship data to further validate the entity relationship data. The option enables to add one or more complex filters. Accordingly, data preview tool fetches the objects that match the filter criteria. For example,
Therefore, it is possible to navigate from one entity to another entity associated with the data model via associations, any number of times, and can validate or check the correctness of associations by previewing data at each target entity (reached via association). Also, the technique described has the ability to intuitively retrace the association to the source entity, without losing any filters attached in the previous steps.
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 DataBase 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 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 one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the embodiments 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 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.
