Patent Description:
One aspect of the present disclosure relates to a system configured for generating an online analytical processing (OLAP) cube in accordance with claim <NUM>.

Another aspect of the present disclosure relates to a method for generating an online analytical processing cube in accordance with claim <NUM>.

Yet other aspects of the present disclosure relate to a non-transient computer-readable storage medium in accordance with claim <NUM>.

Systems and methods are disclosed for specifying OLAP cubes at a database query time. Additionally, the creation of OLAP cubes over star schema is simplified. The search and discovery of existing OLAP cubes is simplified. Finally, the time is reduced to start querying an OLAP cube after it is defined and updated. These features and advantages are at least partially accomplished by decoupling the schema from the instance. Star schemas can more generally be described as a relational data warehouse designed for speed of retrieval. Cube structures are often built from relational data warehouses in order to provide faster and more powerful analysis of the data. In general, cube structures accomplish this by organizing data in a hierarchical arrangement according to dimensions and measures. Dimensions may group the data along natural categories and consist of one or more levels where each level represents a different grouping within the same dimension. The levels can be organized into one or more hierarchies, typically from a coarse-grained level down to the most detailed. Measures can be the cube data values that are summarized and analyzed.

Some types of OLAP cubes or other cube database structures are a managed service that allows developers to improve queriability of their multidimensional data through cube modeling. It provides data curation, protection against erroneous schema modification, and fast querying. It handles both simple and complex business logic. One technical and computer-centric problem solved is simplifying creation of a cube database which would otherwise require writing multiple schema files. A schema is the structure behind the data organization. It comprises different table relationships enabling the business rules for the underlying mission for which the database is created. Simplification would result in a reduction of time taken to write the schema. Using the single configuration file, (<NUM>) the data-source property configuration for each data-source is automatically generated and (<NUM>) whether the columns of relational data-sources are key, attribute, or measure are automatically generated. Cube creation may involve a tool which involves human in building the cube definition. The tool can automatically generate configuration and schema (or cube definition) of the OLAP cube and when tool finds anything ambiguous it involves human to remove the ambiguity. asks questions to the end user to generate the cube definition itself.

Another technical and computer-centric problem solved is creation of a mechanism where none exists for discovery of existing and new OLAP cubes. Cubes are indexed so that they can be searched and discovered.

Another technical and computer-centric problem solved is the reduction of time to write a query, from deciding to use an OLAP cube to execution of the query. In some implementations, the time may be reduced from on the order of days to on the order of seconds.

In some implementations, one component of the disclosed systems and methods is providing functionality for a user to specify a cube identifier in the request itself. Another component may be a schema-less tenant/instance which brings the cube definition file from a data-source at query time and then executes the query over the cube definition file. This may involve reducing the cube definition file creation time by not creating self-contained query language specific objects inside the cube definition file. In some implementations, additional latency due to cube definition file creation on the fly may be reduced by (<NUM>) cube definition file caching for reuse of cube definition files if the query comes again over the same cube, (<NUM>) prefetching cube definition files, where changes in OLAP cubes are scanned for changes and the in-memory cache of the cube is updated whenever a cube definition changes, and (<NUM>) a tenant owns the datascape schema provider instead of creating datascape schema provider every time at query time.

<FIG> is a block diagram of an example network architecture <NUM> for specifying an OLAP cube at query time. An architecture can include one or more database servers <NUM>, user devices <NUM>, and a network <NUM>.

In some implementations, the user devices <NUM> may be used by a user to perform various actions and/or access various types of content, some of which may be provided over a network <NUM> (e.g., the Internet, LAN, WAN, etc.). A "user" or "entity" used herein may refer to an individual operating user devices <NUM>, interacting with resources or content items via the user devices <NUM>, etc. The user devices <NUM> may be used to access websites (e.g., using an internet browser), media files, and/or any other types of content. An API (e.g., cube definition file API <NUM>) may be configured to access content for display to users within resources (e.g., webpages, applications, etc.) and to provide content items to the user devices <NUM> over the network <NUM> for display within the resources. The content from which the API selects items may be provided by one or more database servers <NUM> via the network <NUM>. In some implementations, one or more of the database servers can be at least a data catalog <NUM> and/or a schemaless database server <NUM>.

<FIG> is a block diagram of an example query system <NUM>. In some implementations, the user device <NUM> can contain a graphical user interface (GUI) <NUM> and a cube definition file API <NUM>. There may be data flow from piper <NUM> to data catalog <NUM> into the cube definition file API <NUM>. There may be an OLAP cube query request from the cube definition file API <NUM> to the schemaless database server <NUM>. The query request may also go through one or more of a visualization explorer <NUM>. In some implementations, a drag and drop query interface may be used. The schemaless database server <NUM> can contain a query scope schema.

In some implementations, the user device <NUM> contains a GUI <NUM>. The GUI can be configured to allow a user to create new dimensions and measures and then map them onto data-source columns.

In some implementations, the user device <NUM> contains a cube definition file API <NUM>. The cube definition file API <NUM> may provide a shell to allow a user to set the cube definition file during a session. In some implementations, cube definition file creation time is reduced by not creating self-contained query language (e.g., RVL) specific objects inside the cube definition file. Further latency may be avoided by cube definition file caching and prefetching. Cube definition file caching may include storing a cube definition file to use if a query is received again over the same cube instead of recreating the cube definition file every time. A cube definition file prefetcher may scan for changes in OLAP cubes in data catalog <NUM>. Whenever a cube definition changes, the cube definition file prefetcher can update the in-memory cache of the OLAP cube. A query specific field may be used to bypass the cache completely and access data catalog <NUM> directly to fetch cube definition file changes.

In some implementations, the example query system <NUM> includes a piper <NUM> (i.e., a version control system). The piper <NUM> can be used to modify a cube definition file and can validate a query against the modified schema. In some implementations, piper <NUM> can be used to search for an OLAP cube. In some implementations, were the OLAP cubes are indexed in data catalog <NUM>, piper <NUM> accesses the index in data catalog <NUM>. Schema in piper <NUM> may be synced to data catalog <NUM> for discovery. Schema in piper <NUM> may be synced to data catalog <NUM> for use in a schemaless database server <NUM>.

In some implementations, the example query system <NUM> includes a data catalog <NUM>. The data catalog <NUM> may index every OLAP cube where it can be searched and discovered. In some implementations, cube definition files may be stored in data catalog <NUM> where it is discoverable. In some implementations, data catalog <NUM> can be used to modify a cube definition file and can validate a query against the modified query. In some implementations, were the OLAP cubes are indexed in data catalog <NUM>, piper <NUM> accesses the index in data catalog <NUM>. Cube definition files in piper <NUM> may be synced to data catalog <NUM> for discovery.

In some implementations, the example query system <NUM> includes a visualization explorer <NUM>. The visualization explorer <NUM> can serve a static dashboard or dynamic dashboard on top of an OLAP cube. In some implementations, visualization explorer <NUM> can be used as a service to generate an interactive report. A visualization explorer <NUM> instance may have to be set up and customized. In some implementations, the example query system <NUM> includes other visualization explorers. The visualization explorers may provide access to a data-source. In some implementations, visualization explorers can be used as a service to generate an interactive report.

In some implementations, the example query system <NUM> comprises a schemaless database server <NUM>. The schemaless database server <NUM> may contain a query scope schema <NUM>. The schemaless database server <NUM> may use schema (i.e., cube definition files) in piper <NUM> synced to data catalog <NUM>. In some implementations, the schemaless database server <NUM> can run a request on an OLAP cube that is provided as part of the query request. The query scope schema <NUM> can be configured to use a reference to data catalog <NUM> in a query specifying what cube definition file to use. In some implementations, the example query system <NUM> uses an OLAP context container, wherein an OLAP context container is an object that is used during OLAP query execution to convert an OLAP query to an SQL query. The OLAP context container may contain mapping from an OLAP model to relational data sources. The OLAP context container may also contain various indexes to speed up an OLAP conversion request. In some implementations, the OLAP context container further comprises user-specified data to influence the heuristics used during the SQL generation. For example, user-specified data in the OLAP context container may determine that a cube schema preferentially selects one data source over another when a particular set of fields are requests.

<FIG> illustrates a method <NUM> for generating an online analytical processing cube, in accordance with one or more implementations. The operations of method <NUM> presented below are intended to be illustrative. In some implementations, method <NUM> may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method <NUM> are illustrated in <FIG> and described below is not intended to be limiting. In brief, method <NUM> comprises receiving a cube definition file, accessing a data source, generating a data-source property configuration for the data source, determining each of the respective parsed data from the data source is a key, attribute, or measure, and generating an OLAP cube by combining the cube definition file and the data-source property configuration for the data.

In some implementations, method <NUM> may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices (e.g., database servers <NUM>, schemaless database server <NUM>, etc.) may include one or more devices executing some or all of the operations of method <NUM> in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method <NUM>.

Still referring to <FIG> and in more detail, an operation <NUM> includes receiving a cube definition file. In some implementations, rather than requiring multiple cube definition files to create an OLAP cube, an OLAP cube can be created using a data-source (e.g., a non RVL data-source, wherein RVL or Relational View Language is a self-contained query language where RVL uses information in the schema to automatically aggregate data when columns are projected) with just a single cube definition file. For example, the cube definition file may be a cube_definition configuration file. In some implementations, this is a cube definition file for creation of an OLAP cube in "RVL_LESS" mode. The RVL_LESS mode may be hidden from the end user.

An operation <NUM> includes accessing a data-source. The data-source may not use relational view language. In some implementations, the data-source (e.g., data catalog <NUM>) may index every OLAP cube where it can be searched and discovered. In some implementations, cube definition may be stored in the data-source where it is discoverable. In some implementations, the data-source can be used to modify a cube definition file and can validate a query against the modified query. In some implementations, were the OLAP cubes are indexed in the data-source, the data-source allows access to the index and may allow syncing for discovery.

An operation <NUM> includes generating a data-source property configuration for the data-source using the cube definition file. A data-source property configuration may comprise a list of data sources and keys, attributes, and/or measures contained respectively within.

An operation <NUM> includes determining each of respective parsed data from the data-source is a key, attribute, or measure. In some implementations, it is automatically determined if columns of relational data-sources are a key, an attribute, or a measure. Measure may be inferred from a default aggregation function in the cube definition. In some implementations, the user may be able to specify the overlay to indicate the key columns and other information. In some implementations, an overlay schema is provided to the user to allow the user to specify whether a column is a key or attribute. A key is a key attribute. In some implementations, each dimension in an OLAP cube contains a key attribute and the key attribute is the attribute in a dimension that identifies the columns in the dimension main table that are used in foreign key relationships to the fact table. The key attribute can represent the primary key column or column in the dimension table. A measure can be an aggregation of numeric data values. They can be a static element created at design time, or a calculated member based on other measures in the data structure by being summed, averaged, or otherwise mathematically manipulated. Attributes can be used to create foreign key relationships to dimension tables so that quantifiable data in the measure columns can be organized by the data contained in the dimension tables. Attributes can also be used to define the granularity of fact tables and corresponding measures.

An operation <NUM> includes generating the OLAP cube using the data-source property configuration and the determination of each of the respective parsed data from the data-source. In some implementations, the OLAP cube is generated using a single cube definition file using the data-source (e.g., a non RVL data-source). For example, the cube definition file may be a cube_definition configuration file. In some implementations, this is a cube definition file for creation of an OLAP cube in "RVL_LESS" mode. The RVL_LESS mode may be hidden from the end user.

<FIG> illustrates a method <NUM> for operating a query system, in accordance with one or more implementations. The operations of method <NUM> presented below are intended to be illustrative. In some implementations, method <NUM> may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method <NUM> are illustrated in <FIG> and described below is not intended to be limiting.

In some implementations, method <NUM> may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices (e.g., user devices <NUM>, database servers <NUM>, schemaless database server <NUM>, etc.) may include one or more devices executing some or all of the operations of method <NUM> in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method <NUM>.

An operation <NUM> may include receiving a query including a cube identifier. In some implementations, the cube identifier is specified in the query itself. In some implementations, the tenant can create the cube definition file specified in the cube associated with the cube identifier and build a query scope schema configuration to execute the query.

An operation <NUM> includes retrieving objects from a data source associated with the cube identifier. The objects include cube definition files retrieved from the data source (e.g., data catalog <NUM>).

An operation <NUM> includes determining if an associated cached cube definition file is accessible. Cube definition file caching includes storing a cube definition file to use if a query is received again over the same cube instead of recreating the cube definition file every time. A cube definition file prefetcher may scan for changes in OLAP cubes in a data source (e.g., data catalog <NUM>).

An operation <NUM> includes generating a cube definition file based on the query using the cached cube definition file. An operation <NUM> includes generating a cube definition file based on the query. In some implementations, the cube definition file is generated without using a cached cube definition file. The cube definition file may be a star schema. In some implementations, the cube definition file comprises dimensions and their attributes, simple measures and user-defined measures, mapping to columns form data sources, and prohibition rules (i.e., combinations of dimensions and measures that cannot be requested together). In some implementations, a public cube definition file may be generated from a checked-in cube definition file. The generation may include removing some details (e.g., data source mappings) that should not be visible to query users and adding data types from data sources.

An operation <NUM> may include responding to the query based on the generated cube definition file and retrieved objects from the data source.

The various aspects of the subject matter described in this specification and all of the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them.

Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few.

Claim 1:
A system configured for generating an online analytical processing (OLAP) cube, the system comprising:
one or more processors configured by machine-readable instructions to:
receive a query comprising a cube identifier;
receive a cube definition file from a data source associated with the cube identifier;
access and parse data of the data-source;
automatically generate, responsive to receiving the query with the cube identifier, a data-source property configuration for the data-source using the cube definition file;
automatically determine if each of respective parsed data from the data-source is a key, attribute, or measure;
generate the OLAP cube by combining the cube definition file and the data-source property configuration for the parsed data from the data-source determined to be a key, attribute or measure;
generate an OLAP context container based on the cube identifier provided in the query by determining if a cached OLAP context container associated with the cube identifier is accessible; and
respond to the query based on the generated OLAP context container and retrieved objects from the data source.