Patent Description:
To provide a unified user experience for enterprises, it is desirable to connect systems within which data of the enterprise is stored to the DB-based analytics engine. In this manner, an enterprise is able to leverage the more sophisticated and resource-efficient analytics provided by an analytics system through the DB-based analytics engine. Traditional techniques to achieve this include, for example, providing a so-called live connection using an online analytical processing (OLAP) processor, and through the DB-based analytics engine using so-called calculation views. However, such traditional techniques have disadvantages. For example, calculation views used in the database system access causes severe performance issues, because of the complexity and missing metadata, as well as other disadvantages. Bollineni Venkata Saikrishna: "Consuming SAP HANA data into SAP Analytics Cloud through Live connection - End to End scenario" describes end-to-end process of right from creating a SCP HANA Database until consuming that content into SAP Analytics Cloud. D1 discloses a blog post to understand how powerful SAP Analytics Cloud is and how easy it is to setup the whole interoperability.

The present invention is defined by the features disclosed in the independent claims. Additional embodiments are defined in the dependent claims.

The present disclosure further provides a system for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with implementations of the methods provided herein.

It is appreciated that methods in accordance with the present disclosure can include any combination of the aspects and features described herein. That is, methods in accordance with the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

Implementations of the present disclosure are directed to enabling data provided in a first system to be accessed and processed by an analytics engine of a second system. More particularly, implementations of the present disclosure transform metadata (that is used by the first system to store and access data) from a first format to a second format through an intermediate format to enable the analytics engine of the second system to access the data for analytics processing.

Implementations can include actions of retrieving metadata associated with data stored within a database system of an enterprise, the metadata being provided in a first format and being used by the first system to store and access the data, providing a document including the metadata provided in an interoperable format, processing, by a deployer, the document to provide analytics engine metadata in a second format, the analytics metadata being stored in the second system and being consumable by the DB-based analytics engine to access the data from the database system of the enterprise, and retrieving, by the DB-based analytics engine, the data from the database system of the enterprise based on the analytics metadata to provide analytics data based on the data.

Implementations of the present disclosure are described in further detail herein with reference to products, services, and infrastructures provided by SAP SE of Walldorf, Germany. It is contemplated, however, that implementations of the present disclosure can be realized with any appropriate products, services, and/or infrastructures provided by one or more providers.

To provide further context for implementations of the present disclosure, and as introduced above, an enterprise can use multiple systems for storing and processing data. For example, an enterprise can use a system that stores data in a database system and provides metadata that defines how the data is stored and how the data is accessed. An example system includes, without limitation, a data warehouse (DW), which can be described as a system used for storing data, generating reports, and executing data analytics. A DW can be considered a central repository of data integrated from disparate sources and includes metadata that defines how the data is stored and how the data is accessed. For example, the data can be stored in a particular schema (e.g., star schema, discussed below). A DW can store a significant amount of data (e.g., multiple terabytes of data). In some scenarios, a DW is provided as an on-premise system, such that the DW is at least partially managed by the enterprise, for which the DW is established.

By way of non-limiting example, an example DW includes SAP Business Warehouse (BW) provided by SAP SE of Walldorf, Germany. SAP BW can be described as a model-driven data warehousing product based on the SAP NetWeaver ABAP platform. SAP BW collects, transforms and stores data generated in SAP and non-SAP applications and makes the data accessible through built-in reporting, business intelligence, and analytics tools. In SAP BW, data is accessed using so-called InfoCubes, each InfoCube being made up of a set of InfoObjects, which include characteristics (e.g., master data with their attributes and text descriptions) and key figures. An InfoObject can be described as a type of InfoProvider, which is a data object that is created and used to run queries. An InfoCube is structured using a star schema, which includes a fact table that contains key figures for the InfoCube, and several dimension tables surround the fact table. The fact table and dimension tables are both relational database tables that are stored in the underlying database system.

In some examples, a DW (such as SAP BW) includes an analytics engine that enables data to be retrieved from the underlying database system, executes analytics on the retrieved data, and provides analytics results to a client. For example, the analytics engine (also referred to herein as the DW analytics engine, or server-based analytics engine) is executed within an application server. In some examples, the application server receives a request from a client (e.g., a computing device in communication with the application server), and interprets the request based on metadata to determine which data to retrieve from the database. The application server queries the database system using a query language (e.g., (SQL)), and receives data (e.g., hundreds, thousands of records) responsive to the query from the database system. The application server processes the received data using the server-based analytics engine and provides analytics data to the client. This process can be referred to as a <NUM>-tiered approach, in which the majority of processing is executed within the application server.

Analytics systems have been introduced that provide advanced analytics capabilities and improved data processing performance as compared to that provided by DWs, for example. Such analytics systems can include cloud-based analytics systems that include an analytics engine that is executed directly within the underlying database system (e.g., as opposed to a DW analytics engine that executes within an application server). Such an analytics engine is referred to herein as a database (DB) analytics engine (DB-based analytics engine). Accordingly, in response to a request from a client, the request is processed by the DB analytics engine within the database system. Consequently, data stored within the database system is directly accessed by the DB-based analytics engine for analytics processing within the database system, avoiding transmitting data from the database system for analytics processing (e.g., transmitting data from the database system to an application server).

By way of non-limiting example, an example cloud-based analytics system includes SAP Analytics Cloud (SAC) provided by SAP SE of Walldorf, Germany. SAC can be described as an all-in-one platform for business intelligence, planning, and predictive analytics to support enterprise operations. In some examples, SAP SAC uses multi-dimensional services (MDS), which provides a DB-based analytics engine. SAP SAC provides requests to the MDS in a particular protocol (e.g., information access (InA) protocol), which enables more complex data analytics requests to be formulated and executed (e.g., as compared to data analytics requests submitted through the DW).

To provide a unified user experience for enterprises using DWs, it is desirable to connect the DW to the DB-based analytics engine. In this manner, an enterprise using a DW is able to leverage the more sophisticated and resource-efficient analytics provided by an analytics system through the DB-based analytics engine. Traditional techniques to achieve this include, for example, providing a so-called live connection using an online analytical processing (OLAP) processor, and through the DB-based analytics engine using so-called calculation views created by the DW. However, such traditional techniques have disadvantages. For example, calculation views used in the database system access causes severe performance issues, because of the complexity and missing metadata.

With regard to complexity, view creation is designed for usage by SQL-based tools. Consequently, a calculation view contains many parts, which represent features of the DW that may be used. Often, the calculation view contains a complex calculation engine scenario with thousands of nodes. For example, available hierarchies are included by expensive (in terms of resources required to calculate) outer joins, currency conversions are built in, and the like. This leads to substantial instantiation, optimization and runtimes. DW, on the other hand, uses much simpler views - even using SIDs instead of values - and can access the data much faster.

With regard to missing metadata, many details of the view internals are not available as calculation view metadata, which must be used by the DB-based analytics engine. This leads to performance issues. For example, measures using the same currency or unit column or constant in the DW model are shown as different currency/unit columns in the view. The DB-based analytics engine cannot combine these in a single aggregation, because this may result in incorrect results. Runtimes increase with the number of measures used. As another example, all available hierarchies are included in the created view. Without the appropriate metadata, hierarchies requested in the analytics system cannot be used. As another example, the view may contain restricted key figures with additional filters. The calculation view metadata, however, contains a simple base measure only. Count aggregations, which do not explicitly request the measure, may return unexpected results, because the restricted key figure filter is not applied. Besides the above-disadvantages, traditional techniques for connecting the DW to the DB-based analytics engine suffer from other drawbacks.

In view of the above context, implementations of the present disclosure enable data provided in a first system to be accessed and processed by an analytics engine of a second system. More particularly, and as described in further detail herein, implementations of the present disclosure transform metadata (that is used by the first system to store and access data) from a first format to a second format through an intermediate format (referred to herein as an interoperable format) to enable the analytics engine of the second system to access the data for analytics processing.

Implementations of the present disclosure are described in further detail herein with reference to a DW system. It is contemplated, however, that implementations of the present disclosure can be realized with any appropriate system that stores data that is to be accessed by another system.

<FIG> depicts an example architecture <NUM> in accordance with implementations of the present disclosure. In the depicted example, the example architecture <NUM> includes a client device <NUM>, a network <NUM>, and server systems <NUM>, <NUM>. The server systems <NUM>, <NUM> each include one or more server devices and databases <NUM> (e.g., processors, memory). In the depicted example, a user <NUM> interacts with the client device <NUM>.

In some examples, the client device <NUM> can communicate with the server systems <NUM>, <NUM> over the network <NUM>. In some examples, the client device <NUM> includes any appropriate type of computing device such as a desktop computer, a laptop computer, a handheld computer, a tablet computer, a personal digital assistant (PDA), a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or an appropriate combination of any two or more of these devices or other data processing devices. In some implementations, the network <NUM> can include a large computer network, such as a local area network (LAN), a wide area network (WAN), the Internet, a cellular network, a telephone network (e.g., PSTN) or an appropriate combination thereof connecting any number of communication devices, mobile computing devices, fixed computing devices and server systems.

In some implementations, the server systems <NUM>, <NUM> each include at least one server and at least one data store. In the example of <FIG>, the server systems <NUM>, <NUM> is intended to represent various forms of servers including, but not limited to a web server, an application server, a proxy server, a network server, and/or a server pool. In general, server systems accept requests for application services and provides such services to any number of client devices (e.g., the client device <NUM> over the network <NUM>).

In accordance with implementations of the present disclosure, the server system <NUM> can host a DW system operated for enterprise, and the server system <NUM> can be operated by a software provider (e.g., SAP SE) to provision services for one or more enterprises. In some examples, the server system <NUM> and/or the server system <NUM> hosts a database system, within which data of the enterprise is stored. An example database system includes, without limitation, SAP HANA provided by SAP SE of Walldorf, Germany. SAP HANA can be described as a data platform that processes transactions and analytics at the same time on any data type, with built-in advanced analytics and multi-model data processing engines. As described in further detail herein, implementations of the present disclosure enable data of the DW system to be accessed and processed for analytics using the cloud-based analytics system.

<FIG> depicts an example conceptual architecture <NUM> in accordance with implementations of the present disclosure. In the depicted example, the example conceptual architecture <NUM> includes a frontend system <NUM>, a backend system <NUM>, and a cloud services system <NUM>. In general, the example conceptual architecture <NUM> depicts an on-premise approach, in which a system (e.g., a DW system), a database system, and a DB-based analytics engine are provisioned within a server system operated by an enterprise (e.g., the server system <NUM> of <FIG>). That is, for example, the backend system <NUM> is a backend system of the enterprise. In some examples, the cloud services system <NUM> is provided by a software provider (e.g., SAP SE) on a server system (e.g., the server system <NUM> of <FIG>).

In some examples, the frontend system <NUM> can be executed by one or more client-side devices (e.g., the client device <NUM> of <FIG>) and includes a DW administrator user interface (UI) <NUM> and an analytics application <NUM> (e.g., provided as part of SAP SAC). The cloud services system <NUM> can be executed by one or more server-side devices (e.g., the server system <NUM> of <FIG>). In accordance with implementations of the present disclosure, the cloud services system <NUM> includes integration services <NUM>, which includes a metadata handler <NUM> and a deployer <NUM>. Although the integration services <NUM> is depicted within the cloud service <NUM>, it is contemplated that the integration services <NUM> can be provisioned directly within the backend <NUM>. For example, in some implementations, the metadata handler <NUM> and the deployer <NUM> can be provisioned within the backend <NUM> (e.g., on-premise).

In the depicted example, the backend <NUM> includes a DW system <NUM>, integration services <NUM>, application services <NUM>, and a database system <NUM>. By way of non-limiting example, the DW system <NUM> can be provided as at least a portion of SAP BW, introduced above, and the application services <NUM> can be provided as SAP extended application services (XS) provided by SAP SE of Walldorf, Germany. Also by way of non-limiting example, the database system <NUM> can be provided as SAP HANA.

In the example of <FIG>, the DW system <NUM> includes a view generator <NUM>, a data authorization provider <NUM>, a metadata invalidator <NUM>, and a metadata provider <NUM>. The integration services <NUM> includes a data provisioning agent <NUM>, and the application services <NUM> includes a protocol adapter <NUM> (e.g., for the InA protocol). In some examples, the data provisioning agent <NUM> is provided to enable communication (e.g., using HTTP) between the cloud services <NUM> provided by the software provider and the backend system <NUM> of the enterprise provided as an on-premise system.

In the example of <FIG>, the database system <NUM> includes an authorizations store <NUM>, a DW metadata store <NUM>, a facts store <NUM>, a master data store <NUM>, one or more InfoProvider views <NUM>, and, for each InfoProvider view <NUM>, one or more InfoObject views <NUM>. The DW metadata store <NUM> stores metadata that describes how data is stored and can be accessed within the database system <NUM> (e.g., metadata that describes columns, views, and relationships therebetween).

The facts store <NUM> stores fact data, which can be described as data that changes relatively frequently. Example fact data includes, without limitation, sales, revenue, cost, net values, keys (e.g., a key identifying a specific customer) and the like. The master data store <NUM> stores master data, which can be described as data that changes less frequently (e.g., as compared to fact data). An example of master data includes, without limitation, customer data (e.g., name, address, telephone number).

The database system <NUM> further includes an analytics engine <NUM> (e.g., provide as MDS), an analytics engine data access component <NUM>, analytics engine metadata <NUM>, a view cache manager <NUM>, and a view cache <NUM>. In some examples, the view cache manager <NUM> monitors views (e.g., InfoProvider views <NUM>, InfoObject views <NUM>) generated within the database system <NUM>, and caches views in the view cache <NUM>. Accordingly, the first time a view is requested, the view can be generated and stored in the view cache <NUM>, and the second time the view is requested, the view can be provisioned from the view cache <NUM>, if still available in the view cache <NUM>. In this manner, computing resources of the backend system <NUM> can be preserved, because the view does not need to be (re-)generated with each request.

As described in further detail herein, implementations of the present disclosure enable the DB-based analytics engine <NUM> direct access to data stored by the DW system <NUM> within the database system <NUM>. That is, the DB-based analytics engine <NUM> is able to directly access facts stored in the fact store <NUM> and master data stored in the master data store <NUM>. For example, the analytics engine <NUM> receives a request for analytics processing from the analytical application <NUM> and through the application services <NUM>. The analytics engine <NUM> uses the analytics engine metadata <NUM> to provide a data access request to access one or more InfoProvider views <NUM> and one or more InfoObjects <NUM>. In some examples, the data access request is received by the analytics engine data access component <NUM>, which processes the data access request to retrieve data relevant to the request for analytics.

In accordance with implementations of the present disclosure, DW metadata stored in the DW metadata store <NUM> is transformed into analytics engine metadata that has a format that is consumable by the DB-based analytics engine <NUM> and that is stored in the analytics engine metadata store <NUM>. In some implementations, the metadata provider <NUM> retrieves metadata from the DW metadata store <NUM> that would be needed to access a particular view. The metadata provider <NUM> transforms the metadata from a first format to an interoperable format. In some examples, the first format is specific to analytics processing of the DW system (e.g., by a server-based analytics engine executed on an application server), and the interoperable format is not bound to any analytics engine. The interoperable format includes the metadata and expresses the semantics and intent of the metadata. In some examples, the interoperable format includes core schema notation (CSN) and the metadata is provided within a metadata document (e.g., a Javascript object notation (JSON) document). A non-limiting example CSN representation is provided below in Listing <NUM>. In the example of Listing <NUM>, there are two references to "MAX_PLUS_MIN," one in a section "elements" and one in a section "query," which contain the design-time information in terms of standardized/ interoperable "annotations", e.g. "@EndUserText. label", "@Aggregation.

In some implementations, the integration services <NUM> receives the metadata document from the DW system <NUM> (e.g., in response to an HTTP request issued by the integration services <NUM> to the DW system <NUM>). The metadata handler <NUM> interprets the metadata document received from the DW system <NUM> and provides the metadata document to the deployer <NUM>. In some examples, the metadata stored in the DW system <NUM> can be described as single entity definitions and their relations to other entities. One task of the metadata handler <NUM> is, starting with a single entity (e.g., the central entity of a star schema), to collect all metadata from the metadata provider, which is required for the deployer <NUM> to create the AE/runtime-optimized metadata. This would include, for example, all related dimension entities, (language-dependent) texts, and hierarchies for a compete star schema. In order to do so, the metadata handler has to have knowledge about the functional scope of the deployer. The deployer <NUM> transforms the metadata from the interoperable format to a second format that is specific to the analytics engine <NUM> to provide the analytics metadata. The invention defines that the analytics metadata includes data definition language (DDL) statements (e.g., to create or delete objects within the database system <NUM>) and/or data modification language (DML) statements (e.g., to insert, update or delete data within the database system <NUM>). The analytics metadata is stored in the analytics metadata store <NUM> through the data provisioning agent <NUM>. In this manner, DW metadata from the DW metadata store <NUM> is transformed to provide analytics engine data stored in the analytics engine metadata store <NUM>, the analytics engine <NUM> being able to consume the analytics metadata to retrieve data (e.g., facts, master data) within the database system <NUM> for analytics processing within the database system <NUM>.

A non-limiting example DW representation is provided below in Listing <NUM>. In the example of Listing <NUM>, there are two sub-sections "MAX_PLUS_MIN" one in a section of "DataSourceFields" referring to a deployed database runtime artefact (e.g., a SQL view) and another in a section "Measures" (analytics-specific metadata for the MDS runtime).

<FIG> depicts another example conceptual architecture <NUM> in accordance with implementations of the present disclosure. The example conceptual architecture <NUM> depicts a hybrid approach, in which an enterprise uses a cloud-based data warehouse system that access data stored in an on-premise system of the enterprise. In this manner, cloud-based functionality is provided, while maintaining the data on-premise. An example cloud-based data warehouse system includes, without limitation, the SAP Data Warehouse Cloud (DWC) provided by SAP SE of Walldorf, Germany.

In the example of <FIG>, the example conceptual architecture <NUM> includes the frontend <NUM>, a cloud-based DW (e.g., SAP DWC) <NUM>, and a backend system <NUM>' (i.e., on-premise system of the enterprise). The backend system <NUM>' includes a DW system <NUM>', the integration services <NUM>, and a database system <NUM>'. The DW system <NUM>' includes the view generator <NUM>, the data authorization provider <NUM>, the metadata invalidator <NUM>, and the metadata provider <NUM>. The integration services <NUM> includes the provisioning agent <NUM>. The database system <NUM>' includes the authorizations store <NUM>, the DW metadata store <NUM>, the facts store <NUM>, the master data store <NUM>, the one or more InfoProvider views <NUM>, and the one or more InfoObject views <NUM>.

The cloud-based DW includes spaces <NUM>, repositories <NUM>, integration services <NUM>', and a database system <NUM>". The integration services <NUM>' include the metadata handler <NUM>, the deployer <NUM>, the adapter <NUM>, and an authorization and data privacy component <NUM>. The database system <NUM>" includes authorizations <NUM>, provided as a remote table, one or more InfoProvider views <NUM>', provided as respective remote tables, and one or more InfoObject view <NUM>', provided as respective remote tables (also referred to as virtual tables). In some examples, a remote table is a technical artefact in the (local) database system, that appears in all usages to be a table, but in fact it points to a table or view in another database system, which can be referred to as a remote source. The database system <NUM>" also includes the analytics engine <NUM>, the analytics engine data access component <NUM>, the analytics engine metadata <NUM>, the view cache manager <NUM>, and the view cache <NUM>.

As similarly described above with reference to <FIG>, DW metadata stored in the DW metadata store <NUM> is transformed into analytics engine metadata that has a format that is consumable by the DB-based analytics engine <NUM> and that is stored in the analytics engine metadata store <NUM>. In some implementations, the metadata provider <NUM> retrieves metadata from the DW metadata store <NUM> that would be needed to access a particular view. The metadata provider <NUM> transforms the metadata from the first format to the interoperable format. In some implementations, the integration services <NUM>' receives the metadata document from the DW system <NUM> (e.g., in response to an HTTP request issued by the integration services <NUM> to the DW system <NUM>'). The metadata handler <NUM> interprets the metadata document received from the DW system <NUM>' and provides the metadata document to the deployer <NUM>. The deployer <NUM> transforms the metadata from the interoperable format to the second format that is specific to the analytics engine <NUM> to provide the analytics metadata, which is stored in the analytics metadata store <NUM>. In this manner, DW metadata from the DW metadata store <NUM> is transformed to provide analytics engine metadata stored in the analytics engine metadata store <NUM>, the analytics engine <NUM> being able to consume the analytics metadata to retrieve data (e.g., facts, master data) within the database system <NUM>' for analytics processing within the database system <NUM>".

In some implementations, to trigger transformation of metadata to provide analytics engine metadata, data within the database system <NUM>, <NUM>' can be identified as being accessible by the analytics engine <NUM>. For example, a user (e.g., an administrator) can access the DW system <NUM>, <NUM>' through the DW administrator UI <NUM>, and can mark data (e.g., InfoProviders) that are to be accessible to the analytics engine <NUM>. For example, the user can set a flag associated with the data, the flag indicating that the data is to be accessible to the analytics engine <NUM>. In some examples, for each InfoProvider marked as to be accessible to the analytics engine <NUM>, a SQL view is generated with all dimensions relevant to the InfoProvider and including navigation attributes and measure fields from the InfoProvider. In some examples, only fields of the InfoProvider (e.g., dimension-key, measures) are included. In response to data being marked as accessible to the analytics engine <NUM>, the metadata provider <NUM> can retrieve corresponding metadata from the DW metadata store <NUM> to transform the metadata and provide the analytics engine metadata, as described herein.

In some implementations, it can be determined that metadata underling data that is to be accessible to the analytics engine <NUM> has changed. For example, an update to the database system <NUM>, <NUM>' can result in a structure of data being changed, which also results in the corresponding metadata being changed. In some examples, the metadata invalidator <NUM> can be provided as a listener that detects a change in metadata of data that is to be accessible to the analytics engine <NUM>. If a change has occurred, the metadata invalidator <NUM> triggers redeployment of the metadata as analytics engine metadata. That is, for example, the metadata provider <NUM> can retrieve corresponding metadata from the DW metadata store <NUM> to transform the metadata and provide the analytics engine metadata, as described herein.

For purposes of illustrating implementations of the present disclosure, and without limitation, a brief description and example of the analytics engine <NUM> processing a request from the analytical application is provided and includes how the analytics metadata is used to identify and access data (i.e., an end-to-end workflow starting from the analytics application making a request to the MDS). In further detail, the analytical application request metadata in order to, for example, offer the selection of dimensions and measures to a user (e.g., in an "edit chart" dialogue). In some examples, the MDS reads its private representation and converts the measures section into the format specified for client/server exchange for metadata (which is close to the MDS-internal format). This is part of the runtime optimization: that it only uses relatively few and cheap (in terms of resources expended to execute) transformations to prepare the response for a metadata request. The analytical application has a chart definition, for example, with the dimension "Fiscal Year" and the measure "Max + Min," and sends a corresponding data request to the MDS. The MDS reads the metadata of the requested fields in order to prepare a response to the data request. The MDS determines that "Fiscal Year" is a dimension and there is a corresponding column in the data source / underlying SQL view, and that "Min + Max" is a measure. In some examples, "Min + Max" can be provided as a formula (e.g., non-SQL default aggregation FORMULA), referring to other measures "Min" (with default aggregation MIN) and "Max" (with default aggregation MAX). For those measures there are corresponding columns in the data source.

In some examples, the MDS prepares an execution plan. An example execution plan based on the above example can include first reading MIN(Min) and MAX(max) group by FISCAL_YEAR from the underlying (SQL) data source, and then calculate the formula MAX_PLUS_MIN for each row of the result set. In some examples, the MDS executes the execution plan (e.g., by creating a complex SQL request or a transient DB runtime artefact ("caculation scenario") for this plan and execute it). The MDS returns the query result in accordance with the metadata (e.g. values for measure MIN_PLUS_MAX).

<FIG> depict example screen-shots for a query design-time within a DW system. In the examples of <FIG>, the example measure MAX_PLUS_MIN is defined, which is used in the examples of Listing <NUM> and Listing <NUM> provided herein.

<FIG> depicts an example process <NUM> that can be executed in accordance with implementations of the present disclosure. In some examples, the example process <NUM> is provided using one or more computer-executable programs executed by one or more computing devices.

A trigger is received (<NUM>). For example, a user can mark data stored within the database system <NUM>, <NUM>' as to be accessible to the analytics engine <NUM>, the trigger being marking of the data. As another example, it can be determined that metadata associated with data stored within the database system <NUM>, <NUM>' that is to be accessible to the analytics engine <NUM> has changed, the trigger being changing of the metadata. DW metadata is accessed (<NUM>) and a document is provided including DW metadata provided in the interoperable format (<NUM>). For example, in response to the trigger, DW metadata associated with the data that is to be accessible to the analytics engine <NUM> is accessed by the metadata provider <NUM>, which converts the DW metadata to an interoperable format. In some examples, the interoperable format includes CSN.

The document is processed to provide analytics metadata (<NUM>). For example, the metadata handler <NUM> receives the document from the DW system <NUM>, <NUM>', and the deployer <NUM> processes the document to provide the analytics metadata in the second format, such that the analytics metadata is consumable by the analytics engine <NUM> to access the data from the database system <NUM>, <NUM>'. The analytics metadata is stored in the analytics metadata store (<NUM>). Data is retrieved from the database system of the enterprise based on analytics metadata (<NUM>).

Referring now to <FIG>, a schematic diagram of an example computing system <NUM> is provided. The system <NUM> can be used for the operations described in association with the implementations described herein. For example, the system <NUM> may be included in any or all of the server components discussed herein. The system <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, and an input/output device <NUM>. The components <NUM>, <NUM>, <NUM>, <NUM> are interconnected using a system bus <NUM>. The processor <NUM> is capable of processing instructions for execution within the system <NUM>. In some implementations, the processor <NUM> is a single-threaded processor. In some implementations, the processor <NUM> is a multi-threaded processor. The processor <NUM> is capable of processing instructions stored in the memory <NUM> or on the storage device <NUM> to display graphical information for a user interface on the input/output device <NUM>.

In some implementations, the memory <NUM> is a computer-readable medium. In some implementations, the memory <NUM> is a non-volatile memory unit. In some implementations, the storage device <NUM> may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. In some implementations, the input/output device <NUM> includes a keyboard and/or pointing device. In some implementations, the input/output device <NUM> includes a display unit for displaying graphical user interfaces.

The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier (e.g., in a machine-readable storage device, for execution by a programmable processor), and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result.

Elements of a computer can include a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer can also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks.

The features can be implemented in a computer system that includes a backend component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. Examples of communication networks include, for example, a LAN, a WAN, and the computers and networks forming the Internet.

Claim 1:
A computer-implemented method for accessing data provided in a first system by a database, DB, -based analytics engine (<NUM>) of a second system, the method being executed by one or more processors and comprising:
retrieving metadata associated with data stored within a database system (<NUM>) of an enterprise, the metadata being provided in a first format and being used by the first system to store and access the data, wherein the metadata defines how data is stored and accessed within the database system (<NUM>), and comprises entity definitions and relationships between entities;
providing a document including the metadata provided in an interoperable format, wherein the interoperable format is not bound to any analytics engine (<NUM>);
processing, by a deployer (<NUM>), the document to provide analytics engine metadata in a second format, the analytics metadata being stored in the second system and being consumable by the DB-based analytics engine (<NUM>) to access the data from the database system (<NUM>) of the enterprise, wherein the deployer (<NUM>) transforms the metadata from the interoperable format to the second format that is specific to the DB-based analytics engine (<NUM>) and wherein the analytics metadata comprises one or more of data definition language statements to create or delete objects within the database system (<NUM>) and/or data modification language statements to insert, update or delete data within the database system (<NUM>); and
retrieving, by the DB-based analytics engine (<NUM>), the data from the database system (<NUM>) of the enterprise based on the analytics metadata to provide analytics data based on the data.