Systems and methods for dependency analysis in multidimensional database environments

Abstract

To provide a system and a method for dependency analysis in a multidimensional database environment.SOLUTION: A multidimensional database environment comprises a computer including one or more microprocessors and a multidimensional database server that operates in the computer. The multidimensional database server supports at least one multidimensional cube, and a multidimensional database is provided with multiple dimensions. Each of the multiple dimensions is provided with multiple members and dynamic members. A dynamic member is dependent on one pair of multiple members, and dependency analysis is executed for determining the one pair of multiple members on which the dynamic member is dependent.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] Copyright Notice A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to anyone copying or reproducing the patent document or patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.

[0002] Priority claims This application claims the benefit of priority to U.S. patent application Ser. No. 16 / 439,532, filed June 12, 2019, entitled "SYSTEM AND METHOD FOR DEPENDENCY ANALYSIS IN A MULTIDIMENSIONAL DATABASE ENVIRONMENT," and to Indian patent application Ser. No. 201841039503, filed October 18, 2018, entitled "SYSTEM AND METHOD FOR DEPENDENCY ANALYSIS IN A MULTIDIMENSIONAL DATABASE ENVIRONMENT," both of which are incorporated herein by reference.

[0003] Field of the invention: FIELD OF THE INVENTION Embodiments of the present invention relate generally to databases and data warehousing, and more particularly to a system and method for dependency analysis in a multidimensional database environment. [Background technology]

[0004] background: Multidimensional database computing environments enable enterprises to deliver critical business information to the right people when they need it, including the ability to leverage and integrate data from multiple existing data sources and deliver filtered information to end-user communities in a format that best suits their needs. Users can interact with and utilize data in real time and along familiar business dimensions, enabling speed-of-thought analytics. These are some examples of the types of environments in which embodiments of the present invention can be used. Summary of the Invention [Means for solving the problem]

[0005] overview: According to an embodiment, a system and method for dependency analysis in a multidimensional database are described herein. A dynamic member may depend on other members (called formula dependents) from the same outline, and of course, these dependents must first be calculated to evaluate the original formula at each intersection. Therefore, to evaluate a dynamic member's formula in a hybrid data aggregation model, the system may first prepare a list of all members on which the formula depends. Furthermore, the list of dynamic member dependents may be classified as "runtime dependents" and "static dependents." A dynamic member's runtime dependents are dependents that are different for each intersection, whereas static dependents are dependents that remain constant regardless of the intersection. This analysis process of identifying a dynamic member's runtime dependents and static dependents is referred to as dependency analysis in a hybrid data aggregation model.

[0006] According to an embodiment, an exemplary method for dependency analysis in a multidimensional database can include providing a computer including one or more microprocessors with a multidimensional database server operating on the computer, the multidimensional database server supporting at least one multidimensional cube, the multidimensional database having a plurality of dimensions, each of the plurality of dimensions having a plurality of members, the method can further include providing a dynamic member on the computer including one or more microprocessors, the dynamic member being dependent on a set of the plurality of members, and the method can further perform a dependency analysis to determine the set of the plurality of members on which the dynamic member is dependent.

[0007] According to an embodiment, performing the dependency analysis may comprise tokenizing the dynamic member to generate one or more tokens for the dynamic member. The dependency analysis may then analyze each of the one or more tokens for the dynamic member and determine, based on the analysis of each of the one or more tokens for the dynamic member, that the dynamic member depends only on static dependencies. In such a case, the method may fetch and transfer to the input odometer all static dependencies on which the dynamic member depends, based on the determination that the dynamic member depends only on static dependencies.

[0008] According to an embodiment, performing the dependency analysis may include tokenizing the dynamic member to generate one or more tokens for the dynamic member. The dependency analysis may then analyze each of the one or more tokens for the dynamic member and determine that the dynamic member depends on one or more runtime dependencies based on the analysis of each of the one or more tokens for the dynamic member. The method may then generate an array of the one or more runtime dependencies based on the determination that the dynamic member depends on one or more runtime dependencies. The method may also generate a list of runtime dependency members for the multidimensional database cube based on the generated array of the one or more runtime dependencies. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an example of a multidimensional database environment, according to an embodiment. [Figure 2] FIG. 1 illustrates the use of a multidimensional database in conjunction with dynamic flow, according to one embodiment. [Figure 3] FIG. 10 further illustrates the use of a multidimensional database in conjunction with dynamic flow, according to an embodiment. [Figure 4] FIG. 2 illustrates an exemplary function stack according to an embodiment. [Figure 5] FIG. 1 illustrates an exemplary data set, according to an embodiment. [Figure 6] FIG. 1 illustrates an exemplary data set, according to an embodiment. [Figure 7] 1 is a flowchart of an exemplary method for dependency analysis according to an embodiment. [Figure 8] 1 is a flowchart of an exemplary method for dependency analysis according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Detailed Description: The above, together with other features, will become apparent upon reference to the enclosed specification, claims, and drawings. Specific details are set forth to provide an understanding of various embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The enclosed specification and drawings are not intended to be limiting. do not have.

[0011] Multidimensional database environments, one example of which includes Oracle Essbase, can be used to integrate large amounts of data, potentially from multiple data sources, and deliver filtered information to end users in a manner that meets their specific needs.

[0012] FIG. 1 is a diagram illustrating an example multidimensional database environment 100 according to one embodiment. As shown in FIG. 1, according to one embodiment, a multidimensional database environment operating as a database tier may include one or more multidimensional database server systems 102, each of which may include physical computer resources or components 104 (e.g., microprocessors / CPUs, physical memory, network components), an operating system 106, and one or more multidimensional database servers 110 (e.g., Essbase servers).

[0013] According to an embodiment, middle tier 120 may include one or more services, such as, for example, provider services 122 (e.g., Hyperion provider services), administration services 124 (e.g., Essbase administration services), or studio / integration services 126 (e.g., Essbase studio / Essbase integration services). The middle tier can provide access to a metadata catalog 129 and / or one or more data sources 130 (e.g., relational databases) via ODBC / JDBC 127, 128 or other types of interfaces for use with a multidimensional database environment.

[0014] According to one embodiment, the one or more data sources are also accessible by one or more multidimensional database servers via ODBC / JDBC132 or other types of interfaces for use in providing a multidimensional database.

[0015] According to an embodiment, client tier 140 may include one or more multidimensional database clients 142 (e.g., Essbase Server clients) that enable access to the multidimensional database (e.g., SmartView, Spreadsheet Add-In, SmartSearch, Administration Services, MaxL, XMLA, CAPI or VB API applications, Oracle Business Intelligence Enterprise Edition Plus, or other types of multidimensional database clients). The client tier may also include consoles for use with services in the middle tier, such as Administration Services Console 144 or Studio / Integration Services Console 146.

[0016] According to one embodiment, communication between the client tier, middle tier, and database tier may be provided by one or more of TCP / IP, HTTP, or other types of network communication protocols.

[0017] According to an embodiment, the multidimensional database server can integrate data from one or more data sources to provide a multidimensional database, data structure, or cube 150, which can then be accessed to provide filtered information to an end user.

[0018] Typically, each data value in a multidimensional database is stored in one cell of the cube, and a particular data value can be referenced by specifying its coordinate along a dimension of the cube. The intersection of a member from one dimension with a member from each of one or more other dimensions represents a data value.

[0019] For example, as shown in FIG. 1, which illustrates a cube 162 that may be used in a sales-oriented business application, if a query refers to "Sales Amount," the system may interpret the query as a slice or layer of data values ​​164 in the database that includes all "Sales Amount" data values, intersected with "Actual" and "Budget." To reference a particular data value 166 in the multidimensional database, the query may specify a member on each dimension, for example, by specifying "Sales Amount, Actual, January." Different slices of the database provide different perspectives of the data. For example, a slice 168 of the "February" data values ​​considers all of those data values ​​whose time dimension is anchored at "February."

[0020] Database Outline According to one embodiment, development of a multidimensional database begins with the creation of a database outline, which defines the structural relationships between members in the database, organizes the data in the database, and defines links and mathematical relationships. Within the hierarchical tree or data structure of the database outline, each dimension comprises one or more members, which may in turn comprise other members. The specification of a dimension instructs the system how to link the values ​​of its individual members. A link is a group of members within a branch of the tree.

[0021] Dimensions and Members According to one embodiment, a dimension represents the highest level of consolidation in a database outline. Standard dimensions may be selected to represent components of a business plan related to departmental functions (e.g., time, account, product line, market, division). Attribute dimensions associated with standard dimensions allow users to group and analyze members of the standard dimensions based on member attributes or characteristics. Members (e.g., Product A, Product B, Product C) are the individual components of a dimension.

[0022] Dimensions and Member Relationships According to one embodiment, a multidimensional database uses family terminology (parent, child, sibling, descendant and ancestor) and hierarchical terminology (generations and levels, root and leaf) to describe the roles and relationships of members within the database outline.

[0023] According to one embodiment, a parent is a member that has branches below it. For example, "Margin" may be the parent of "Revenue" and "Cost of Goods Sold" (COGS). A child is a member that has a parent above it. In the above example, "Revenue" and "Cost of Goods Sold" are children of the parent "Margin." Siblings are children within the same generation and of the same direct parent.

[0024] According to one embodiment, descendants are members in a branch below a parent. For example, "Profit," "Inventory," and "Ratio" may be descendants of a measure, in which case the children of "Profit," "Inventory," and "Ratio" are also descendants of the measure. Ancestors are members in a branch above a member. In the above example, "Margin," "Profit," and the measure may be ancestors of "Sales."

[0025] According to one embodiment, a root is the highest member in a branch. For example, a measure may be the root of "Profit", "Inventory", and "Ratio", and therefore the root of the children of "Profit", "Inventory", and "Ratio". Leaf (level 0) members have no children. For example, beginning "Inventory", additions, and ending "Inventory" are leaf members. It may also be a bar.

[0026] According to one embodiment, a generation refers to a concatenated level within a dimension. The root branch of the tree is considered to be "generation 1," with generation numbers increasing from the root toward the leaf members. A level refers to a branch within a dimension, numbered in the reverse order of the numbers used in generations, with level numbers decreasing from the leaf members toward the root.

[0027] According to one embodiment, a user can assign a name to a generation or level and use that name as shorthand for all members within that generation or level.

[0028] Sparse and dense dimensions Data sets in multidimensional databases often share two characteristics: the data is not smoothly and uniformly distributed, and data does not exist for most of the member combinations.

[0029] To address this, according to one embodiment, the system can recognize two types of standard dimensions: sparse dimensions and dense dimensions. A sparse dimension is one in which the available data positions are filled at a relatively low rate, while a dense dimension is one in which there is a relatively high probability that one or more cells in any combination of dimensions will be occupied. Many multidimensional databases are inherently sparse in that they lack data values ​​for a large proportion of member combinations.

[0030] Data Block and Index System According to one embodiment, a multidimensional database uses data blocks and indexes to store and access data. The system can create a multidimensional array or data block for each unique combination of members of sparse standard dimensions, with each data block representing the dense dimension members for that combination of members of sparse dimensions. An index is created for each data block, the index representing the combination of members of the sparse standard dimensions and including an entry or pointer for each unique combination of members of the sparse standard dimensions for which at least one data value exists.

[0031] According to one embodiment, when a multidimensional database server searches for a data value, it can use a pointer provided by the index to locate the appropriate data block and, within that data block, to locate the cell containing the data value.

[0032] Managed Services According to one embodiment, an administration service (eg, Essbase Administration Services) provides a single point of access that enables users to design, develop, maintain, and manage servers, applications, and databases.

[0033] studio According to one embodiment, a studio (eg, Essbase Studio) provides a wizard-driven user interface for performing tasks related to data modeling, cube design, and analytical application construction.

[0034] Spreadsheet Add-in According to one embodiment, a spreadsheet add-in integrates multidimensional databases with spreadsheets to support advanced commands such as connect, pivot, drill-down and calculate.

[0035] Integration Services According to one embodiment, integration services (e.g., Essbase Integration Services) provide a metadata-driven environment for use in integrating data stored in multidimensional databases and data stored in relational databases.

[0036] Provider Services According to one embodiment, a provider service (eg, Hyperion Provider Service) acts as a data source provider for Java API, Smart View, and XMLA clients.

[0037] Smart View According to one embodiment, SmartView provides a common interface for, for example, Hyperion Financial Management, Hyperion Planning, and Hyperion Enterprise Performance Management Workspace data.

[0038] Developer Products According to one embodiment, the developer product enables the rapid creation, management and implementation of customized enterprise analytical applications.

[0039] Lifecycle Management According to one embodiment, lifecycle management (e.g., Hyperion Enterprise Performance Management System Lifecycle Management) provides a means for enterprise performance management products to enable applications, repositories, or individual artifacts to move across product environments.

[0040] OLAP According to one embodiment, online analytical processing (OLAP) provides an environment that allows users to analyze enterprise data. For example, finance departments can use OLAP for applications such as budgeting, activity-based costing, financial performance analysis, and financial modeling to provide "just-in-time" information.

[0041] According to one embodiment, an OLAP system can organize data in multiple dimensions, allowing a searcher / user of a dataset to perform a directed search across various dimensions to ultimately arrive at the desired results. An OLAP system can view data as residing at the intersection of dimensions. In other words, the data underlying an OLAP system can be organized and stored as a multidimensional database that instantiates the cross-product of all dimensions. This allows a user / searcher to traverse hierarchies of detail along the desired dimensions in an ad hoc manner to arrive at specific data of interest. Slowly changing data can be represented as metadata within the current dataset.

[0042] Hybrid Multidimensional Database According to one embodiment, the system supports the use of dynamic flow (referred to herein in some examples as query processing dynamic flow (QPDF)) in a multidimensional database (e.g., Essbase) computing environment. This dynamic flow process enables hybrid use of, for example, aggregate storage option (ASO), block storage option (BSO), or other types of storage containers; It provides a general flow for processing received input queries in a bottom-up mode. This approach can be used to reduce the size of the cube and provides efficient calculation of dynamic members.

[0043] For example, according to one embodiment, for queries that access sparse dynamic members, the system can satisfy the request using an aggregate storage engine. For queries that cannot be processed by the aggregate storage engine, the system can utilize a block storage engine to satisfy the request, which may include, for example, bringing the data into an aggregate storage temporary tablespace.

[0044] For example, according to one embodiment, a dynamic flow, when executed by a computer system, can operate on a multidimensional database to (1) expand an input query to determine all basic / computational data, (2) analyze the expanded query to determine dependencies and computation order, (3) define computational units according to the preceding steps, (4) construct a processing flow using the defined computational units and connect them, and (5) execute the processing flow to determine a response to the input query.

[0045] FIG. 2 is a diagram illustrating the use of a multidimensional database in conjunction with dynamic flows, according to one embodiment.

[0046] In a typical multidimensional environment, to prepare the system to respond to incoming queries, the database server pre-calculates values ​​for particular dimensions and stores those pre-calculated values ​​in a cube for subsequent lookup.

[0047] According to one embodiment, if dynamic flow is used instead, the ability to support dynamic query processing allows the database server to avoid pre-computing and storing such values, thereby improving performance and reducing storage of potentially empty cells.

[0048] As shown in FIG. 2 , according to an embodiment, the system may include one or more query processors 200, such as a multidimensional expressions (MDX) query processor 202 and / or a spreadsheet extractor (SSE) 204 query processor, that enable receiving 206 input queries 208 from clients to retrieve, access, or examine a set of data (provided by and made accessible through the multidimensional database) from a data source.

[0049] According to one embodiment, the preprocessor component 210 may include a data acquisition layer 212 or data fetch component (which in some environments may incorporate a kernel-based odometer retriever, or a memory-stored odometer or data structure that manages pointers to data blocks, contains control information, or serves as one of multiple arrays of pointers to stored members), an aggregator component 214, and a calculator component 216, each of which may be provided as software or program code executable by a computer system.

[0050] Generally, according to one embodiment, a preprocessor receives input queries from one or more query processors for processing against a multidimensional database (218). An aggregator is adapted to perform hierarchical aggregation of data. A calculator is , adapted to perform calculations on the data, and to utilize the data acquisition layer (including an odometer, as appropriate) in cooperation with the aggregator as further described below for at least one of input and / or search within the cube, and to process responses to input queries.

[0051] According to an embodiment, the system may include one or more storage containers 220, such as one or more aggregate storage options (ASOs) 222, block storage options (BSOs) 224, or other types of storage containers 226, each of which may act as an interface between data 230 read from and written to a data source or multidimensional database, whichever data is required for aggregation and calculation in the preprocessor.

[0052] FIG. 3 is a diagram further illustrating the use of a multidimensional database in conjunction with dynamic flows, according to one embodiment.

[0053] As shown in FIG. 3, according to one embodiment, in response to the database server receiving an input query, the aggregator can operate in conjunction with a calculator (240, 242) to process the query as part of a dynamic flow 244, which can also be provided as software or program code executable by a computer system.

[0054] For example, as shown in FIG. 3, the dynamic flow process, in this example, allows for the hybrid use of one or more ASO, BSO, or other types of storage containers and provides a general flow for processing queries in a bottom-up mode using these storage containers.

[0055] According to one embodiment, when the system begins to process an input query, it first determines what particular data or other information, i.e., metadata, needs to be retrieved by examining the input query. The system can then define 246 an initial computation unit 250 for the input query, which encapsulates an aggregation / computation process that retrieves a set of data from a storage container.

[0056] According to one embodiment, for use by the computing units, a data buffer 260 (referred to herein in some examples as one or more output buckets) operates as a data structure to which each computing unit can read / write data (252) and to which data received (254) from a storage container can be temporarily stored.

[0057] According to one embodiment, when dynamic flow is used with a BSO type storage container, the dynamic flow process performs a pre-analysis of the input query and expansion of the requested points to their underlying data.

[0058] However, the amount of such expanded basic data would be quite large. To address this and reduce the amount of expanded data, in accordance with one embodiment, a first dynamic aggregation can be performed while fetching data from the kernel without significant expansion of the associated kernel structures (e.g., the kernel-side odometer described above).

[0059] According to one embodiment, the dynamic flow then operates to expand the input query, determine all base / calculation data, and analyze the expanded query to determine dependencies and calculation order. Make.

[0060] Dependency Analysis According to an embodiment, a multidimensional database (e.g., Essbase) may have "m" dimensions, each dimension having "n" members, and each member of a dimension may be stored with a loaded input value or a dynamic member, whose value is calculated during actual retrieval at run time when the dynamic member is requested in a query. The dimension members are hierarchical in nature. The cardinality of a dimension may be the total number of dimension members, and each combination constructed between all the dimension members represents an intersection point in the multidimensional database cube. Each cube may have a stored or calculated value associated with it, and each coordinate of the combination represents meaning (e.g., extracted information such as business meaning) for the intersection point value.

[0061] According to one embodiment, dynamic members of a multidimensional database may comprise members with valid formulas or temporary members (created per request via a language associated with or capable of communicating with the multidimensional database cube, such as MDX in Essbase). Such formulas may be simple arithmetic expressions or complex expressions involving complex conditional calculations of values ​​resulting from the calculations of other members from the same outline on which this member depends. Thus, the formula of such a dynamic member represents its value and is evaluated for each intersection.

[0062] According to one embodiment, a dynamic member may depend on other members (called formula dependents) from the same outline, and of course, these dependents must first be calculated to evaluate the original formula at each intersection. Therefore, to evaluate a dynamic member's formula in a hybrid data aggregation model (e.g., "Hybrid Essbase" (bottom-up)), the system may first prepare a list of all members on which the formula depends. Furthermore, the list of dynamic member's dependents may be categorized as "runtime dependents" and "static dependents." A dynamic member's runtime dependents are those that are different for each intersection, whereas static dependents are those that remain constant regardless of the intersection. This analysis process of identifying a dynamic member's runtime dependents and static dependents is referred to as "dependency analysis" in a hybrid data aggregation model.

[0063] According to one embodiment, hybrid aggregation for block storage databases is an aggregation model in which block storage data calculations are performed with efficiency similar to that of aggregate storage databases. Hybrid aggregation provides the advantage of fast performance by eliminating sparse aggregations, reducing size and memory footprint, and accelerating batch routines. Implementation considerations are simplified because users no longer have to worry about whether to use block storage for frequent level-0 calculations, aggregate storage for many higher-level aggregations, or design a partitioned model in which cubes are split along dimensional lines to promote calculation performance. Block storage databases must store large sparse dimensions, and making them dynamic results in excessive block I / O during queries, impacting performance. Storing very large sparse dimensions can result in long batch aggregation times and large database sizes related to the number and size of these sparse dimensions. Despite these drawbacks, block storage is widely used due to its powerful features. Aggregate storage is designed to enable large databases with more and larger dimensions. Unlike block storage, it does not require pre-aggregation of large sparse dimensions to achieve good query performance. Fast dynamic aggregation across large dimensions The key is an aggregate storage engine that facilitates this. Hybrids utilize ASO calculation engines when possible and switch to BSO calculation engines when necessary.

[0064] According to one embodiment, dependency analysis can form part of a hybrid flow in a multidimensional database environment that allows a user to evaluate dynamic members in a bottom-up approach by identifying all necessary dependent elements before the actual evaluation begins. The dependency analysis described herein improves performance by eliminating redundant and outdated recursive top-down trips.

[0065] According to one embodiment, a dependency analysis is performed for each dynamic (or transient) member to collect a list of runtime and static dependencies in both BSO (Block Storage Option) and ASO (Aggregate Storage Option) cubes, allowing the member to participate in a hybrid flow for execution in a bottom-up approach.

[0066] In the following example, consider a dynamic member with the sample formula shown below, which illustrates an exemplary dynamic member according to an embodiment: The italicized text between the lines explains the function in the line above.

[0067]

number

[0068] According to one embodiment, following the dynamic members described above, two main steps are taken for dependency analysis: In the first step, dependency analysis is performed based on the dynamic members during server startup; in the second step, the results of the first step are used to fetch the actual dependent elements.

[0069] First step - perform dependency analysis while the server is starting According to one embodiment, the first step is to discover the list of runtime dependent element dimensions and dependency patterns present in the dynamic expression. This logic is executed during server startup and therefore does not contribute to the MDX query turnaround time during actual retrieval.

[0070] According to one embodiment, during cube loading (e.g., server startup), the systems and methods herein can read the entire cube outline, i.e., member by member, examining the formulas for each member and collecting dependencies for each member. All of this dependency information is collected during server startup. Because all of the dependency information is static, this collection step does not rely on user queries. This dependency mapping can then be stored and invoked when a query on a dynamic member is invoked.

[0071] According to one embodiment, the input of the first step of dependency analysis is to break down the dynamic expression into a list of tokenized strings.

[0072] According to one embodiment, the output of such a step is at least twofold. The first output is an array of dimensions along which the dynamic formula has "run-time" dependencies. Looking at the dynamic member example above, the run-time dependency dimensions are Product and Market. These dimensions generate the correct list of run-time dependent element members during the actual retrieval of this formula member at run-time based on the stored dependency mapping (e.g., those dimensions, whether static or run-time, form the dependency mapping for Product and Market, the dependency dimensions in the example above).

[0073] According to one embodiment, the second output is the detection of patterns present in the formula, which indicates whether the list of "context" dependent dimensions used by the formula in its "IF" (conditional logic / conditional statement) conditions is different or the same as that used in the body part of each "IF" in the formula. This pattern detection becomes more complex as the IF-ELSE nesting in the formula increases.

[0074] According to one embodiment, in the following examples, the term cube / database may refer to an actual server or cube or database with multiple dimensions, where the members of each dimension are hierarchical and can be represented in an outline or tree view. Similarly, the term MDX may refer to Multidimensional Expressions (MDX), which is used in multidimensional databases. Also, the term top-down or runtime-dependent element function may refer to a function that depends on the actual query, and whose resulting value is evaluated in the context of the actual running query. There may be some top-down functions, such as @PARENT, @CURRMBR, etc.

[0075] According to one embodiment, in the above example, the high-level output from the first stage would consist of a list of dimensions on which the dynamic member is dependent, a determination of whether an IF ELSE pattern is present, and a list of dimensions that only the runtime dependency function uses in the "IF" condition. In the high-level output, the list of dimensions on which the above example is dependent includes Market, Product. In this example, an IF ELSE pattern is present, and the list of dimensions used in the "IF" condition includes Market, Location.

[0076] According to one embodiment, a first stage of dependency analysis may be provided such that a measure of the state of the stacks (i.e., function stack and argument stack) is created for each query. These stacks may be based on each call chain in the query.

[0077] According to one embodiment, as described above, the input for dependency analysis may be a query expression that is broken down into a tokenized list, so that the system and method can declare all necessary variables used internally and sort them into their respective stacks.

[0078] According to one embodiment, the following pseudocode represents the primary steps taken in dependency analysis.

[0079]

number

[0080] The above pseudocode can now be written in example form. In the following example, Referring to FIG. 4, which shows an exemplary function stack according to an embodiment, the following outline formula can be used:

[0081]

number

[0082] According to one embodiment, as shown in the figure, there are three individual function stacks resulting from the above equation. The first function stack 410 comprises function A(@WeightedSumX) 401 and function B(@RANGE) 402. This represents the end of the first function call chain, and the remaining values ​​in this call chain, "Entered Delta" and USD:ZAR, are arguments that will be placed on the argument stack.

[0083] According to one embodiment, the second function stack 420 comprises function A (@WeightedSumX), function C (@CONCATENATE) 403, function D (@NAME) 404, and function E (@CURRMBR) 405. This represents the end of the second function call chain, and the remaining values ​​in this call chain, "Rate_" and Currency, are arguments that will be placed on the argument stack.

[0084] According to one embodiment, the third function stack 430 comprises the function F(@PRIOR) 406. This represents the end of the third function call chain, and the remaining value in this call chain, "Reporting," is an argument that will be placed on the argument stack.

[0085] According to one embodiment, each call chain in the above example can be analyzed and the runtime dimensions can be pointed out. In the above example, the runtime dimensions are Currency and Reporting.

[0086] According to one embodiment, the above example does not include any IF-ELSE patterns.

[0087] Second stage: Use the output of the first stage to fetch the actual dependencies According to one embodiment, once the first phase is executed (note that the first phase can be executed once in the cube's lifetime, during server startup when it is loaded for the first time), a second phase can begin. The second phase described below, used to fetch actual runtime dependencies, is specific and dependent on the retrieval request (e.g., MDX query). Thus, the logic for the actual fetching of dependent elements is executed for each retrieval request (i.e., during actual query runtime). The information collected in the first phase of dependency analysis is used to discover and collect query runtime dependent elements.

[0088] According to one embodiment, in the second stage, the system and method takes as its input the query odometer and the list of runtime dependencies (obtained from the first stage).

[0089] According to one embodiment, the system and method then constructs member combinations (or intersections) from the odometers of only the runtime dependent element dimensions detected in the first stage.

[0090] According to an embodiment, the system and method includes, for each intersection, determining the internal properties of the dynamic member. The recompiled program is executed to fetch the unique and distinct dependent element members for each intersection. The system and method can then accumulate all the resulting dependent elements for each intersection as output and place it in the query's extended odometer. This step evaluates the program only for metadata via the stack machine. The multidimensional database already knows how to execute the expression program for value retrieval. However, the system and method allows the same expression to be executed to fetch only the dependent element members by skipping the value retrieval.

[0091] According to one embodiment, consider the following dynamic member: In this example, the dynamic member would be named "Test."

[0092]

number

[0093] FIG. 5 is a diagram illustrating an exemplary data set, according to one embodiment. In FIG. 5, several dimensions are shown, such as market 500, location 510, product 520, and sales 530.

[0094] For purposes of one embodiment and the following example, assume that a user sends the following request to retrieve an MDX query:

[0095]

number

[0096] According to one embodiment, [TPDNTest.TPDNTest] may comprise an internal cube created for testing purposes. Executing the dynamic member "Test" results in the dataset shown in FIG.

[0097] According to one embodiment, considering the dynamic member "Test", the first stage (dependency analysis) returned Market and Product dimensions as runtime dependency dimensions. "Test" also has an IF-ELSE pattern. This information, along with the input Odometer, is taken as input by the second stage to fetch the actual runtime dependency elements. Therefore, the newly derived dependency element as the output of the second stage is Sales Amount in the Measures dimension. Also, the Product dimension has four members: Cola, Root Beer, There are cream sodas and fruit sodas.

[0098] According to one embodiment, the outputs may comprise: a first output is an array of dimensions on which this formula has "run-time" dependencies, i.e., two dimensions, Product and Market, in the above example, which can generate an accurate list of run-time dependent element members during the actual retrieval of this formula members at run-time.

[0099] According to one embodiment, the next output is the detection of a pattern present in the expression that indicates that the list of dependency dimensions used by the expression in the "IF" conditions is different from or does not result from the one used in the body of each "IF" in the expression. This pattern detection becomes more complex as IF-ELSE nesting increases in the expression, and is a crucial part of dependency analysis to accurately fetch the dependent element members for each intersection at runtime.

[0100] According to one embodiment, the steps of the second phase are outlined as follows: According to one embodiment, the second stage can form all mathematical combinations among all members of the runtime dependency dimensions (market and product) from the input odometer and execute the program for each combination to fetch the dependency.

[0101] According to one embodiment, the input odometer members from the market and product are as follows:

[0102]

number

[0103] According to one embodiment, the full combination is as shown below:

[0104]

number

[0105] According to one embodiment, the second step then performs a search on this list of all combinations. For each combination, the expression of the member "Test" can be evaluated to fetch the dependent element members. A second step can add these members as dependent elements to the extended odometer of measures, markets, and products, respectively.

[0106]

number

[0107] According to one embodiment, dependencies are collected for metadata once for the input odometer by the executed formula, and the logic repeats the same process of building combinations and running the same program to discover more dependencies, this time building combinations only among newly added members of the runtime dependency dimension.

[0108] According to one embodiment, further, to evaluate an expression for a particular combination, a precompiled executable program of the expression, along with the input combination, can be fed into a stack machine framework that knows how to evaluate the program. The stack machine, being an existing work, knows to evaluate an expression for its value, but not just to fetch dependency metadata. Therefore, the stack machine is enhanced with a feature that allows the stack machine to take the program of the expression along with the combination as its input, and execute this program just to fetch metadata as dependencies, without invoking the value calculation part of the expression. This mode of the stack machine in which the program is executed just to fetch dependencies is called the "metadata" mode.

[0109] According to one embodiment, the second stage of the process can be performed in a temporary container that can hold the discovered dependent element members. This structure can be used to form a dynamically expandable list of members and can hold any object created in the multidimensional database.

[0110] FIG. 7 is a flowchart of an exemplary method for dependency analysis, according to an embodiment.

[0111] According to one embodiment, in step 701, the method can receive input parameters, which include dynamic members and odometers containing user acquisition requests.

[0112] According to one embodiment, in step 702, the method checks whether the dynamic members are static and have no runtime dependencies. If so, in step 703, the method passes the expression program to a stack machine with a default combination. The method runs the program once with the default combination to fetch all static dependencies. The method then transfers all these dependencies from the temporary container to the odometer.

[0113] According to one embodiment, in step 704, the method checks whether the dynamic member has a runtime dependency and whether there is an IF-ELSE pattern in the expression of the dynamic member. If so, in step 705, the method checks whether the dynamic member has a runtime dependency and whether there is an IF-ELSE pattern in the expression of the dynamic member. Obtain a list of dependent element dimensions. The method iterates over the input odometers of the runtime dependent element dimensions. For each combination (total number = multiplied by the size of each odometer) of members from the odometers of the runtime dependent element dimensions, the method passes the current formula program and the current combination to the stack machine for program execution, and while executing the program only for metadata, the method excludes all value calculation parts from the program and executes only metadata instructions, and the method stores the dependent elements obtained from this execution of the program for the current cmi in a temporary container.

[0114] According to one embodiment, at this point the program has been run through all possible combinations and all resulting dependencies are in a temporary container, which we then iterate over.

[0115] According to one embodiment, in step 706, for each member in the temporary container, the method adds a dependent element member to the query's extended odometer.

[0116] According to one embodiment, in step 707, the method does not require all combinations. Instead, the method selects a smaller number of combinations, and each vertical axis appears only once in all combinations. In this case, the total number of combinations is equal to the maximum size of each odometer of the runtime dependency element. For each combination of members from the odometer of the runtime dependency element dimension (total number = maximum size of each odometer), the method passes the current formula program and the current combination to the stack machine for program execution. While executing the program only for metadata, the method excludes all value calculation parts from the program and executes only metadata instructions. Then, the method stores the dependency elements obtained from this execution of the program for the current cmi in a temporary container.

[0117] According to one embodiment, at this point the program has been run through all possible combinations and all resulting dependencies are present in a temporary container over which the method iterates.

[0118] According to one embodiment, for each member in the temporary container, the method adds dependent element members to the query's extended odometer.

[0119] According to one embodiment, all dynamic members are expanded, i.e., all necessary dependencies of each dynamic member are recognized and added to the expanded odometer of the query, which is then carried forward by a hybrid flow in a multidimensional database environment to obtain the complete odometer in a bottom-up approach and return the appropriate results to the user.

[0120] FIG. 8 illustrates an exemplary method for dependency analysis in a multidimensional database.

[0121] In step 810, the method can include providing a computer including one or more microprocessors with a multidimensional database server running on the computer, the multidimensional database server supporting at least one multidimensional cube, the multidimensional database having a plurality of dimensions, each of the plurality of dimensions having a plurality of members and a dynamic member, the dynamic member being dependent on a set of the plurality of members.

[0122] In step 820, the method may perform a dependency analysis to determine a set of members on which the dynamic member depends.

[0123] While various embodiments of the present invention have been described above, it should be understood that they are presented by way of example, not limitation. These embodiments have been selected and described in order to explain the principles of the invention and its practical application. These embodiments illustrate systems and methods in which the present invention may be utilized to enhance the performance of the systems and methods by providing new and / or improved features and / or by providing benefits such as reduced resource utilization, increased capacity, improved efficiency, and reduced latency.

[0124] In some embodiments, features of the present invention are implemented in whole or in part in a computer that includes a processor, a storage medium such as memory, and a network card for communicating with other computers. In some embodiments, features of the present invention are implemented in a distributed computing environment in which one or more clusters of computers are connected by a network such as a local area network (LAN), a switched fabric network (e.g., InfiniBand), or a wide area network (WAN). A distributed computing environment may have all the computers in a single location, or may have clusters of computers in various remote geographic locations connected by a WAN.

[0125] In some embodiments, features of the present invention are implemented in a cloud, as part of a cloud computing system or as a service of a cloud computing system, based in whole or in part on shared, elastic resources delivered to users in a self-service, metered manner using web technologies. There are five characteristics of a cloud (as defined by the National Institute of Standards and Technology): on-demand self-service, broad network access, shared resources, rapid scalability, and scalable services. Cloud implementation models include public, private, and hybrid. Cloud service models include Software as a Service (SaaS), Platform as a Service (PaaS), Database as a Service (DBaaS), and Infrastructure as a Service (IaaS). A cloud, as used herein, is a combination of hardware, software, network, and web technologies that delivers shared, elastic resources to users in a self-service, metered manner. Unless otherwise specified, cloud in this specification encompasses all cloud implementation models, including but not limited to public cloud embodiments, private cloud embodiments, hybrid cloud embodiments, and cloud SaaS, cloud DBaaS, cloud PaaS, and cloud IaaS.

[0126] In some embodiments, features of the present invention are implemented using or with the aid of hardware, software, firmware, or a combination thereof. In some embodiments, features of the present invention are implemented using a processor configured or programmed to perform one or more functions of the present invention. In some embodiments, the processor is a single-chip or multi-chip processor, a digital signal processor (DSP), a system-on-chip (SOC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a state machine, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In some implementations, features of the present invention may be implemented by circuitry specific to a given function. In other implementations, these features may be implemented using, for example, instructions stored on a computer-readable storage medium to perform a particular function. The method may be implemented in a processor configured to perform the method.

[0127] In some embodiments, features of the present invention are incorporated into software and / or firmware for controlling the hardware of a processing system and / or networking system and for enabling the processor and / or network to interact with other systems that utilize features of the present invention. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, virtual machines, hypervisors, application programming interfaces, programming languages, and execution environments / containers. Appropriate software coding can be readily prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software arts.

[0128] In some embodiments, the present invention includes a computer program product, which is a storage medium or computer-readable medium having instructions stored thereon that can be used to program or otherwise configure a system, such as a computer, to perform any of the processes or functions of the present invention. The storage medium or computer-readable medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives and magneto-optical disks, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data. In certain embodiments, the storage medium or computer-readable medium is a non-transitory storage medium or computer-readable medium.

[0129] The above description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Moreover, while embodiments of the present invention have been described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the invention is not limited to the described sequence of transactions and steps. Furthermore, while embodiments of the present invention have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. Furthermore, while various embodiments describe particular combinations of features of the present invention, it should be understood that different combinations of features will be apparent to those skilled in the art as being within the scope of the present invention, and that features of one embodiment can be incorporated into another embodiment. Furthermore, it will be apparent to those skilled in the art that various additions, subtractions, deletions, changes in form, detail, implementation, and application, as well as other modifications and alterations, may be made herein without departing from the spirit and scope of the present invention. The broader spirit and scope of the present invention is intended to be defined by the following claims and their equivalents.

Claims

1. 1. A system for dependency analysis in a multidimensional database, comprising: a computer including one or more microprocessors; a multidimensional database server running on the computer, wherein the multidimensional database comprises a plurality of dimensions, each of the plurality of dimensions comprising a plurality of members, and the system further comprises: a dynamic member, the dynamic member being dependent on a set of the plurality of members; A system wherein a dependency analysis is performed to determine the set of members on which the dynamic member depends, the set of members comprising at least one runtime dependency.

2. The system of claim 1 , wherein the dependency analysis is performed at startup of the multidimensional database server.

3. The dependency analysis causes the computer, including one or more microprocessors, to perform steps including: The system of claim 1 or 2, comprising the step of tokenizing the dynamic member to produce one or more tokens for the dynamic member.

4. The dependency analysis causes the computer, including one or more microprocessors, to perform steps including: determining, based on an analysis of each of the one or more tokens of the dynamic member, that the set of members on which the dynamic member depends comprises the at least one runtime dependency; generating an array of said at least one runtime dependency; and generating a list of runtime dependency element members of the multidimensional database server based on the generated array of the at least one runtime dependency element.

5. The system of claim 4 , wherein queries for the dynamic members are performed on the multidimensional database.

6. 6. The system of claim 5, wherein the query for the dynamic member utilizes the list of runtime dependency element members of the multidimensional database to fetch values ​​associated with each of the runtime dependency element members on the list of runtime dependency element members.

7. The dependency analysis causes the computer, including one or more microprocessors, to perform steps including: determining, based on the list of runtime dependency element members, at least one IF-ELSE nesting pattern for a runtime dependency element member in the list of runtime dependency element members; and adding each dependent element member of the IF-ELSE nesting pattern to an input odometer based on the determined at least one IF-ELSE nesting pattern.

8. 1. A method for dependency analysis in a multidimensional database, comprising:

1. A method comprising: providing a multidimensional database server running on a computer including one or more microprocessors, the multidimensional database comprising a plurality of dimensions, each of the plurality of dimensions comprising a plurality of members; The computer including one or more microprocessors provides a dynamic member, the dynamic member being dependent on a set of the plurality of members, the method further comprising:

10. The method of claim 9, further comprising: performing a dependency analysis to determine the set of members on which the dynamic member depends, the set of members comprising at least one runtime dependency.

9. The method of claim 8 , wherein the dependency analysis is performed during a start-up operation of the multidimensional database server.

10. A method as described in claim 8 or 9, further comprising the step of the computer tokenizing the dynamic member to generate one or more tokens for the dynamic member.

11. The method of claim 10, further comprising: determining, based on an analysis of each of the one or more tokens of the dynamic member, that the set of members on which the dynamic member depends includes the at least one runtime dependency; generating an array of the at least one runtime dependency element; 11. The method of claim 10, further comprising the step of: generating a list of runtime dependency element members of the multidimensional database server based on the generated array of the at least one runtime dependency element.

12. The method of claim 11 , wherein queries for the dynamic members are performed on the multidimensional database.

13. 13. The method of claim 12, wherein the query for the dynamic member utilizes the list of runtime dependency element members of the multidimensional database to fetch values ​​associated with each of the runtime dependency element members on the list of runtime dependency element members.

14. The method of claim 13, further comprising: determining, based on the list of runtime dependency element members, at least one IF-ELSE nesting pattern for a runtime dependency element member in the list of runtime dependency element members; 12. The method of claim 11, further comprising the step of: adding, by the computer, each dependent element member of the IF-ELSE nesting pattern to an input odometer based on the determined at least one IF-ELSE nesting pattern.

15. A program that causes a computer to execute the method according to any one of claims 8 to 14.

Images