Creating and consuming data models across multiple fact sets

Abstract

A computing device displays a first object icon representing a first object of a first data source and a second object icon representing a second object of the first data source. The first object icon is connected to the second object icon via a first connector representing a relationship between the first object and the second object. In response to receiving a first user input to add a third object, the computing device displays a third object icon representing the third object. In response to receiving a second user input on the third object icon, in accordance with a determination that the second object and the third object include at least one common data field, the computing device displays a second connector connecting the third object icon to the second object icon.

Description

[0001] Related applications

[0002] This application is a continuation-to-file of (i) U.S. Patent Application No. 18 / 424,505, filed January 26, 2024; (ii) U.S. Patent Application No. 18 / 424,592, filed January 26, 2024; and (iii) U.S. Patent Application No. 18 / 424,619, filed January 26, 2024; each of the foregoing U.S. patent applications claims priority to U.S. Provisional Patent Application No. 63 / 464,911, filed May 8, 2023. The entire contents of each of the foregoing applications are incorporated herein by reference.

[0003] This application relates to the following applications, each of which is incorporated herein by reference in its entirety:

[0004] ● (i) U.S. Patent Application No. 15 / 911,026, entitled “Using an Object Model of Heterogeneous Data to Facilitate Building Data Visualizations”, filed on March 2, 2018, now U.S. Patent No. 11,620,315, published on April 4, 2023;

[0005] ● (ii) U.S. Patent Application No. 16 / 236,612, entitled “Generating Data Visualizations According to an Object Model of Selected Data Sources”, filed on December 30, 2018, now U.S. Patent No. 11,537,276, published on December 27, 2022;

[0006] ● (iii) U.S. Patent Application No. 16 / 944,047, entitled “Analyzing Data Using Data Fields from Multiple Objects in an Object Model”, filed on July 30, 2020, now U.S. Patent No. 11,216,450, published on January 4, 2022;

[0007] ● (iv) U.S. Patent Application No. 17 / 397,913, entitled “Validating Relationships Between Classes in Object Models,” filed August 9, 2021, now U.S. Patent No. 11,520,463, published December 6, 2022; and

[0008] ● (v) U.S. Patent Application No. 17 / 307,427, filed May 4, 2021, entitled “Systems and Methods for Visualizing Object Models of Database Tables”. Technical Field

[0009] The disclosed implementations involve data visualization in general, and more specifically, systems and methods that facilitate the creation of object models and the validation of relationships between objects in the object model of a data source. Background Technology

[0010] Data visualization applications enable users to visually understand datasets, including distributions, trends, outliers, and other factors crucial for making business decisions. Some data visualization applications offer user interfaces that allow users to indirectly define data visualizations from data sources by selecting data fields and placing them in specific user interface areas. However, when complex data sources and / or multiple data sources exist, it may be unclear what type of data visualization (if any) should be generated based on user choices or how the data fields are related. Summary of the Invention

[0011] Businesses need a comprehensive understanding of their data to effectively manage their operations. Often, their data exists as "islands" of separate but related fact tables with common dimensions such as time and geography (e.g., dimension data fields or dimension fields). These tables can be combined using row-level joins. However, there exist "fact sets" (e.g., groups of related tables) that do not have row-level correspondences. For example, an organization might have a marketing department that controls marketing campaigns for products, and a sales department that is responsible for selling those products. In this case, the ability to combine data from both the marketing and sales fact tables provides a complete and accurate understanding of the effectiveness of the marketing campaigns and their impact on sales.

[0012] Currently, some data analytics applications limit analysis to the fact that they can only target a single group, restricting the questions analysts can ask and placing a maintenance burden on data administrators who must support workarounds.

[0013] Therefore, there is a need for improved methods, devices, systems, and user interfaces that enable the creation of data models (also known as "object models") spanning multiple fact tables. There is also a need for improved methods, devices, systems, and user interfaces that enable users to analyze multi-fact data models.

[0014] Generating data visualizations that combine data from multiple tables can be challenging, especially when multiple fact tables exist. In some cases, building an object model of the data before generating the visualization can be helpful. In some instances, a person is a specific expert on the data, and this person creates the object model. By storing relationships in the object model, data visualization applications can leverage information to assist all users accessing the data, even if they are not experts.

[0015] An object is a collection of named properties. Objects typically correspond to real-world objects, events, or concepts, such as a Store. Properties describe an object and are conceptually related to it in a one-to-one manner. Therefore, a Store object can have a single [Manager Name] or [Employee Count] associated with it. At the physical level, objects are typically stored as rows in a relational table or as objects in JSON.

[0016] A class is a collection of objects that share the same properties. Comparing and aggregating objects within a class must be analytically meaningful. At the physical level, classes are typically stored as relational tables or arrays of objects in JSON.

[0017] An object model is a set of classes and a set of many-to-one relationships between them. Classes related by one-to-one relationships are conceptually treated as a single class, even if they are different in meaning to the user. Furthermore, classes related by one-to-one relationships can be represented as different classes in a data visualization user interface. By adding an association table that captures the relationships, many-to-many relationships are conceptually split into two many-to-one relationships.

[0018] Once the object model is built, data visualization applications can assist users in various ways. In some implementations, based on already selected data fields placed on shelves in the user interface, the data visualization application can suggest additional fields or restrict the actions that can be taken to prevent unavailable combinations. In other implementations, the data visualization application allows users considerable freedom in selecting fields and uses the object model to build one or more data visualizations based on what the user has already selected.

[0019] Some implementations of the publicly disclosed text involve a computing device with an improved user interface that facilitates the creation of multi-fact data models. Compared to existing data models, the data models disclosed herein are displayed in a more compact manner within the user interface (see, for example...). Figure 1C The user interface facilitates the selection and disambiguation of relationships in the object model.

[0020] In some implementations, in response to user interaction with an object in the object model (e.g., hovering over it), the computing device highlights the object and traces other objects in the object model that are shared with it, thereby providing the user with improved visual feedback.

[0021] Some implementations of public text involve a computing device with an improved user interface that facilitates the analysis of multi-fact data models.

[0022] In some instances, within complex multifact data models, analysts may struggle to identify relevant fields to use together. Once they begin their analysis, analysts may easily overlook both relevant and irrelevant fields. Multiple perspectives exist on how to leverage complex data models, and these perspectives need to be adapted to the analyst's analytical workflow.

[0023] Some implementations of the publicly available text provide a simple yet informative way to guide analysts in fully utilizing multi-fact data models. In some implementations, the user interface grays out fields irrelevant to the current analysis (e.g., fields not currently used in the analysis). In others, the user interface provides subtle hints about the grayed-out fields and offers explanations of why they are irrelevant and the consequences of using them. Analysts gain enough information from the tooltips displayed in the user interface to decide whether to proceed. As analysts continue exploring the data model, the relevance of fields adapts to user input. In some implementations, the user interface saves relevant tips for already used fields and indicates whether they are relevant or irrelevant, allowing analysts to always return and refine their analysis.

[0024] Some implementations of the publicly available text involve improved query semantics to support multi-fact data model analysis. The disclosed query semantics are fully compatible with Tableau's VizQL, which provides flexible interactivity and answers complex analytical questions using an iterative approach.

[0025] The systems, methods, and apparatuses for publishing texts each have several innovative aspects, none of which are solely responsible for the desired properties.

[0026] (A1) According to some implementations, a method for generating an object model across multiple fact tables is performed at a computing device having a display, one or more processors, and memory configured for executing one or more programs by the one or more processors. The method includes displaying a first object icon and a second object icon located to the right of the first object icon in a user interface. The first object icon represents a first object from a first data source. The second object icon represents a second object from the first data source. The first object icon is connected to the second object icon via a first connector representing a relationship between the first object and the second object. The relationship between the first object and the second object has a first cardinality. The method includes: in response to receiving first user input to add a third object, displaying a third object icon representing the third object in the user interface. The method includes: in response to receiving second user input on the third object icon, when the second object and the third object include at least one common data field, generating and displaying a second connector connecting the third object icon to the second object icon in the user interface. The second connector represents a relationship between the third object and the second object. The relationship between the third object and the second object has a second cardinality.

[0027] (A2) In some implementations of A1, the first cardinality is one of the following: many-to-many relationship, many-to-one relationship, or one-to-many relationship.

[0028] (A3) In some implementations of A1 or A2, the second cardinality is one of the following: many-to-many relationship, many-to-one relationship, or one-to-many relationship.

[0029] (A4) In some implementations of any of A1 to A3, the second user input includes a user selection of at least a portion of the third object icon. The method further includes: in response to the user selection, generating and displaying a freeform line in the user interface. A first end of the freeform line is connected to the third object icon, and a second end of the freeform line corresponds to the position of the mouse cursor in the user interface.

[0030] (A5) In some implementations of any of A1 to A4, the method further includes: in response to receiving a user interaction with the second connector, displaying an identifier of at least one common data field.

[0031] (A6) In some implementations of any of A1 to A5, the method further includes: after connecting the third object icon to the second object icon via the second connector, in response to receiving a user selection on the first object icon, displaying in the user interface a plurality of data rows and data columns representing information corresponding to one or more data fields in the first object.

[0032] (A7) In some implementations of any of A1 to A6, the method further includes: after connecting the third object icon to the second object icon via the second connector, vertically aligning the first object icon and the third object icon for display in the user interface.

[0033] (A8) In some implementations of any of A1 to A7, the method further includes: after connecting the third object icon to the second object icon via the second connector, arranging the first object icon and the third object icon in alphabetical order for display in the user interface.

[0034] (A9) In some implementations of any of A1 to A8, showing that the second connector connecting the third object icon to the second object icon includes converting the second object from the subtree of the first object to a shared object.

[0035] (A10) In some implementations of A9, the shared object is a dimension logical table consisting of one or more dimension data fields.

[0036] (A11) In some implementations of any of A1 to A10, the first object includes a first fact table and the third object includes a second fact table that is not related to the first fact table.

[0037] (A12) In some implementations of any of A1 to A11, at least one common data field includes a geographic data field.

[0038] (A13) In some implementations of any of A1 to A11, at least one common data field includes a date / time data field.

[0039] (A14) In some implementations of any of A1 to A13, the third object is the object of the first data source.

[0040] (A15) In some implementations of any of A1 to A13, the third object is an object of a second data source that is different from the first data source.

[0041] (A16) In some implementations of any of A1 to A15, the method further includes displaying a fourth object icon representing a fourth object in a user interface. The fourth object icon is connected to a second object icon via a third connector representing a relationship between the fourth object and the second object. The relationship between the fourth object and the second object has a third cardinality. The fourth object icon is connected to a fifth object icon representing a fifth object via a fourth connector. The fourth connector represents a relationship between the fourth object and the fifth object. The relationship between the fourth object and the fifth object has a fourth cardinality. The third and fourth connectors include an overlapping portion. The method includes: in response to receiving a user interaction with the overlapping portion of the third and fourth connectors, simultaneously displaying (i) an identifier of a first related data field associated with the fourth object and the second object, and (ii) an identifier of a second related data field associated with the fourth object and the fifth object. The first object icon, the second object icon, the third object icon, the fourth object icon, and the fifth object icon are different icons. The first and second related data fields are different data fields.

[0042] (A17) In some implementations of A16, the method also includes: responding to a user selection of the identifier of a first related data field associated with the fourth object and the second object, while visually emphasizing the fourth object, the second object, and the third connector.

[0043] (A18) In some implementations of A16 or A17, the third cardinality is one of the following: many-to-many relationship, many-to-one relationship, or one-to-many relationship.

[0044] (A19) In some implementations of any of A16 to A18, the fourth cardinality is one of the following: many-to-many relationship, many-to-one relationship, or one-to-many relationship.

[0045] (A20) In some implementations of any of A1 through A19, the method further includes displaying in the user interface: (i) a fourth object icon representing a fourth object; (ii) a fifth object icon representing a fifth object; and (iii) a third connector connecting the fourth object icon and the fifth object icon. The third connector represents a many-to-many relationship between the fourth object and the fifth object. The fourth object icon, the fifth object icon, and the third connector are not connected to any of the first object icon, the second object icon, or the third object icon. The method includes generating and displaying a freeform line in the user interface in response to receiving third user input on the fifth object icon. A first end of the freeform line is connected to the fifth object icon, and a second end of the freeform line corresponds to the position of the mouse cursor in the user interface. The method includes converting the freeform line into a third connector connecting the fifth object icon and the second object icon in response to receiving an interaction between the second end of the freeform line and the second object icon, the third connector representing a many-to-many relationship between the fifth object and the second object.

[0046] (A21) In some implementations of A20, a first object icon, a second object icon, and a third object icon are displayed in the first part of the user interface. A fourth object icon and a fifth object icon are displayed in the second part of the user interface. Converting a freeform line into a third connector connecting the fifth object icon and the second object icon involves redisplaying the fourth and fifth object icons in the first part of the user interface.

[0047] (B1) According to some implementations, a method for performing guided analysis using a multi-fact object model is performed at a computing device having a display, one or more processors, and memory configured for executing one or more programs by the one or more processors. The method includes displaying multiple data field icons corresponding to multiple data fields in a user interface. Each of these data fields is associated with a corresponding object among multiple objects in an object model. The method includes: in response to (i) a user selection of a first data field icon corresponding to a first data field from the multiple data field icons and (ii) placement of the first data field icon in a shelf area of ​​the user interface, wherein the first data field is associated with a first object among the multiple objects: (1) generating and displaying a first data visualization in the user interface; and (2) updating the visual characteristics of a subset of the multiple data field icons displayed in the user interface from a first visual characteristic to a second visual characteristic. Each data field icon in the subset of data field icons is associated with a second object among the multiple objects that is different from the first object. The data field icons in the subset are user-selectable and are independent of the first or second visual characteristics.

[0048] (B2) In some implementations of B1, updating the visual characteristics of the subset of data field icons from the first visual characteristic to the second visual characteristic includes visually de-emphasizing the subset of data field icons relative to other data field icons among multiple data field icons, while maintaining the user selectability of the subset of data field icons.

[0049] (B3) In some implementations of B1 or B2, the method further includes: when the visual characteristic of the first data field subset is the second visual characteristic: in response to user interaction with a second data field icon from a subset of data field icons that corresponds to the second data field among the multiple data fields: displaying information that the second data field is unrelated to the first data field.

[0050] (B4) In some implementations of any of B1 to B3, the method further includes: when the visual characteristic of the first subset of data fields is the second visual characteristic: in response to receiving (i) a user selection of a second data field icon from the subset of data field icons corresponding to the second data field among the plurality of data fields and (ii) a user placement of the second data field icon in the shelf area: generating and displaying the second data visualization in the user interface.

[0051] (B5) In some implementations of B4, generating a first data visualization includes executing a first query that specifies the aggregation of data values ​​in a first data field. In some implementations, generating a second data visualization includes executing a second query that repeats the aggregated data values ​​of the first data field for each data value in a third data field.

[0052] (B6) In some implementations of B4 or B5, the method includes: while displaying the second data visualization, displaying a warning visual indicator adjacent to the icon of the first data field in the shelf area. In response to user interaction with the warning visual indicator, the method displays information unrelated to the second data field and the first data field.

[0053] (B7) In some implementations of any of B1 to B6, the method includes: after updating the visual characteristics of a subset of data field icons to a second visual characteristic: in response to receiving (i) a user selection of a third data field icon from a plurality of data field icons, wherein the third data field icon corresponds to a third data field and is not a data field icon from a subset of data field icons, and (ii) placement of the third data field icon in a shelf area: performing a second query specifying the aggregation of data values ​​of a first data field based on the third data field to generate a third data visualization, and then displaying the third data visualization in the user interface.

[0054] (B8) In some implementations of B7, the method also includes updating the visual characteristics of a subset of data fields from the second visual characteristics to the first visual characteristics while displaying the third data visualization.

[0055] (B9) In some implementations of B7 or B8, the third data field is a shared data field shared between the first object and the second object.

[0056] (B10) In some implementations of any of B7 to B9, the third data field is associated with the dimension logical table.

[0057] (B11) In some implementations of any of B7 to B10, the third data field is a dimension data field.

[0058] (B12) In some implementations of any of B7 to B11, the third data field is a geographic data field.

[0059] (B13) In some implementations of any of B7 to B11, the third data field is a date / time data field.

[0060] (B14) In some implementations of any of B7 to B13, the method further includes: after displaying the third data visualization: in response to receiving (i) a user selection of a fourth data field icon corresponding to the fourth data field from a subset of data field icons and (ii) placement of the fourth data field icon in the shelf area: performing a third query specifying the data value of the fourth data field aggregated according to the third data field to generate the fourth data visualization, and displaying the fourth data visualization in the user interface.

[0061] (B15) In some implementations of B14, the fourth data visualization and the third data visualization are displayed simultaneously in the user interface.

[0062] (B16) In some implementations of B15, the third and fourth data visualizations share a common data axis.

[0063] (C1) According to some implementations, a method for generating data visualizations using a multi-fact object model is performed at a computing device having a display, one or more processors, and memory configured for executing one or more programs by the one or more processors. The method includes receiving first user input, the first user input specifying a first dimension data field and a second dimension data field for generating a first data visualization. The method includes determining that the first dimension data field belongs to a first object of the object model, and that the second dimension data field belongs to a second object of the object model, distinct from the first object. The method includes constructing a dimension subquery based on characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object. Construction includes: determining a join type for combining (i) a first data row including data values ​​of the first dimension data field and (ii) a second data row including data values ​​of the second dimension data field; and constructing a dimension subquery based on the determined join type, the dimension subquery referencing the first object and the second object. The method includes executing the dimension subquery against one or more data sources corresponding to the first dimension data field and the second dimension data field to obtain a first tuple comprising a unique ordered combination of data values ​​of the first dimension data field and the second dimension data field. The method includes constructing one or more metric subqueries, each of which references one or more metric data fields in an object model. The method includes executing one or more metric subqueries to obtain a second tuple. The method includes forming an extended tuple by combining the obtained first tuple and the obtained second tuple. The method also includes generating and displaying a first data visualization based on the extended tuple.

[0064] (C2) In some implementations of C1, constructing a dimension subquery based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the object includes using an inner join to combine the data columns of the first dimension data field and the second dimension data field when (i) the first dimension data field can be traced back to a root object and (ii) the second dimension data field can be traced back to the same root object.

[0065] (C3) In some implementations of C1, constructing a dimension subquery based on the characteristics of a first dimension data field, a second dimension data field, a first object, and / or a second object includes: when (i) the first dimension data field can be traced back to a first root object and (ii) the second dimension data field can be traced back to a second root object different from the first root object: (a) forming a first object tree including the first object and the first root object, and using an inner join to combine the data columns of the objects from the first object tree to form a first table based on the data values ​​of the first dimension data field; (b) forming a second object tree including the second object and the second root object, and using an inner join to combine the data columns of the objects from the second object tree to form a second table based on the data values ​​of the second dimension data field; and (c) combining the data columns of the first table and the second table via a cross join.

[0066] (C4) In some implementations of C1, constructing a dimension subquery based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object includes: when the first dimension data field and the second dimension data field belong to the same object shared by two or more root objects, using an inner join to combine the data columns of the first dimension data field and the second dimension data field.

[0067] (C5) In some implementations of C1, constructing a dimensional subquery based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object includes using a cross join to combine the data columns of the first dimension data field and the second dimension data field when (i) the first object is shared by the first group of root objects and (ii) the second object is shared by the second group of root objects.

[0068] (C6) In some implementations of C1, constructing a dimension subquery based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object includes: using an inner join to combine the data columns of the first dimension data field and the second dimension data field when (i) the first object is the first root object, (ii) the second object can be traced back to the first root object, and (iii) the second dimension data field is not shared by another root object.

[0069] (C7) In some implementations of any of C1 to C6, the first dimension data field and / or the second dimension data field are geographic data fields.

[0070] (C8) In some implementations of any of C1 to C7, the first dimension data field and / or the second dimension data field is a date / time data field.

[0071] (C9) In some implementations of any of C1 to C8, one or more data sources include multiple data sources.

[0072] In some implementations, a computing device includes one or more processors, memory, and one or more programs stored in the memory. The programs are configured to be executed by the one or more processors. The one or more programs include instructions for performing any of the methods described herein.

[0073] In some implementations, a non-transitory computer-readable storage medium stores one or more programs configured for execution by a computing device having one or more processors and memory. The one or more programs include instructions for performing any of the methods described herein.

[0074] Therefore, methods, systems, and graphical user interfaces are provided for creating object models across multiple fact tables, as well as for analyzing and presenting data based on multi-fact data models.

[0075] It should be noted that the various implementations described above can be combined with any other implementations described herein. The features and advantages described in the specification are not exhaustive, and in particular, many additional features and advantages will be apparent to those skilled in the art from the accompanying drawings, specification, and claims. Furthermore, it should be noted that the language used in the specification is primarily chosen for readability and instructional purposes and may not be intended to limit or define the subject matter of the invention. Attached Figure Description

[0076] To better understand the aforementioned systems, methods, and graphical user interfaces, as well as additional systems, methods, and graphical user interfaces that provide data visualization and analysis, reference should be made to the following detailed embodiments in conjunction with the accompanying drawings, wherein similar reference numerals refer to corresponding parts throughout the drawings.

[0077] Figure 1A The workflow for creating and consuming data models across multiple fact sets is shown, based on some implementation methods. Figure 1B The data model is shown according to some implementation methods. Figure 1C The visual differences between existing data models based on some implementations and publicly available data models are shown.

[0078] Figure 2 It is a block diagram of a computing device based on some implementation methods.

[0079] Figure 3 It is a block diagram of a server system based on some implementation methods.

[0080] Figure 4A and Figure 4B A separate fact table is shown, which is a shared dimension logical table according to some implementation.

[0081] Figures 5A to 5D This illustrates how to add a new tree and new relationships to an existing object model, based on some implementation methods.

[0082] Figure 6A and Figure 6B This illustrates how new relationships can be added between objects in an existing object model, depending on some implementation methods.

[0083] Figure 7 This illustrates how relationships between objects can be removed from an existing object model, depending on the implementation method.

[0084] Figures 8A to 8C This illustrates how to change the relationships between objects in an existing object model, depending on some implementation methods.

[0085] Figures 9A to 9C The rearrangement of the fact subtree is shown according to some implementation methods.

[0086] Figure 10 This shows a visual representation of objects connected to the root object, based on some implementation methods.

[0087] Figure 11 This shows a visual representation of non-shared objects connected to the selected object, based on some implementation methods.

[0088] Figure 12 This illustrates how a non-shared table can be swapped with a base table, depending on the implementation.

[0089] Figures 13A to 13U A series of screenshots, based on some implementations, are provided, illustrating user interactions with a data modeling graphical user interface used to build (e.g., construct) a multi-fact data model.

[0090] Figure 14A and Figure 14B A data model with seven logical tables is shown, based on some implementation methods.

[0091] Figures 15A to 15C The data model is shown according to some implementation methods.

[0092] Figures 16A to 16H A series of screenshots, based on some implementations, are provided, illustrating user interactions with the data analytics user interface.

[0093] Figures 17A to 17E A series of screenshots, based on some implementations, are provided, illustrating user interactions with the data analytics user interface.

[0094] Figures 18A to 18I A series of screenshots, based on some implementations, are provided, illustrating user interactions with the data analytics user interface.

[0095] Figures 19A to 19G The steps of a query generation algorithm based on some implementations are shown.

[0096] Figures 20A to 20I Examples of query generation based on some implementation methods are shown.

[0097] Figures 21A to 21C The dimension-metric subgraph is shown according to some implementation methods.

[0098] Figure 22 A multi-fact object model is shown based on some implementation methods.

[0099] Figure 23 A multi-fact object model is shown based on some implementation methods.

[0100] Figures 24A to 24H This illustrates an exemplary data table or data visualization generated from the analysis of a multi-fact object model.

[0101] Figure 25 A multi-fact object model is shown based on some implementation methods.

[0102] Figure 26 The diagram illustrates the logic operations for creating a join for a tree subquery with shared nodes, based on some implementations.

[0103] Figure 27 The diagram illustrates the logic operations for creating a join for a tree subquery without shared nodes, based on some implementations.

[0104] Figures 28A to 28E A flowchart is provided for methods for generating object models (e.g., data models) across multiple fact tables, based on some implementation.

[0105] Figures 29A to 29D A flowchart is provided for methods for performing guided analysis using a multi-fact object model (e.g., a data model), based on some implementation.

[0106] Figures 30A to 30D A flowchart is provided for methods for generating data visualizations using a multi-fact object model (e.g., a data model), based on some implementations.

[0107] Throughout the accompanying figures, similar reference numerals refer to corresponding parts.

[0108] Reference will now be made in detail to implementations, examples of which are shown in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without these specific details. Detailed Implementation

[0109] Businesses need a comprehensive understanding of their data to effectively manage their operations. Often, their data exists as “silos” of separate fact tables with shared dimensions such as time and geography (e.g., dimension data fields or dimension fields). For example, an organization might have a marketing department that controls marketing campaigns for products, and a sales department that is responsible for selling those products. The ability to combine data from marketing and sales fact tables can provide a complete understanding of the effectiveness of marketing campaigns and their impact on sales. Currently, some data analytics applications limit analysis to a single set of facts, restricting the questions analysts can ask and imposing a maintenance burden on data administrators who must support workarounds. The disclosed implementation addresses these shortcomings by providing improved methods, devices, systems, and user interfaces that enable the creation and consumption of data models across multiple fact tables.

[0110] Figure 1A A workflow 100 for creating and consuming a data model across multiple fact sets, according to some implementation, is shown. In the public text, the terms "data model" and "object model" are used interchangeably and refer to the same model. Workflow 100 can be considered to include three phases: a data modeling phase (step 102), a deployment phase (step 106), and an analysis phase (step 108). The data modeling phase includes (e.g., by a data modeler) building (104) (e.g., generating) a multi-fact object model. A multi-fact object model refers to an object model that includes multiple (e.g., at least two) fact tables. In the public text, a computing device executes a data visualization application 230, which includes a data modeling user interface 240 for generating the multi-fact object model. Figure 1A A data model 120 generated and displayed by a data modeling user interface 240 according to some implementation methods is shown.

[0111] In some implementations, workflow 100 includes an analysis phase 108. In the published text, a computing device executes a data visualization application 230, which includes a data analysis user interface 250 for performing the analysis phase. Figure 1A In some implementations, a computing device (e.g., via user interface 250) receives (110) user-specified (or visual specification 252) data fields for generating a data visualization. In some implementations, the computing device is configured to apply (112) an object model (e.g., a multi-fact object model generated in data modeling phase 102) to determine query semantics. The computing device constructs (114) and executes one or more queries based on the determined query semantics. The computing device then generates (116) and displays the data visualization. Figure 1AAn exemplary data visualization 130 generated and displayed on a data analysis user interface 250 according to some implementation is shown.

[0112] Figure 1B An object model 150 is illustrated according to some implementations. An object model can be thought of as a diagram instructing a data visualization application how it should query data from connected database tables. In some instances, the object model is a simple model with a single table. In other instances, the object model is a complex model with multiple tables using different combinations of relationships, joins, and unions. Object model 150 has two layers: a logical layer 160 and a physical layer 170. In some contexts, the physical layer 170 is referred to as the "data model," and the logical layer 160 as the "object model." For the most part of this paper, the focus is on the logical layer 160.

[0113] In some implementations, the default view seen by the user (e.g., a data modeler) in the data modeling user interface 240 of the data visualization application 230 is the logical layer 160. Figure 1B In the logical layer 160, logical table A 162-1 (e.g., an object) and logical table B 162-2 (e.g., another object) are included. Relations 164 (also referred to as "noodles" in the public text) are used to combine data in logical layer 160. In physical layer 170, joins and unions are used to combine data between tables. Each logical table 162 in logical layer 160 contains data from at least one physical table in physical layer 170. Figure 1B In the table, logical table A 162-1 consists of four tables: 172-1, 172-2, 172-3, and 172-4, while logical table B 162-2 consists of one table: 172-5. Within the data source, tables at the logical layer are not merged; they remain distinct (e.g., normalized) and maintain their natural hierarchy of detail.

[0114] In public texts, the terms "object model" and "data model" are often used interchangeably. In some implementations, the logical layer 160 is also referred to as the semantic layer.

[0115] The data modeling capabilities disclosed in this article create flexible data sources built around relationships. Relationships combine data from different tables by looking at columns (fields) that those tables share and using that information to bring together information from each table in the analysis. Unlike joins or unions, relationships form data sources without breaking multiple tables down into a single table. Therefore, a related data source knows which table each field comes from. This means that each field retains its context or level of detail. Thus, related data sources can handle tables with different granularities without issues of duplication or data loss. In a related data source, joins are not pre-fixed. Not all data is merged (and all data must be processed regardless of what each visualization needs), but rather related data is combined only when necessary (e.g., according to the data visualization). As users drag and drop fields, the data visualization application evaluates the relationships between the related fields and tables. These relationships are used to write queries with the correct join types, aggregations, and null value handling. Users can think about how the data matches together and what questions they hope to answer, rather than how to combine data or compensate for artifacts from the data source. Relationships cannot replace previous ways of combining data, such as via joins, unions, and blends. Instead, relationships are a novel and flexible way to bring together data from multiple sources.

[0116] Figure 1C The conceptual differences between existing data models (top) based on some implementations and the publicly available data model (bottom) are illustrated. The multi-fact data model disclosed in this paper has a simpler and easier-to-understand layout compared to existing data models.

[0117] Figure 2This is a block diagram of a computing device 200 (e.g., a client device) capable of executing a data visualization application 230 or a data visualization web application to display data visualizations. In some implementations, the computing device displays a graphical user interface 232 for the data visualization application 230. In some implementations, the graphical user interface 232 includes a data modeling user interface 240. In some implementations, the graphical user interface 232 includes a data analysis user interface 250. The computing device 200 may be a desktop computer, a laptop computer, a tablet computer, or other computing device having a display and a processor capable of running the data visualization application 230. The data visualization application 230 may include a data source generator for database organization (e.g., generating object models for databases) and for generating new data sources using existing databases. The computing device 200 typically includes: one or more processing units / cores (CPUs) 202 for executing modules, programs, and / or instructions stored in memory 214 to perform processing operations; one or more network or other communication interfaces 204; memory 214; and one or more communication buses 212 for interconnecting these components. Communication bus 212 may include circuitry for interconnecting and communicating between system components. Computing device 200 includes a user interface 206, which includes a display 208 and one or more input devices or mechanisms 210. In some implementations, the input device / mechanism includes a keyboard. In some implementations, the input device / mechanism includes a “soft” keyboard that is displayed on the display 208 as needed, allowing the user to “press” “keys” appearing on the display 208. In some implementations, the display 208 and the input device / mechanism 210 include a touchscreen display (also known as a touch-sensitive display). In some implementations, the display is an integrated part of the computing device 200. In some implementations, the display is a separate display device.

[0118] In some implementations, memory 214 includes high-speed random access memory, such as DRAM, SRAM, DDRRAM, or other random access solid-state memory devices. In some implementations, memory 214 includes non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. In some implementations, memory 214 includes one or more storage devices located remotely from CPU 202. Memory 214 (or alternatively, the non-volatile memory devices within memory 214) includes non-transitory computer-readable storage media. In some implementations, memory 214 or the computer-readable storage media of memory 214 stores programs, modules, and data structures, or subsets thereof:

[0119] ● Operating system 216, which includes programs for handling various basic system services and for performing hardware-related tasks;

[0120] ●Communication module 218, which is used to connect computing device 200 to other computers and devices via one or more communication network interfaces 204 (wired or wireless) and one or more communication networks (such as the Internet, other wide area networks, local area networks, metropolitan area networks, etc.);

[0121] ● Web browser 220 (or other client applications) that enable users to communicate with remote computers or devices over a network;

[0122] ● Data visualization application 230 provides a graphical user interface 232 for users to perform data analysis, including building databases, building object models, and building visual graphics (e.g., standalone data visualizations or dashboards with multiple related data visualizations). In some implementations, data visualization application 230 executes as a standalone application (e.g., a desktop application). In some implementations, data visualization application 230 executes within a web browser 220 (e.g., as a web application). Data visualization application 230 includes:

[0123] A graphical user interface 232 enables users to access or build object models and data sources, and provides graphical views to create data visualizations by visually specifying elements. In some implementations, the graphical user interface 232 includes a data modeling user interface 240 for accessing or building object models and data sources. In some implementations, the graphical user interface 232 includes a data analysis user interface 250 for creating data visualizations by visually specifying elements (e.g., data fields).

[0124] Object model generator 234 generates an object model that includes multiple objects (e.g., object classes). The object model can be generated from one or more databases, and each object in the object model can be generated from one or more data tables (e.g., physical tables) or one or more data fields. An object icon represents a logical combination of one or more data tables. For example, an object represented by an object icon may include one or more data fields from a data table. In another example, an object represented by an object icon can be constructed by combining two data tables with each other (e.g., left join, right join, inner join, union, or intersection). Object model generator 234 includes a relation cardinality module 236, which determines the cardinality of the relationship between two object classes. For example, relation cardinality module 236 can determine whether a many-to-many relationship or a many-to-one relationship has been detected. Object model generator 234 also includes a relation referential integrity module 238, which analyzes and compares data values ​​from link fields (e.g., link data fields) of two object classes connected by a relationship to identify matching and non-matching data values.

[0125] ○ Object model visualization generator 242 generates (e.g., constructs) a visualization of object model 268 for display in object model visualization area 120. Object model visualization generator 242 generates object icons 1322 (e.g., Figure 13) corresponding to objects in object model 268, and generates a visual representation of the relationship between two objects in object model 268;

[0126] ○ Query semantics module 244, in response to receiving user specifications for one or more data fields used to generate data visualizations or visual specifications 252, uses an object model to determine query semantics. Query semantics specifies a database query to retrieve data from physical layer 170;

[0127] ○ Visualization generation module 246 generates data visualizations and / or data dashboards. In some implementations, visualization generation module 246 generates and displays data visualizations according to visual specifications. According to some implementations, visualization generation module 246 uses an object model to generate queries (e.g., dimensional subqueries, aggregate metric subqueries, and / or final queries) and / or uses a query optimizer to optimize queries; and

[0128] Visual specification 252 defines the desired characteristics of the data visualization. In some implementations, a user interface 250 is used to construct visual specification 252. Visual specification includes the identified data source 262 (i.e., specifying what the data source is), providing sufficient information to locate the data source 262 (e.g., the data source name or the full network path name). Visual specification 252 also includes visual variables and data fields assigned to each visual variable. In some implementations, visual specification 252 has a corresponding data field for each shelf area 1612 (e.g., ...). Figure 16A The visual variables correspond to the column shelves 1612-1 and row shelves 1612-2 in the diagram. In some implementations, the visual variables include other information, such as contextual information about the computing device 200, user preference information, or other data visualization features not implemented as shelf areas (e.g., analytical features). In some implementations, when a user adds data fields to the visual specification (e.g., indirectly by placing data fields on the shelf using a graphical user interface), the data visualization application 230 (or web application 330) groups the user-selected data fields together according to an object model. Such groups are called data field sets. In many cases, all user-selected data fields are in a single data field set. In some instances, there are two or more data field sets. Each measure m is in exactly one data field set, but each dimension d can be in more than one data field set;

[0129] ● One or more databases 260 may store one or more data sources 262 and / or one or more object models 268. Each data source 262 includes one or more data tables 264, and each data table includes one or more data fields 266. Each object model 268 includes multiple objects 270 (e.g., logical tables) connected to each other via relations 272 (e.g., relation lines).

[0130] Each of the executable modules, applications, or assemblies identified above may be stored in one or more of the previously mentioned memory devices and corresponds to an instruction set for performing the functions described above. The modules or programs identified above (i.e., instruction sets) do not need to be implemented as separate software programs, programs, or modules, and therefore various subsets of these modules can be combined or otherwise rearranged in various implementations. In some implementations, memory 214 stores a subset of the modules and data structures identified above. In some implementations, memory 214 stores additional modules or data structures not described above.

[0131] although Figure 2 A computing device 200 is shown, but Figure 2 This is intended more as a functional description of the various features that may exist, rather than as a structural diagram of the implementation described herein. In practice, and as those skilled in the art will recognize, the items shown individually can be combined, and some items can be separated.

[0132] Figure 3 This is a block diagram of a server system 300 according to some implementations. The server system 300 may host one or more databases 260, or provide various executable applications or modules. The server 300 typically includes one or more processing units / cores (CPUs) 302, one or more network interfaces 304, memory 314, and one or more communication buses 312 for interconnecting these components. In some implementations, the server 300 includes a user interface 306, which includes a display 308 and one or more input devices 310, such as a keyboard and mouse. In some implementations, the communication bus 312 includes circuitry (sometimes referred to as a chipset) for interconnecting and controlling communication between system components.

[0133] In some implementations, memory 314 includes high-speed random access memory, such as DRAM, SRAM, DDRRAM, or other random access solid-state memory devices. In some implementations, memory includes non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. In some implementations, memory 314 includes one or more storage devices located remotely from CPU 302. Memory 314 (or alternatively, the non-volatile memory devices within memory 314) includes non-transitory computer-readable storage media.

[0134] In some implementations, memory 314 or its computer-readable storage medium stores the following programs, modules, and data structures or subsets thereof:

[0135] ● Operating system 316, which includes programs for handling various basic system services and for performing hardware-related tasks;

[0136] ● Network communication module 318, which is used to connect server 300 to other computers via one or more communication network interfaces 304 (wired or wireless) and one or more communication networks (such as the Internet, other wide area networks, local area networks, metropolitan area networks, etc.);

[0137] ● A web server 320 (such as an HTTP server) receives web requests from users and responds by providing responsive web pages or other resources;

[0138] ● A data visualization web application 330 can be downloaded and executed by a web browser 220 on a user's computing device 200. Generally, the data visualization web application 330 has the same functionality as the desktop data visualization application 230, but provides the flexibility to be accessed from any device with network connectivity from any location, and requires no installation or maintenance. In some implementations, the data visualization web application 330 includes various software modules for performing certain tasks. In some implementations, the data visualization web application 330 includes a user interface module 332, which provides a user interface for all aspects of the data visualization web application 330. In some implementations, the user interface module 332 includes a data modeling interface module 340. In some implementations, the user interface module 332 includes a data analysis interface module 350. In some implementations, the data visualization web application 330 includes an object model generator 334 and an object model visualization generator 342, as described above relative to... Figure 2The object model generator 334 and object model visualization generator 242 are described above. In some implementations, the object model generator 334 includes a relation cardinality module 336 and a relation referential integrity module 338, both of which are described above in relation to... Figure 2 The relational cardinality module 236 and relational referential integrity module 238 are described in the text. In some implementations, the data visualization web application 330 includes a query semantics module 344 and a visualization generation module 346, as described above relative to... Figure 2 The query semantics module 244 and the visualization generation module 246 described in the document;

[0139] ● Data acquisition module 348 creates and executes queries to retrieve data from one or more databases 260. Databases 260 may be stored locally on server 300 or in an external database system. For example, data acquisition module 348 may retrieve data from database 260 that stores one or more data sources 262, so that data table 264 and data field 266 from data source 262 can be used to build an object model;

[0140] ●Visual Guideline 252, as mentioned above Figure 2 As described in; and

[0141] ● One or more databases 260 that store data used or created by the data visualization web application 330 or the data visualization application 230. Databases 260 may store data sources 262 that provide data used in the generated data visualizations. For example, databases 260 may store an object model 268 comprising multiple objects 270 linked to each other via one or more relations 272, and objects 270 may be formed from data fields 266 from one or more databases 260 or data sources 262.

[0142] Databases 260 can store data in many different formats and typically include many different tables 264, each with multiple data fields 266. Some databases 260 consist of a single table.

[0143] Data fields 266 in database 260 include both raw fields from database 260 (e.g., columns from a database table or a spreadsheet) and derived data fields that can be calculated or constructed from one or more other data fields. For example, derived data fields may include calculating months or quarters from date fields, calculating the time span between two date fields, calculating the cumulative total of a quantitative field, calculating percentage growth, and so on. In some instances, derived data fields are accessed by programs or views stored in the database. In some implementations, the definition of derived data field 266 is stored separately from data source 262. In some implementations, database 260 stores a set of user preferences for each user. These user preferences can be used when the data visualization web application 330 (or desktop data visualization application 230) makes recommendations on how to view the set of data fields 266. In some implementations, database 260 stores a data visualization history log, which stores information about each data visualization generated.

[0144] In some implementations, database 260 stores additional information, including information used by data visualization application 230 or data visualization web application 330. Database 260 may be separate from server system 300, or it may be included with server system (or both).

[0145] Each of the executable modules, applications, or assemblies identified above may be stored in one or more of the previously mentioned memory devices and corresponds to an instruction set for performing the functions described above. The modules or programs identified above (i.e., instruction sets) need not be implemented as separate software programs, programs, or modules, and therefore various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, memory 314 stores a subset of the modules and data structures identified above. In some implementations, memory 314 stores additional modules or data structures not described above.

[0146] although Figure 3 Server system 300 is shown, but Figure 3 This is intended more as a functional description of the various features that may exist than as a structural diagram of the implementation described herein. In practice, and as those skilled in the art will recognize, items shown individually can be combined, and some items can be separated. Additionally, some of the programs, functions, processes, or data shown above relative to server 300 can be stored or executed on computing device 200. In some implementations, functionality and / or data can be distributed between computing device 200 and one or more servers 300. Furthermore, those skilled in the art will recognize that… Figure 3 It is not necessary to represent a single physical device. In some implementations, server functionality is distributed across multiple physical devices, including the server system. As used herein, references to “server” or “data visualization server” include various groups, collections, or arrays of servers that provide the described functionality, and the physical servers do not need to be physically co-located (e.g., they can be distributed across the United States or the world as individual physical devices).

[0147] I. Naming Convention

[0148] A data model comprises an object graph. Nodes in the graph are called objects, and links are called relationships. In some implementations, the graph is also referred to as a "tree." In public texts, the terms "object model" and "data model" are often used interchangeably.

[0149] An object is a logical table in the object model. Objects are created through physical modeling. For example, an object might contain a union of two Oracle tables. When considering semantics, objects are treated as opaque, meaning that it is only necessary to be able to query the object and obtain its schema. In public texts, the terms "object" and "logical table" are used interchangeably.

[0150] Schema identifier object fields for various objects.

[0151] Relationships are links used to compose objects. A relationship links one or more pairs of objects on their fields. In some implementations of public text, data models with shared objects can block filter flows across shared objects. This contrasts with existing data models where there is one type of relationship and filters applied to an object flow through all relationships between objects. Relationships will ultimately be compiled into various types of joins.

[0152] In some implementations, information about the cardinality of the relationships (e.g., many-to-one, many-to-many, one-to-many, or one-to-one) is known to the data visualization application 230 and / or the data visualization web application 330. In some implementations, if the cardinality of the relationships is unknown, the data visualization application 230 assumes that all relationships are many-to-many.

[0153] In some implementations, referential integrity of relationships is known. For example, a data visualization application may know that joining one logical table to another will not cause the first logical table to lose rows due to mismatched keys. Without this information, the data visualization application makes no assumptions about guarantees regarding matching.

[0154] In some implementations, queries include calculations and / or filters defined by object fields or other calculations. Calculations include field names and formulas. "Overlay calculations" means applying a formula to the top of the query to output columns with given field names defined by the formula. If a field with a name already exists, the calculation overrides the field. Filters consist of certain predicates (e.g., [State] == "Alaska"). "Overlay filters" means applying the predicates at the top of the query and only retaining rows where the predicates are true.

[0155] Each tree has a root table. The root table always starts from the leftmost side of the object model.

[0156] A shared tree is a tree that can be traced back to two or more root tables. A shared tree does not include a root table.

[0157] A shared object is an object common to two or more related trees. For example, in Figure 4A In the data field "date" (in Figure 4A In this context, it is represented as "Dimension Date (DimDate)" or "Dimension Field Date (Date)" and "Site (site)" (in...). Figure 4A The dimension field "DimSite" or "Site" is a shared object.

[0158] Tree traversal is directional. When we trace an object back to its root, we only trace to the left.

[0159] Shared objects exist within a context. For example, if there are two or more fact trees used to generate data visualizations, but a shared object is only used with one fact tree, the shared object will use the same semantics as when it is not shared. This is discussed in more detail in Chapter IV.

[0160] Shared objects can be connected together to their own subtrees. Only one shared object in a shared subtree (see below) can be connected to a non-shared object in the fact tree.

[0161] Fact (sub)trees: Some implementations of public text enable data models to support multiple fact trees. Fact trees are combined at shared objects. Figure 4A In the example, there are two fact trees: (1) Inventory, Dimension Date, Dimension Site and (2) Sales, Dimension Date, Dimension Site.

[0162] Non-shared subtree: A non-shared subtree consists of all related (e.g., connected) objects in the fact tree that are not shared between fact trees. Figure 4A In the example, the non-shared subtrees are (1) inventory and (2) sales.

[0163] Shared subtree: A shared subtree consists of all related (e.g., connected) objects shared between fact trees within the fact tree. Figure 4A In the example, there are two shared subtrees: (1) Dimension Date and (2) Dimension Site. Two potential shared subtrees could exist if there are more shared objects connected to Dimension Date and Dimension Site (e.g., FiscalDate associated with Dimension Date, DimRegion associated with Dimension Site, and DimCountry associated with Dimension Region).

[0164] A dimension (or dimension data field) is a field that can be considered an independent variable. Dimension data fields contain qualitative or categorical information. Dimension data fields cannot be aggregated except for counts. Some examples of dimensions are "Date", "Region", "Customer Name", "Sales Type", "Order ID", "Age", and "Longitude".

[0165] A measure (or measure data field) is a field that serves as the dependent variable. That is, its value is a function of one or more dimensions (e.g., dimension data fields). A measure field is a field that contains numeric (e.g., quantitative) information. Examples of measure fields are "Sales," "Revenue," "Price," and "Spending."

[0166] II. Multi-fact data model using shared objects

[0167] The public text improves the existing data modeling experience by enabling analysts to (i) create data models with multiple related trees (also known as object models); (ii) create relationships to share objects between trees independently of adding objects; (iii) identify objects (e.g., logical tables) and relationships within a tree; and (iv) identify the trees and objects associated with shared objects.

[0168] One pain point of existing data modeling tools is that analysts cannot aggregate measures from different fact tables (e.g., multi-fact tables) into a common dimension shared by the fact tables. Figure 4A The diagram shows an inventory logical table 402 (fact table) and a sales logical table 404 (another fact table). Inventory table 402 and sales table 404 have separate facts that are not directly related to each other. However, they both share a dimension date (DimDate) object 406 (logical table) and a dimension site (DimSite) object 408 (another logical table). Figure 4BAs shown in existing data modeling tools, in order to aggregate measures from the inventory fact table and the sales fact table using a common dimension, the analyst must (i) generate (412) a first visualization by aggregating measures from the inventory table 402 using the dimension date and site; (ii) generate (414) a second visualization by aggregating measures from the sales table 404 using the dimension date and site; and (iii) juxtapose (416) the first and second data visualizations on the data dashboard.

[0169] II.A. Feature Target

[0170] According to some aspects of the publicly available text, the same object can be connected to multiple fact trees as a "shared object".

[0171] Some aspects of the public text support the current flexibility of tables and fields (which can be dimensions or measures).

[0172] Some aspects of the public text support existing relational semantics within the same fact tree (i.e., relationships between logical tables, joins / unions between physical tables).

[0173] Some aspects of the public text support shared objects between some (but not all) fact trees.

[0174] Some aspects of public text support shared objects that can have their own subtrees.

[0175] II.B. Multi-tree method

[0176] Based on some aspects of the publicly available text, the characteristics / properties of the multi-tree method include:

[0177] ● Continue with the current left-to-right layout of the data model.

[0178] ● The leftmost object is the root (e.g., the root table or root object). At the far left of the data model, each tree can have one and only one root, which will be used to describe the fact (sub)tree.

[0179] ● Objects belonging to the same snowflake data model are associated together as (sub)trees.

[0180] ● Objects within the same subtree are fanned out from the root (to the right).

[0181] ●Emit each tree by starting from the root and then traversing all relations from the root to the end of each branch, but never going back.

[0182] ● Each object must belong to at least one tree. A single object itself can be a tree.

[0183] ● Each object can have zero or one relational path that returns each root object.

[0184] ● Each shared object is defined as being inversely related to two or more root objects.

[0185] ● For any tree with one or more shared objects, there exists only a specific set of subtrees that can be explicitly derived from it.

[0186] ● Root objects cannot be directly related to each other.

[0187] ● Shared objects can exist when there are at least two distinct subtrees / roots.

[0188] ● Shared objects are associated with two or more fact trees and can be analyzed using new semantics (see the “Query Semantics” section).

[0189] II.C. Use Case Scenarios

[0190] This section describes four exemplary workflows that lead to the use and avoidance of multiple facts with shared objects:

[0191] ●Scenario 1: Creating a new data model when it is known that the data model uses multiple facts with shared objects;

[0192] ●Scenario 2: Modify the data model (without using shared objects) to have multiple facts and use shared objects;

[0193] ●Scenario 3: Converting multiple single-fact data sources into a single multi-fact data source with a shared table; and

[0194] ●Scenario 4: Remove multi-facts and shared objects from a single-fact data model.

[0195] Scenario 1: Two (or more) fact subtrees with two (or more) shared objects. In some existing data modeling tools, adding objects also adds relationships. To support shared objects, some implementations of public text enable adding relationships independently of objects. For example, in some implementations, relationships can be added across (sub)trees, thereby changing (e.g., transforming) objects into shared objects. In some implementations, relationships can be added to link another tree to existing shared objects.

[0196] Unlike existing data modeling tools that assume only one root table, some implementations of the publicly available text support building data models with multiple root tables. Figure 5A , Figure 5B , Figure 5C and Figure 5D The addition of a new root to object model 510 is illustrated according to some implementation schemes. In some implementations, object model 510 is displayed in data modeling user interface 240 or data modeling user interface 340.

[0197] Figure 5A The object model 510 is shown to include an inventory object 512, a date object 514, and a site object 516. Data in the inventory object 512 can be combined with data in the date object 514 via a first relation 522. Data in the inventory object 512 can be combined with data in the site object 516 via a second relation 524. The inventory object 512, date object 514, and site object 516 form an "inventory" tree. The data modeling user interface 240 or data modeling user interface 340 may display an icon 518 for creating new trees (e.g., a drag-and-drop area "+New Tree"). Figure 5A The diagram shows placing the sales object 520 (523) on the icon 518 to add a new tree (e.g., "Sales") to the object model. Figure 5B This shows that a new "Sales" tree has been added. Sales can become their own separate tree, or they can be associated with the inventory tree via a shared object.

[0198] According to some implementations in the publicly available text, the root and fact subtrees do not necessarily have to be immediately related to each other. For example, Figure 5B The sales tree consisting of 520 sales objects is shown, independent of the inventory tree. Figure 5B It is also shown that in some implementations, in response to user interaction with the sales object 520 (e.g., on its right), a free-form line 526 is generated and displayed.

[0199] Figure 5C This demonstrates the ability to add relationships from a sales tree to another tree (e.g., an inventory tree) independently of objects. In the example, in response to a user drawing a freeform line 526 to a date object 514, the data model creates a relationship 528 between the sales object 520 and the date object 514. Figure 5D As shown, the newly added relationship 528 makes the date object 514 a shared object between the inventory fact tree (or fact subtree) and the sales fact tree (or fact subtree).

[0200] Some implementations of public text enable data modelers to create relationships independently of adding new objects. Figure 6A Object model 610 is shown, which includes an inventory root object 612 and a sales root object 614. Date object 616 is shared with inventory object 612 and sales object 614 via relations 624 and 626, respectively. Product object 618 is associated with sales 614 via another relation 630. Site object 620 is associated with inventory 612 via relation 628. In some implementations, context menus on objects can be used to add new relations. Figure 6A A context menu 622 corresponding to product 618 is shown, which can be accessed in response to a user selection of icon 621 on product object 618.

[0201] exist Figure 6B In the diagram, inventory object 612 and site object 620 are highlighted because either object can accept a relationship from product object 618. Other objects cannot be associated with product object 618 because sales object 614 is already associated with product object 618, and date object 616 is already associated with sales (as a cross branch within the same subtree). In response to user interaction with product object 618, freeform line 632 can extend from the right side of product object 618 to connect to site object 620 to create a relationship between the two objects.

[0202] If an object is deleted from its right-hand side (i.e., downstream), the existing data model automatically removes the relationship from the object. To support adding / removing relationships between shared and non-shared objects, some implementations in the public text enable the deletion of such relationships. Figure 7 This illustrates that a relationship in object model 700 can be removed when there are two or more relationships to the left of the current object. In object model 700, site object 710 has a first relationship 718 with budget object 712; a second relationship 720 with inventory object 714; and a third relationship 722 with product object 716 to its left. Figure 7 A menu 724 is shown that displays in response to a user selection of relationship 720 (e.g., via mouse click), allowing the user to remove the relationship.

[0203] In some implementations, any of the relationships can be deleted when there are two or more relationships to the left of the current object. In other implementations, the option to remove a relationship is not available when there is only one subtree.

[0204] In some implementations, a shared object becomes "non-shared" when its last remaining relation is associated with a tree. In some implementations, it is not possible to delete the last remaining relation to the left of the current object.

[0205] In some implementations, objects downstream of the current object become non-shared if they are only associated with one (sub)tree.

[0206] As mentioned above, a relationship is a link used to compose objects. In some implementations, the relationship can be changed by modifying either end of the link. Figure 8A A data model 800 is shown, comprising an inventory object 802 and a date object 804 connected by a relation 806. In response to a user selection of relation 806, the data modeling user interface 240 (or data modeling interface module 340) displays a menu 807, which includes options for removing the relation, changing the left table, or changing the right table.

[0207] In some implementations, the user at one end of relation 806 chooses to release the relation to connect to another object. Figure 8B The connection between inventory 802 and date 804 was removed in response to a user selection at the right end of relation 806, and a freeform line 808 was created. Figure 8C This illustrates the creation of a connection 810 (e.g., a relationship) between inventory object 802 and financial object 812 via manipulating freeform line 808. Financial object 812 becomes a shared object between the subtree of budget object 814 and the subtree of inventory object 802.

[0208] Core Scenario 2: Enables the rearrangement of fact subtrees so that data modelers can share the object currently set as the root.

[0209] With existing data modeling tools, if a user does not add objects in the correct order, they will have to restart the data modeling process, which may require removing all objects already created in the data model. According to some implementations in the publicly available text, a user (e.g., the data modeler) can assign any non-shared object of the tree as a root (e.g., a root object or root table).

[0210] Figure 9A An exemplary complex data model 900 is shown. According to some implementations in the publicly available text, because the budget object 902 and the product object 904 are not shared in the data model 900, they can be the roots in their respective subtrees. Figure 9B Budget object 902 is shown to have financial branch 906 and site branch 908. Figure 9C This shows that making Budget 902 the new root causes Finance to become the new branch, and the site and its shared subtree with employees and the state become the new branches.

[0211] Core Scenario 3: The data model may become complex, and users will need to be able to take different perspectives to view the scope of the fact subtree or see which facts are already related to the currently shared object.

[0212] Figure 10 An object model 1000 is shown according to some implementation methods. Figure 10 As shown in some implementations, when a user selects reservation object 1002, all objects connected to the reservation object (e.g., reservation type 1004, billing category 1006, month FK 1008, provider ID 1010, room 1012, population count 1014, fiscal year 1016, service type ID 1018, cost code 1020, subcategory 1022 and category 1024) and their corresponding relational connectors are visually emphasized.

[0213] In some implementations, when a non-shared object of object model 1000 (e.g., rating 1026, channel 1028, and / or feedback 1030) is selected, the connected non-shared object and all shared objects connected to the non-shared object are highlighted. Figure 10 The rating fact tree is shown to consist of two types of objects: non-shared objects (e.g., such as rating 1026, channel 1028, and / or feedback 1030) and shared objects (e.g., demographic number 1024, service type ID 1018, cost code 1020, subcategory 1022, category 1024, month FK 1008, and financial year 1016).

[0214] Some implementations of public text enable data modelers to view the data model from the perspective of shared objects, thus allowing data modelers to identify which subtrees have been shared with it. Figure 11 This is shown from the perspective of month FK 1018. Figure 10 The data model shown is 1000. In this viewpoint, users can identify the root object (i.e., the object in the leftmost column), rating 1022, expense 1034, invoice 1028, and appointment 1036. The fiscal year object 1016 shares the same data as the month FK 1018, while other objects in object model 1000 are non-shared. The data modeler can introduce additional non-shared objects or remove relationships with existing objects. Figure 11 As shown in some implementations, the data modeling user interface 240 includes an enablement representation 1102 that allows the user to select which root objects (e.g., rating 1026, cost 1034, invoice 1028, and appointment 1036) the user wants to view on the user interface.

[0215] In some implementations, users can swap the non-shared tables of the object model with the base tables of the object model. Figure 12 Data model 1200 is shown, in which there are enough tables to exchange with the base table, and parent node reset has operational freedom. Figure 12 In the table structure, the base tables are the leftmost tables: Inventory 1202, Marketing 1204, Sales 1206, and Support 1208. Non-shared tables are those that can be traced back to only one base table: Inventory 1202, Marketing 1204, Sales 1206, Stores 1214, Regions 1222, Support 1208, and Parts 1216. The shared tree of tables is those trees within their own tree that are grouped together starting with a table shared by multiple base tables. Figure 12 In this context, a single shared tree (single table tree) consists of Supplier 1218, Date 1210, and Customer 1212. Multiple shared trees (multiple table trees) consist of Product 1220, Subcategory 1224, Category 1226, and Part 1228.

[0216] In some implementations, any non-shared table can be swapped with its base table. For example, in... Figure 12 In this context, stores 1214 and areas 1222 can be exchanged with sales 1206; parts 1216 can be exchanged with support 1208.

[0217] In some implementations, users can reset the parent node of a table within its own tree. In other implementations, a non-shared table that can be exchanged with its base table can reset its own parent node to any other non-shared table originating from the same base table. For example, in... Figure 12 In this context, region 1222 can be reset to sales 1206 by its parent node. In some implementations, shared tables can have their parent nodes reset within their own shared tree. For example, in... Figure 12 In the process, category 1226 can be reset to component 1228 by its parent node; component 1228 can be reset to subcategory 1224 or category 1226 by its parent node.

[0218] II.D. Exemplary User Interface for Building Multi-Fact Data Models

[0219] Figures 13A to 13U A series of screenshots, based on various implementations, are provided illustrating user interactions with a data modeling graphical user interface 240 used to establish (e.g., construct) a multi-fact data model. In some implementations, the graphical user interface 240 is used to validate relationships between objects (also referred to as object classes or logical tables) in an object model.

[0220] exist Figure 13A In this embodiment, according to some exemplary implementations, user interface 240 includes a connection area 1302, a table area 1304, an object model visualization area 1306, a data field / metadata area 1308, and a data area 1310. The connection area 1302 includes one or more user-selectable data sources 1312. The table area 1304 includes one or more icons 1314. Each icon 1314 represents a corresponding data table from one or more data sources 1312 selected in the connection area 1302. The object model visualization area 1306 displays multiple object icons 1322 (e.g., ...). Figure 13A Object model 1320 (1322-1 to 1322-9 in the model). Each object icon 1322 represents a corresponding object (e.g., a logical table or object class) in object model 1320, and each object includes one or more corresponding data fields. Object model visualization area 1306 also displays visual connections 1324 (e.g., connecting links or connectors) between connected object icons 1322. Each visual connection 1324 represents a corresponding relationship between connected objects corresponding to object icons 1322.

[0221] exist Figure 13AIn the example, object model 1320 is a multi-fact model, which includes multiple fact tables "Inventory," "Marketing," and "Sales" corresponding to object icons 1332-1 to 1332-3. In some implementations, the fact tables are also called root tables (or root objects). In some implementations, the object icons corresponding to the fact tables are located in the leftmost part of the object model visualization area 1306. In some implementations, the object icons corresponding to the fact tables are arranged alphabetically in the user interface 240.

[0222] In some implementations, the data field / metadata area 1308 displays information about the data fields and / or metadata of the selected object, represented as object icon 1306 in the object model visualization area 130. For example, Figure 13A In response to a user selection of the object icon 1322-1 corresponding to the “Inventory” object, the data field / metadata area 1308 displays table 1326, which provides information about the fields in the Inventory logical table, such as their field names, field types, the physical table in which the corresponding field is located, and metadata information (such as remote field names).

[0223] In some implementations, data area 1310 displays information about the data fields and data values ​​of the selected object, represented as object icon 1306 in object model visualization area 130. For example, Figure 13A It is also shown that in response to a user selection of object icon 1322-1, data area 1310 displays table 1328, which includes information about data fields corresponding to the inventory logical table and their respective data values.

[0224] Figure 13B In response to user interaction with visual connection 1324-1 (e.g., user selection or mouse hover), user interface 240 displays tooltip 1330, which provides information about logical tables, cardinality (e.g., many-to-many, many-to-one, one-to-many), and related fields connected by visual connection 1324-1.

[0225] Figure 13C The image shows a user (e.g., via mouse) hovering over (1332) the object icon 1322-2 corresponding to the “Marketing” object. Figure 13CThe user interface 240, in response to user interaction, displays a subset of object icons 1322-4, 1322-5, 1322-8, and 1322-9 of the object model. These icons correspond to the object dates, products, subcategories, and categories connected to the "Marketing" object. The user interface 240 also displays visual connections 1324 to the subset of object icons. Simultaneously, in the user interface 240, other object icons and connectors not connected to the "Marketing" object are visually de-emphasized. In some implementations, in response to a user hovering over object icon 1322, the user interface 240 displays a tooltip 1332 inviting the user to double-click object icon 1322 to view a physical table.

[0226] Figures 13D to 13S The process of adding a “supporting” fact table to data model 1320 is shown according to some implementation methods. Figure 13D It shows that before the “support” fact table is added to the object model, the “Customer” object (represented by object icon 1322-7) is not shared because it is only connected to a root table, Sales (represented by object icon 1322-3).

[0227] Figure 13E The user selection (1334) is shown for icon 1314-1 corresponding to the supporting data table (e.g., fact table). Figure 13F The image shows a user drag-and-drop action where icon 1314-1 is dragged from table area 1304 to object model visualization area 1306. Figure 13F It also shows that when icon 1314-1 passes through table area 1304 and enters object model visualization area 1306, user interface 240 displays options for adding a new table (or creating a new tree, as shown in the reference). Figure 5A The power representation 1336 (e.g., an icon or drag-and-drop area) described by element 518 (e.g., "+ new base table").

[0228] Based on some implementations in the publicly available text, when a user imports a table (e.g., a logical table or an object) into the object model visualization area 1306, there are two ways to add a table to the object model. The first way to add a table to the object model is through relations (e.g., "relationship lines"). For example, Figure 13G and Figure 13H This illustrates that when a user moves icon 1314-1 toward any existing object icon 1322 in data model 1320, a freeform line 1338 is automatically generated, with one end connected to icon 1314-1. The user can connect the other end of the freeform line 1338 to the object icon of the object to form a relationship between a "support" logical table and the object. Figure 13G This illustrates the possible relationships between support tables (objects) and sales objects. Figure 13HThis illustrates the possible relationships between support tables (objects) and client logic tables. Figure 13I It is shown that if icon 1314-1 is placed below an existing object (e.g., "Customer"), the data visualization application provides a union option (1340) to combine the two objects (e.g., "Customer" and "Support").

[0229] The second way to add a table to the object model is via the energy representation 1336 used to add a new table. Figure 13J and Figure 13K This shows the placement of icon 1314-1 on power display 1336. Figure 13K Add a new object icon 1322-10 to data model 1320, corresponding to the "Support" logical table. Figure 13K In this context, the “Support” logic table exists as a separate table in the object model because object icon 1322-10 is not connected to other object icons in object model 1320.

[0230] Figure 13K As shown in some implementations, when the data visualization application 230 detects the presence of a standalone object (not connected to any other object) in the object model, the data visualization application 230 displays an alert icon 1342 on the user interface. Figure 13L In response to a user selection (1344) of alert icon 1342, user interface 240 displays a tooltip informing the user that a broken table exists in the graph (object model). The tooltip includes an alert feature 1348 that can be activated by the user.

[0231] Figure 13M In response to user activation (1350) of alert feature 1348, user interface 240 displays object icons 1322 corresponding to individual objects (e.g., disconnected objects) in a disconnect table area 1352 separate from the object model visualization area 1306. The disconnect table area 1352 is helpful to the user in identifying disconnected objects and makes the data modeling process more efficient.

[0232] Figures 13N to 13Q This illustrates the process of adding relationships to objects based on some implementation methods. Figure 13NThis illustrates the generation and display of a freeform line 1354 (e.g., a "relationship line") when a user selects a portion (e.g., an edge, side, or icon) of object icons 1322-10. One end 1356 of the line 1354 is connected to the object icons 1322-10, and the other end 1358 of the line 1354 corresponds to the position of the mouse cursor in the user interface 240 (e.g., within predefined boundaries). It should be noted that when the user (e.g., by moving the mouse) moves the other end 1358 of the line 1354 to interact with other object icons in the object model, objects that can form a relationship with "supporting" objects (e.g., ...) are visually emphasized. Figure 13O "Customer" and Figure 13P The "date" in the text, and visually de-emphasize objects that cannot form a relationship with the "supporting" object (e.g., Figure 13Q (Subcategories and Categories). In some cases, due to limitations of the tree traversal strategy, and / or if the relationship would create a nested shared tree, the user interface 240 prevents the user from forming relationships between the root table and one or more shared objects.

[0233] Figure 13R The illustration shows a user interaction where the other end 1358 of the freeform line 1354 is connected to the object icon 1322-7 corresponding to the object "customer". Figure 13S The data visualization application 230, in response to user interaction, displays a visual connection 1324-2 between object icons 1322-7 and 1324-10. Visual connection 1324-2 represents the relationship between these two connected objects. Because object icon 1324-10 is now connected, no independent object exists in the object model. Therefore, the disconnected table area 1352 is no longer displayed in the user interface. In some instances, the user can continue to create other relationships. For example, the "Support" table could have dates, and the user could drag another freeform line 1360 (e.g., by interacting with a portion of object icon 1324-10) and link it to the "Date" logical table (…). Figure 13T This is done to establish a connection between the "Support" object and the "Date" object. This is achieved through... Figure 13U The visual connector 1324-3 between object icons 1322-10 and 1322-7 is shown in the diagram. In some implementations, the user can click the visual connector corresponding to the relationship and then click... Figure 13U Use the "Remove Relationship" icon 1362 to remove the relationship between two objects. Figure 13U An object model including updates to the fact table is shown.

[0234] III. Multifact Data Model Analysis

[0235] There are several analytical challenges in using complex data models, including those with shared dimensions, to analyze relationships between multi-fact data sources:

[0236] ●Relevance: Cross-fact analysis can present data fields that are relevant, irrelevant, and / or not clearly relevant.

[0237] ●Non-aggregate comparison with aggregate calculations: Calculations within a single set of facts are performed at the non-aggregate level, while cross-fact analysis must be performed at the aggregate level.

[0238] ● Cardinality warning for multiple facts: Cross-connecting / Cartesian joins are made between unrelated dimensions of different facts, thus introducing potentially high cardinality products that require user intervention.

[0239] ● Filters on shared logical tables are applied to all trees involved.

[0240] ● Keep pill-related icons on the shelf.

[0241] ● Are the fields located within the same or different fact trees? If fields in an analysis are distributed across different facts (e.g., fact tables, fact trees), are there clearly related paths between them? How can analysts know which fields should be used together?

[0242] Refer again Figure 4A For example, Inventory 402 (e.g., an inventory object) and Sales 404 (e.g., a sales object) are separate fact tables that do not have row-level correspondences (primary key-foreign key) with each other. However, they both share dimension Date 406 and dimension Site 408 objects (e.g., logical tables). The current semantics in object modeling need to be updated so that Inventory 402 and Sales 404 can be aggregated separately to dimension Date and dimension Site.

[0243] To address these challenges, public text introduces new semantics for unrelated fields. Some implementations of public text also offer improved user interfaces that provide more direct feedback to help analysts understand the underlying semantics, take appropriate actions to align their analysis along shared dimensions, or resolve ambiguities. The improved user interface decouples from complex data models and presents data analysts with a simple yet clear analytical experience. If analysts "deviate" during analysis, they are notified of this deviation and can take actions to get back on track.

[0244] III.A. Feature Target

[0245] One aspect of public text is improving the existing analytics experience by presenting users with accessible data fields. For example, a public user interface displays fields when using single-tree versus multi-tree semantics.

[0246] Another aspect of the public text introduces additional user interface features to resolve ambiguity. For example, multiple unrelated dimensions are cross-connected, resulting in high cardinality. Paths that may not be explicitly related are resolved.

[0247] Another aspect of public text is to enhance existing pill UX (e.g., in shelf areas of the user interface) to help users understand the underlying semantics when fields are irrelevant or ambiguous, and / or to help users understand the actions they can take to get back on track.

[0248] III.B. Relevance Metadata for Multi-Fact Data Models

[0249] III.B.1. Problem Statement

[0250] The current Tableau data model consists of a single treemap of logical tables. In the schema viewer, columns within a logical table are represented as dimension and metric fields, with their parent node being the logical table itself. Fields that are calculated and aggregated across multiple tables appear outside the table hierarchy. This logical grouping provides analysts with the necessary context to decide what to use in their analysis. An aggregation path always exists between any dimension and metric field.

[0251] However, in multi-fact data models, the aggregation paths between dimensions and measures can be none (irrelevant), one (relevant), or multiple (unclearly related). Furthermore, analysts lack the additional context regarding which fields belong to which trees and which fields should be used together. Teams relying on Tableau's multi-fact data model may also lack this additional context for their features to function correctly.

[0252] III.B.2. The proposed solution

[0253] There are two sets of contextual information that are unavailable in the current schema viewer: (1) what the static metadata is about which fields belong to which trees; and (2) what the dynamic metadata is about which other fields can be used together given a set of fields used in the analysis stream.

[0254] These two sets of metadata are very important in the following ways:

[0255] 1. The schema viewer grays out fields that are unrelated or ambiguously related to (e.g., on the shelf) the currently used tree and provides explanatory information clarifying why they can / cannot be used together.

[0256] 2. Explaining data determines which dimensions the measure is being evaluated on, while data that is irrelevant or ambiguously related is not explained, even if it lacks an underlying data relationship.

[0257] 3. Ask Data automatically creates perspective views (lenses) for single facts and multiple facts.

[0258] 4. The data catalog identifies the logical table hierarchy.

[0259] 5. Narrative science can use relevance to generate stories.

[0260] III.B.3. Model Example

[0261] Figure 14A A multifact data model with seven logical tables (tables 1, 2, 3, 4, 5, 6, and 7) is shown. In the data model, there are three fact trees sharing logical tables (4, 5, 7, and 6) and three shared trees for logical tables (4), (5, 7), and (6).

[0262] Figure 14B The multi-fact data model is shown to consist of separate trees (tree 1, tree 2, and tree 3).

[0263] There are three shared trees in the logical table:

[0264] ● Shared tree A, which belongs to fact trees 1 and 2: Table 4

[0265] ● Shared tree B, which also belongs to fact trees 1 and 2: Tables 5 and 7

[0266] ● Shared tree C, which belongs to fact trees 2 and 3: Table 6

[0267] III.B.4. Ideal Use Case

[0268] Single Tree: Although the data model contains multiple facts (1 to 3), analysts can focus their analysis on a single fact at a time. If an analyst is using a field that has only one common fact, the underlying query semantics will only use that fact, and this will maintain backward compatibility with current versions of object modeling tools. Example:

[0269] a. Simple Tree 1 using base tables: dimensions from Table 1, measures from Tables 4, 5 and / or 7.

[0270] b. Simple Tree 2 without using a base table: Dimensions come from Table 6, and measures come from Tables 4, 5, and / or 7.

[0271] Multiple trees: in Figure 14AIn the model example, using dimensions from Tables 4, 5, and / or 7 will make the measures from Tables 1 and 2 (but not Table 3) relevant. Alternatively, dimensions from Table 6 will make the measures from Tables 2 and 3 (but not Table 1) relevant. If analysts are using dimensions from Tables 4 and 6, they should use the measures from Table 2.

[0272] As shown in the two use cases above, tree membership involves two aspects: a static aspect and a dynamic aspect. The static aspect is the tree membership of fields when using the underlying data model (when they appear in the schema viewer), and the dynamic aspect is which trees are being used (i.e., which fields are being used on the shelf and the current tag card). Using the model example above, the following is an additional example:

[0273] A single tree using shared tree B: dimensions come from logical table 5, and measures come from logical table 7. Although fields in logical tables 5 and 7 belong to trees 1 and 2, they also belong to the same shared tree B, thus this becomes a single tree evaluation. The dynamic or currently used tree aspects for determining relevant measures: relevant measures in tables 1 and 2 because of the shared dimensions in table 5, but measures in table 3 will be unrelevant.

[0274] Use one or more trees, A and B, sharing two trees: dimensions from logical table 4 (of shared tree A) and measures from logical tables 5 and 7 (of shared tree B). There are two possible paths between shared trees A and B: via fact tree 1 or 2. Analysts can choose to map some measures from shared tree B to dimensions in table 4 via fact tree 1 and some measures via fact tree 2. The dynamic aspect regarding which trees are being used depends on the analyst's decision.

[0275] III.B.5. Grayed-out fields in the pattern viewer

[0276] Data administrators and analysts need sufficient information to help decide which fields to use together, but they also don't want to traverse hierarchical structures from tree to table to field, especially when many logical tables can belong to two or more trees. Public Text addresses this need by implementing an improved user interface for the schema viewer with a list of fields that changes the appearance of the fields based on their static tree membership and dynamic aspects about which trees are being used on shelf and tag cards.

[0277] To help analysts determine which fields to draw upon next for their analysis, the exposed pattern viewer user interface (shown in examples in Figures 16, 17, and 18) provides subtle hints about fields that are relevant based on the underlying data model and which fields are already in use. The first of these user interface hints is to gray out fields that are irrelevant and / or not clearly related to the fields on the shelf (e.g., to visually de-emphasize them).

[0278] III.B.6. Related Fields and Fields That May Be Related

[0279] Related fields are fields belonging to logical tables within the same tree. If all fields used on the shelf and tag card belong to only one tree (see example...), then... Figure 14B (As shown in the diagram for tree 1, 2, or 3), all fields belonging to the tree being used are relevant.

[0280] When using from Figure 14A When sharing dimensions in tables 4, 5, or 7, fields belonging to two separate trees (e.g., Figure 14A The measures in Tables 1 and 2 can be made relevant.

[0281] III.B.7. Irrelevant and Uncorrelated Fields

[0282] Unrelated fields are fields that belong to logical tables within a separate tree. The simplest case is when a field belongs to a separate base table (e.g., the root table), meaning that fields in different base tables of the tree are always unrelated to each other.

[0283] However, in a metric-only visualization, unrelated fields are relevant if no dimension is in use, because metric values ​​are aggregated into their respective tables, and Tableau allows metric tags to be juxtaposed adjacent to each other.

[0284] refer to Figure 14A and Figure 14B When using shared dimensions (from Tables 4, 5, or 7), irrelevant measures from Tables 1 and 2 can become relevant. When using dimensions from these separate trees, irrelevant measures from Tables 1 and 3 can become relevant. However, these measures are only aggregated to their respective dimensions within their respective trees.

[0285] When a dimension exists that is in use but does not share any tree with the metric, the irrelevant metric will remain irrelevant. Figure 14A and Figure 14B If the dimensions of Table 3 are used together with the measures of Table 1 and Table 2, then these measures are not correlated because there are no dimensions shared between the two trees.

[0286] III.B.8. Unclear related fields

[0287] When fields belong to the same two or more shared trees, they are not explicitly related because multiple paths can exist connecting them. (Reference) Figure 14A and Figure 14BFor example, shared trees A and B belong to both trees 1 and 2. If a dimension field from table 4 is used, a metric field from table 5 or 7 can be aggregated to the dimension field via table 1 (tree 1) and table 2 (tree 2), or by default, aggregated locally within its table (without using any trees).

[0288] Analysts can eliminate ambiguity by creating Level of Detail (LOD) calculations that include the fields in Table 1 or 2. In some implementations, the data analysis user interface 250 includes UI components to generate these LODs to simplify the elimination of ambiguity regarding aggregation paths.

[0289] III.B.9. Algorithms for Field Correlation

[0290] According to some implementations in the publicly available text, computing device 200 or server 300 is configured to execute algorithms for field correlation. The algorithms include:

[0291] Step 1: Do dimensions exist on the shelf? If not, there's no need to gray out the fields; measures are aggregated in their respective tables.

[0292] Step 2: Do the dimensions share a common tree? If so, evaluate using a single tree (from object model v1): show the inner-connected dimensions and identify all the trees to which these dimensions belong.

[0293] a. Related: The dimensions and metrics of this tree (which can belong to multiple trees, but one of them is actively used), and the aggregation calculations belonging to this tree that is in use.

[0294] b. Irrelevant: Gray out the dimensions and measures of trees that are not in use.

[0295] c. Ambiguous Relevance: Gray out measures (and row-level calculations) that belong to the relevant tree but not to the individual tree being evaluated.

[0296] d. Partially related:

[0297] Step 3: Group the dimensions that share one or more trees, and then evaluate each tree in use using the single tree evaluation described in Step 2. In addition to the relevance logic in Step 2:

[0298] a. Related: Same as step 2

[0299] b. Irrelevant: Same as step 2

[0300] c. Ambiguous Relevance: Gray out metrics (and row-level calculations) belonging to the relevant tree that overlaps with the tree being used in the dimension.

[0301] Step 4: For groups that share one or more tree dimensions, outer join their tree-based tuples together. Use the same relevance logic described in Step 3 above.

[0302] Step 5: For groups that do not share a common tree dimension, cross their dimension tuples. Use the same relevance logic described in Step 3 above.

[0303] III.B.10. Examples of the above experiments

[0304] Figure 15A , Figure 15B and Figure 15C An object model 1500 is shown according to some implementation methods. Figure 15A The inventory tree of object model 1000 is shown. Figure 15B The support tree of object model 1500 is shown. Figure 15C A date object is shown.

[0305] Here are examples of which fields and content should be grayed out in Object Model 1500:

[0306] 1. Measurements only: COUNT (Inventory), SUM (Sales), COUNT (Suppliers)

[0307] 2. Single tree evaluation (inventory), with a related tree (supported): Product Name (Product Table), Supplier Name (Supplier Table), Inventory Type (Inventory Table)

[0308] a. Related trees currently in use: Inventory tree, Support tree (measured from objects shared only with the inventory)

[0309] b. Unrelated trees not in use: Marketing, Sales, Customers

[0310] c. Fields with unclear relevance: (None)

[0311] 3. Single tree evaluation (inventory), but with all related trees: inventory type (inventory table), weekday (date table).

[0312] a. The related tree currently in use: inventory

[0313] b. Unrelated trees not in use: Marketing, Sales, Support

[0314] c. Unrelated fields: Measures in the customer table

[0315] 4. Multiple tree assessments (inventory, support) using shared dimensions: COUNT (inventory), SUM (support hours), supplier name (supplier), product name (product).

[0316] a. Related trees currently in use: Inventory, Support

[0317] b. Unrelated trees not in use: Marketing, Sales

[0318] c. Fields with unclear relevance: Date, Product, Subcategory, Category, Measurement in Supplier

[0319] 5. Multiple tree evaluations (inventory, support), using non-shared dimensions: COUNT (inventory), SUM (support hours), inventory type (inventory), support type (support).

[0320] a. The related tree currently in use: Inventory, Support; cross-linking inventory type and support type

[0321] b. Unrelated trees not in use: Marketing, Sales

[0322] c. Fields with unclear relevance: Date, Customer, Supplier, Product / Subcategory / Measurement within Category

[0323] 6. Multiple tree assessments (inventory, support), using shared and non-shared dimensions: COUNT (inventory), SUM (support hours), vendor name (supplier), product name (product), inventory type (inventory), support type (support).

[0324] a. The relevant tree currently in use: Inventory, Support; inner join: Inventory type + Supplier + Product name; inner join: Support type + Supplier name + Product name; then outer join: these two tree-based results.

[0325] b. Unrelated trees not in use: Marketing, Sales

[0326] c. Unrelated fields: Measurements in date, product, subcategory, category, supplier, and customer fields.

[0327] 7. Multiple tree assessments (inventory, marketing, support), using shared and non-shared dimensions: COUNT (inventory), SUM (support hours), vendor name (supplier), product name (product), inventory type (inventory), support type (support), marketing type (marketing).

[0328] a. The related tree currently in use: Inventory, Marketing, Support; with the same inner joins, the same outer joins, and then cross-joins to the Marketing type.

[0329] b. Unrelated trees not in use: Sales

[0330] c. Unrelated fields: Measurements in date, product, subcategory, category, supplier, and customer fields.

[0331] 8. Multiple tree assessments (inventory, marketing, support) using non-shared methods.

[0332] III.C. Exemplary User Interface for Analysis Based on Multi-Fact Data Models

[0333] Figures 16A to 16H A series of screenshots, based on some implementations, are provided, illustrating user interactions with the data analytics user interface 250.

[0334] Figure 16A A data analysis graphical user interface 250 (e.g., a data visualization user interface) is illustrated according to some implementations. The user interface 250 includes a schema area 1610 (sometimes also referred to as a "schema viewer"), multiple shelf areas 1612 (two shelf areas 1612-1 and 1612-2 are shown in the example), and a data visualization area 1614. In some implementations, the schema area 1610 displays data field icons 1620 (or object field icons) corresponding to data fields (or object fields) of the object model. Each shelf area 1612 is configured to define the corresponding characteristics of the displayed data visualization based on placing the data field icons from the schema area 1610 into the corresponding shelf area 1612. The data visualization area 1614 is configured to display data visualizations. In the example of Figure 16, the object model is a multi-fact object model that includes fact tables "Marketing," "Product," "Sales," and "Region."

[0335] like Figure 16A As shown, each data field icon 1620 in the schema region 1610 is associated with a corresponding object 1616 in the object model (e.g., objects 1616-1 to 1616-4). For example, the data field icons “Marketing Name”, “Marketing Type”, “Marketing Manager”, “Product ID”, “Region ID”, “Activity Spending”, “Activity Budget”, and “Marketing (Count)” are all included in marketing object 1616-1.

[0336] Figure 16B The diagram illustrates user selection of a data field icon 1620-1 from pattern area 1610 corresponding to the data field "Activity Cost", and placement of the data field icon 1620-1 into shelf 1612-1. In some implementations, user selection and placement include drag-and-drop actions.

[0337] Figure 16CThe example illustrates how, in response to a user placing a data field icon 1620-1 into a shelf 1612-1, user interface 250 displays a data visualization 1622 (e.g., a bar chart) in a data visualization area 1614. In this example, data visualization 1622 is generated (e.g., automatically and without user intervention) by aggregating (e.g., summing) all data values ​​(e.g., activity expenses) of the data field "Activity Costs".

[0338] Figure 16C This illustrates, in some implementations, that the computing device updates the visual characteristics (e.g., visual appearance) of one or more data field icons in the pattern area 1610 while displaying the data visualization 1622. Figure 16C In the example, data field icons 1620-2, 1620-3, and 1620-4 are visually de-emphasized (e.g., grayed out) relative to other data field icons 1620 in pattern area 1610. Data field icon 1620-2 corresponds to the data field "Product Name" (e.g., a dimension field) in sales object 1616-3. Data field icon 1620-3 corresponds to the data field "Sales Type" (e.g., a dimension field) in sales object 1616-3. Data field icon 1620-4 corresponds to the data field "Region Name" (e.g., a dimension field) in sales object 1616-3.

[0339] In the example, when a user places data field icon 1620-1 "Activity Spending" on shelf area 1612, data field icons 1620-2, 1620-3, and 1620-4, corresponding to the dimension fields "Product Name," "Sales Type," and "Region Name" in the sales object, turn gray. This is because the dimension field "Sales Type" is separate from "Activity Spending," meaning it's impossible to break down activity spending (i.e., the amount of money spent in the marketing campaign) by sales type (e.g., because no sales were made during the marketing campaign). Grayed-out fields, or fields with subtle hints, are prompts from data visualization applications to guide users in a specific direction for their analysis.

[0340] In some cases, when analyzing complex multifact data models, analysts may not be able to easily identify the relevant fields to use. Once they begin their analysis, they may overlook both relevant and irrelevant content. Figure 16C By visually de-emphasizing fields irrelevant to the current analysis, a simple yet informative approach is presented to guide analysts in fully utilizing multi-fact data models. Here, because shelf area 1612 contains only measure-only fields (e.g., activity spending), dimension fields in irrelevant facts are grayed out.

[0341] Figure 16DThe diagram shows the user selection of the data field icon 1620-5 corresponding to the object field "Product Name" in product object 1616-2, and the placement of the object field icon 1620-5 in shelf area 1612. Figure 16E The user interface 250 displays an updated data visualization 1624 in response to the user placing object field icons 1620-5 into shelf area 1612, which includes a bar chart in which the total marketing expenditure is broken down by product “telephone”, “laptop” and “charger”. Figure 16E It also shows how, while displaying data visualization 1624, the visual characteristics of data field icons 1620-2, 1620-3, and 1620-4 are simultaneously displayed. Figure 16C The grayed-out appearance in the data has been updated to a regular font with icons similar to those of the other data fields in pattern area 1610. The sales dimension is no longer grayed out because people can now break down sales by product type.

[0342] Figure 16F The diagram shows the user selection of data field icon 1620-6 corresponding to the measurement field "Total Sales" from sales object 1616-3, and the placement of data field icon 1620-5 into shelf area 1612.

[0343] Figure 16G The example illustrates how, in response to a user placing object field icons 1620-6 into shelf area 1612, user interface 250 displays an updated data visualization 1626. In this example, the data visualization includes two bar charts showing total activity spending by product name and total sales by product name. These two bar charts share a common vertical axis: product name.

[0344] Figure 16H It shows the corresponding Figures 16A to 16G Example data model 1626. Data model 1626 includes a marketing root table (e.g., a fact table) (i.e., marketing object 1616-1) and a sales root table (e.g., a fact table) (i.e., sales object 1616-3), which are related through a product logical table (i.e., product object 1616-2) and a geographic logical table (i.e., geographic object 1616-4).

[0345] In the example in Figure 16, marketing can be broken down by product (i.e., product object 1616-2) and region (i.e., region object 1616-4). Sales can also be broken down by product and region, but marketing and sales are unrelated to each other. Therefore, when analysts specify fields from marketing, the data visualization displays fields from sales in grayscale because marketing and sales are separate fact tables. However, once analysts specify common fields between marketing and sales, it becomes possible to connect these two root tables through these common fields.

[0346] Figures 17A to 17E A series of screenshots, based on some implementations, are provided, illustrating user interactions with the data analytics user interface.

[0347] Figure 17A A view of the user interface 250 is shown. Details of the user interface 250 (including the schema area 1610, shelf area 1612, data visualization area 1614, objects 1616, and data field icons 1620) are shown in... Figure 16A It has been described in the text, and for the sake of brevity, it will not be repeated here.

[0348] Figure 17B The diagram illustrates a user selection of a data field icon 1620-5 corresponding to the field "Product Name" (e.g., a dimension field) from product objects 1612-5, and the placement of the data field icon 1620-5 into shelf area 1612. In response to the user placing the data field icon 1620-5 into the shelf area, a data visualization 1702 is displayed in data visualization area 1614. In this example, the data visualization is a text table with rows corresponding to the data values ​​of the object field "Product Name" (e.g., the name of the product, such as "telephone," "laptop," and "charger").

[0349] Figure 17B It also illustrates how the computing device updates the visual characteristics (e.g., visual appearance) of the data field icons 1620-7 to 1620-11 corresponding to the geographic object 1616-4 in the pattern region 1610 while displaying the data visualization 1702. Figure 17C In the example, data field icons 1620-7 to 1620-11 are visually de-emphasized (e.g., grayed out) relative to other data field icons 1620 in pattern area 1610. In the example, because the only field in shelf area 1612 is "Product Name," which is a dimension field, dimensions and measures in irrelevant facts are grayed out. Figure 17B In the text, the grayed-out dimension fields are "Region Name" and "Region ID". The grayed-out metric fields are "Population", "Region Size", and "Region (Count)".

[0350] Figure 17CIn response to user interaction with data field icons 1620-11 (e.g., “Region (Count)”), such as user selection or mouse hover, user interface 250 displays tooltip 1704, which includes information (e.g., guidance) indicating that the “Product Name” field is not related to the “Region (Count)” field. Tooltip 1704 also includes the note “Shows duplicate values ​​through multiple path-related metrics,” meaning that if the user places the “Region (Count)” field in shelf area 1612, all possible combinations between the data values ​​of the “Product Name” field and the data values ​​of the “Region (Count)” field will be shown.

[0351] This is designed so that analysts gain enough information from tooltips to decide whether to proceed. As analysts continue to explore the data model, the relevance of fields changes with user input.

[0352] Unlike other business intelligence (BI) tools that don't offer visibility into the underlying mechanisms, publicly disclosed data visualization applications explain to analysts why a particular field is grayed out. Therefore, some implementations of publicly disclosed text provide an improved user interface for managing user expectations, ensuring that users are not confused or frustrated by the results after selecting a specific data field.

[0353] Based on some implementations in the publicly available text, data field icons for fields that have been grayed out remain selectable by the user. This is in... Figure 17D The image shows an updated visualization 1706 displayed in response to a user selection of data field icon 1620-11 and placement of icon 1620-11 on the shelf area. Visualization 1706 is a bar chart of region counts by product name, where each of the product names "Telephone," "Laptop," and "Charger" shows the same region count. Because region counts cannot be broken down by product name, the region count value is copied (e.g., repeated) for each product name.

[0354] Figure 17D and Figure 17E It is also shown that in some implementations, the pills in shelf area 1612 (such as pills 1710 and 1712) include corresponding indicators 1708 that, when interacted with by the analyst, display information about which fields used in the analysis are relevant and which are irrelevant, allowing the analyst to return to and refine their analysis. For example, Figure 17EThe user interface 250 shows a tooltip 1714 that, when an analyst interacts with (e.g., hovers over) the indicator 1708-1 corresponding to the unrelated field “Region (Count)”, the user interface 250 displays to the analyst a reminder that the field “Region (Count)” is unrelated to the field “Product Name” (e.g., information similar to that provided by tooltip 1704).

[0355] In summary, analysts can access all field information in the tooltips to inform them about specific fields and their relevance to their analysis.

[0356] In some implementations, if a field exceeds the limits that can be caused by the field size and / or its use with unrelated fields, the analyst is also notified of a cardinality issue.

[0357] Figures 18A to 18I A series of screenshots, based on some implementations, are provided, illustrating user interactions with the data analytics user interface.

[0358] Figure 18A A view of user interface 250 is shown, with details of user interface 250 (including schema area 1610, shelf area 1612, data visualization area 1614, objects 1616, and data field icons 1620) in... Figure 16A It has been described in the text, and for the sake of brevity, it will not be repeated here.

[0359] Figure 18B The diagram shows the user selection of the data field icon 1620-12 corresponding to the data field (e.g., the object field) "Marketing Type" in the marketing object 1616-1, and the placement of the data field icon 1620-12 in the shelf area 1612.

[0360] Figure 18C The user interface 250 displays a data visualization 1802 (e.g., a text table) in response to placing data field icons 1620-12 into shelf area 1612. The rows of the text table are data values ​​for the marketing type of the data fields (e.g., "online" and "print"). Simultaneously, the computing device visually de-emphasizes all data field icons corresponding to sales object 1612-3 (i.e., data field icons 1620-2, 1620-3, 1620-4, 1620-13, 1620-14, and 1620-15).

[0361] Figure 18DThe user interface 250 displays an updated data visualization 1804 (e.g., a bar chart) in response to a user selection of a data field icon 1620-1 corresponding to the data field "Activity Spending" from pattern area 1610, and the placement of the data field icon 1620-1 into shelf area 1612. In this example, data visualization 1804 shows a breakdown of activity spending amounts by marketing type (e.g., online and print). Figure 18D The icons for all data fields of sales object 1612-3 continue to turn gray.

[0362] Figure 18E In response to user interaction with the data field icon 1620-3 corresponding to the data field "Sales Type" (e.g., user selection or mouse hover), user interface 250 displays tooltips 1806, which include information indicating that the field "Sales Type" is not related to the fields "Activity Spending" and "Marketing Type" (e.g., guidance) and information that all possible combinations will be displayed when the field "Sales Type" is used.

[0363] Figure 18F The user interface 250 displays an updated data visualization 1808 when the user selects the data field icon 1620-3 in the pattern area 1610 and places it in the shelf area. Data visualization 1808 is a bar chart of campaign spending by marketing type and sales type. Because campaign spending cannot be broken down by sales type, the computing device generates data visualization 1808 by: (i) repeating (e.g., copying) campaign spending for online marketing for each of the sales types “cash,” “credit card (CC),” and “cheques,” and (ii) repeating (e.g., copying) campaign spending for print marketing for each of the sales types “cash,” “credit card (CC),” and “cheques.”

[0364] Figure 18F It was also shown that after placing the data field icon 1620-3 in the shelf area, the data field icon of the sales object 1612-3 no longer turned gray.

[0365] Figure 18F and Figure 18G The user interface 250 displays a tooltip 1812 when the user hovers over the indicator 1708-3 displayed next to the pill 1810 shown in the sales type section. The tooltip reminds the user that the fields “sales type” and “activity cost” are not related and show duplicate values.

[0366] Figure 18HThe user interacts with the data field icons 1610-13 corresponding to the field "Total Sales" (e.g., selecting or hovering over them). In response to user interaction, the user interface displays tooltips 1814 with guidance / warning information.

[0367] Figure 18I The computing device generates data visualization 1816 in response to user selection of data field icons 1610-13 from pattern area 1610 and the placement of the icons in the shelf area. The data bars on the left side of visualization 1816 are the same as those in data visualization 1808. The right side 1818 of data visualization 1816 shows the total sales breakdown by marketing type and by sales type. Because sales type and total sales are related (i.e., they are both data fields in the marketing logic table), the computing device is able to determine the corresponding total sales for each sales type (cash, credit card, and check). Because total sales are not related to marketing type, the computing device repeats the corresponding total sales obtained for the corresponding sales type for each data value of the "marketing type" field.

[0368] IV. Query Semantics for Multi-Fact Data Models

[0369] Some aspects of the disclosed implementation extend the semantics of the current Tableau data model to support multi-fact analysis by enabling the aggregation of measures from multiple fact tables into shared dimensions in different tables within the same visualization (see [link to implementation details]). Figure 4A This feature enables the analysis of data models with multiple snowflake patterns (where they share common objects).

[0370] Refer again Figure 4A As an example, one drawback of existing data models is that analysts cannot aggregate measures from different, separate fact tables (e.g., inventory 402 and sales 404) into a common dimension (e.g., dimension date 406 and dimension site 408). To compare data from separate fact tables using existing data models, analysts must generate visualizations corresponding to each fact table and juxtapose them on a data dashboard.

[0371] The proposed technical solution to this problem preserves the current flexibility of existing data models while expanding their capabilities. The solution balances the workload required by the data modeler and limits the amount of additional properties allocated to the new multi-fact data model, thereby increasing analytical capabilities without requiring more user input.

[0372] IV.A. Feature Target

[0373] Some implementations of the public text extend the semantics of the current object model to support multiple snowflake patterns (where they share common objects that can be created using the data model).

[0374] Some implementations of the public text update query generation to enable standalone tree-based queries. In some implementations, row-level metrics are evaluated via a tree. Some implementations support all existing row-based computations, such as hierarchy of details (LOD) computations and computations using combined fields and / or multidimensional sets.

[0375] Some implementations of the publicly disclosed text add query generation to allow merging individual tree-based queries together. In some implementations, the disclosed devices, methods, and / or user interfaces enable (i) the aggregation of metrics across multiple trees, (ii) shared dimensions between outer join trees, and / or (iii) non-shared dimensions between cross join trees.

[0376] Some implementations of the publicly available text impose / restrict on query generation for cross-joining irrelevant fields. In some implementations, the disclosed devices, methods, and / or user interfaces remind users not to use irrelevant dimensions from different groups of facts. In some implementations, the disclosed devices, methods, and / or user interfaces remind users not to use inaccessible dimensions from metrics.

[0377] IV.B. Query semantics for a single fact table (object model v1)

[0378] This section discusses query semantics in the case of a single fact table.

[0379] The goals of query semantics include:

[0380] Appropriate metric aggregation: We want all metrics to be aggregated at their natural granularity to avoid duplication.

[0381] Keep all measures: Adding dimensions should not cause us to lose measure values, even if the measure values ​​do not have corresponding dimension values.

[0382] Maintain all dimensions: Adding measures should not cause us to lose dimension values, even if some parts of the domain do not have corresponding measure values.

[0383] One of the goals of data visualization applications is to generate queries that include dimensions, aggregate measures, and / or filters. Some of these field and filter inputs can be calculations, and the data visualization application has formulas for these calculations.

[0384] IV.B.1. Query Generation Algorithm

[0385] Figure 19A The query generation algorithm is illustrated. At a higher level, the query generation algorithm includes:

[0386] Step 1 - Construct Dimensional Subqueries: Create a table consisting of dimensions. We call this query a dimensional subquery.

[0387] Step 2 - Constructing Metric Subqueries: For each aggregate metric, create a subquery consisting of the dimension and a single aggregate metric to which the filter is applied. We call these queries metric subqueries.

[0388] Step 3 - Combining Subqueries: Combining Dimension and Metric Subqueries

[0389] IV.B.1.a. Constructing Dimensional Subqueries

[0390] Figure 19B The process of constructing a dimension subquery is shown (step 1 of the query generation algorithm).

[0391] For this part of the algorithm, we first perform an inner join of all objects needed to compute dimensions and filters. Generally, a set of objects required for a set of dimensions, filters, and / or measures is a minimal subgraph containing all objects that have at least one object field required to compute dimensions, measures, or filters. Then, we stack the computations, followed by the filters. We only stack the computations required for computed dimensions and filters. Finally, we perform grouping operations by dimension. If the query does not have a measure, the operation is complete.

[0392] The purpose of dimensional subqueries is to ensure that we preserve all dimension values ​​that will appear in dimension-only queries.

[0393] A noteworthy special case is the query without dimensions. In this case, we generate a query for Table Dee—a table with one row and an empty schema.

[0394] Roughly speaking, connecting a table to a Table Dee produces the original table.

[0395] IV.B.1.b. Constructing metric subqueries

[0396] A metric query consists of a set of dimensions and a single aggregate metric.

[0397] The crux of object model algorithms lies in creating a table containing measures and dimensions (called a "pre-aggregation table"), in which filters are applied so that aggregation can be safely applied.

[0398] The process of constructing the pre-aggregation table is the most challenging part of the object model algorithm because it not only strives to preserve all metric values ​​but also to recover mismatched dimension values ​​as much as possible.

[0399] Assuming we know the primary key of each object, we can then construct a pre-aggregated table using the following steps:

[0400] ● Create an object connection tree: Connect objects together to create an object connection tree.

[0401] ● Add computed calculations and filters to the object connection tree: Add computed calculations and filters at the top of the object connection tree.

[0402] ●Result Deduplication: Deduplicativity is achieved by deriving duplicates from the object join tree using the primary key and dimension of the metric objects. The goal of this step is to ensure that the metric remains at its natural granularity level.

[0403] When we deduplicate a query using a set of deduplication fields, we are asserting that for each combination of the deduplication fields, there is only one combination of the remaining fields. In other words, the deduplication fields uniquely identify the remaining parts of the field.

[0404] The query we computed performed a GROUP BY operation on the deduplication field and an ANY aggregation on the remaining fields.

[0405] While actual pre-aggregation queries are not always this simple, their purpose is to simulate the semantics of the query structure when information is incomplete.

[0406] exist Figure 19C The diagram illustrates the process of constructing a metric subquery.

[0407] i. Create an object connection tree

[0408] We define the metric core as a set of objects required to obtain all object fields of the metric for a subquery. Currently, we are using an inner join with the objects in the metric core.

[0409] The metric core defines the granularity of the pre-aggregated table and the set of metric rows we want to maintain.

[0410] We want to preserve the rows in the metric core by making left joins to the remaining objects. This may result in mismatched dimension values—which appear as null values.

[0411] For example, we might be aggregating sales by state, where a particular sale has a missing / unknown state. A left join would ensure we retain all sales, but the state would be represented as null.

[0412] ii. Query optimization - Referential integrity

[0413] Recall that we performed left joins relative to the metric core to avoid missing rows in the metric core. By setting referential integrity for the relations, we can eliminate some of these left joins.

[0414] In other words, we can extend the core of our inner-joined objects along the relationships, and the referential integrity information of these relationships indicates that we always have a match relative to the metric core.

[0415] In the example above, if the relation indicates that every row in object 1 has a match in object 2, then we can reduce the subquery all the way down to... Figure 19D As shown in the figure.

[0416] iii. Application calculations and filters

[0417] We apply calculations and filters at the top of the object connection tree.

[0418] The key semantics in this field are:

[0419] ● Computations at the top of the join: Computations (and filters) are applied at the top of the object join tree. This means they operate on top of null values ​​introduced from the metric core by the left join. For example, a computation defined as IFNULL([field], "Foo") will return "Foo" if the underlying field returns a non-matching null value.

[0420] ● Forced Filters: We always apply all filters. This means that adding filters may require additional objects to be included. Note: We have already determined that we need the input objects of the filters when calculating the object join tree. See the next section for more details. For example, if we have a query that only uses fields from orders, but has a filter about states, we will include states (and intermediate objects in the join path).

[0421] iv. Deduplication steps

[0422] In practice, we don't always have primary key (PK) or cardinality information. The general algorithm for creating pre-aggregated tables roughly creates pseudo-PKs, which can be used to join dimension objects to the metric core without causing undue duplication.

[0423] IV.B.1.c. Combining Dimensions and Metric Subqueries

[0424] Figure 19E The steps for combining subqueries are shown.

[0425] We use the dimension as the join key to perform a full outer join on each subquery, one at a time.

[0426] After each connection, we replace each dimension value with a merged value of the dimensions across both sides of the connection. We use these merged dimensions for subsequent connections and in the result set.

[0427] Semantically, outer joins and merges combine the dimensions of the entire subquery. For this special case of joins and merges, the order in which we join the subqueries is irrelevant.

[0428] Figure 19F This shows an outer join performed on two tables. Mismatched metrics are assumed to be null (except for COUNT / COUNTD, which has an estimate of 0).

[0429] IV.B.1.d. Query fusion optimization

[0430] In some instances, we can avoid outer join subqueries by combining subqueries into a composite subquery.

[0431] In some instances, we can avoid outer join subqueries by combining subqueries into a composite subquery.

[0432] For example, if we detect that two metric subqueries with the same set of dimensions operate on a join tree with specific properties, we replace these subqueries with a new subquery that exposes the combined group metric.

[0433] exist Figure 19G The query fusion optimization process is shown in the figure.

[0434] IV.B.1.e. Query Generation Example

[0435] This chapter will illustrate this using an example of a supermarket model, such as... Figure 20A As shown.

[0436] We want to compute the metric subquery for the pre-aggregated table to be:

[0437] Measurement = {Count([Order ID])}

[0438] Dimension = {[Customer Age Group]}

[0439] The filter is set to {[order amount including tax] >= 50}, where [order amount including tax] is calculated using the formula [order amount] * (1 + [state tax rate]).

[0440] The complete algorithm for creating a pre-aggregate table via deduplication is as follows:

[0441] Step 1: Obtain all the object fields needed for dimensions, measures, and filters. Define the object field subgraph as the smallest subgraph containing all of these fields.

[0442] For the rest of the algorithm, we can ignore all objects that are not in the object field subgraph.

[0443] For the metric, the object field used is the [Order ID] from the order.

[0444] For the dimensions, the object field used is from the customer's [customer age group].

[0445] For the filter, the object fields required for the internal calculation are [order amount] from the order and [state tax rate] from the state.

[0446] Therefore, the object field subgraph is {order, customer, address, state}, as shown below. Figure 20B As shown. For the rest of the example case, we can ignore the existence of {specific projects, products}.

[0447] Step 2: Define the metric core as the smallest subgraph that contains all the object fields required to compute the metric.

[0448] The measurement core is very important because it encodes both the granularity of what is being measured and the set of measurement lines we need to maintain.

[0449] Based on our analysis in step 1, the metric only requires the order object, which is the core of the metric.

[0450] Step 3: For all dimensions and filters not fully contained in the metric kernel, compute the minimum subgraph that satisfies the following condition:

[0451] A. Object fields that contain them

[0452] B. Contains at least one object from the metric core.

[0453] We call the subgraph a dimension-metric subgraph.

[0454] Note: If all dimensions and filters are fully contained within the metric core, then there will be no dimension-metric subgraph.

[0455] The goal of the dimension-measure subgraph is to add all dimensions and filters that are not in the measure core to the measure core in a controlled manner.

[0456] As we will see later in steps 5 and 8, objects from the metric core are crucial for preserving the computational semantics we expect and for reconnecting the two subgraphs.

[0457] Neither the dimensions nor the filters are fully contained within the metric core. Dimensions require customers, and filters require orders and states. The dimension-metric subgraph is {orders, customers, addresses, states}. Since the graph shares objects with the metric core (orders), the graph itself is sufficient.

[0458] Step 4: Create a compiled metric subgraph by connecting all objects in the metric core. Then, add computations and filters that depend only on objects in the metric core.

[0459] The compiled metric subgraph is merely a query representation of the orders.

[0460] If no dimension-metric subgraph exists, the operation is complete.

[0461] Step 5: Create a compiled dimension-metric subgraph by inner-joining all objects from the metric core. Then, left-join the rest of the objects.

[0462] Next, add computations and filters that are fully contained within the objects in the dimension-metric subgraph.

[0463] In a dimension-measure subgraph, a metric core object exists that stores the semantics of computations performed on top of null values ​​introduced by left connections relative to the metric core.

[0464] The order is the only object from the metrics core. We left-join the rest of the object to the order. Then, we overlay calculated fields by creating new fields using the formulas of the calculated fields. Finally, we overlay filters.

[0465] exist Figure 20C The compiled dimension-metric subgraph is shown in the figure.

[0466] Step 6: Define the link field as a union of the following items:

[0467] The relation keys that connect the metric objects in the dimension-metric subgraph to the rest of the subgraph. We pick the keys from the metric-object side.

[0468] For filters and dimensions across the rest of the metric core and object field subgraph, the object field falls within the metric core.

[0469] The relationships connecting the metric objects to the rest of the dimension-metric subgraph are (order, customer) and (order, address). The keys from these relationships on the order side are {[customer FK], [address FK]}.

[0470] Although the dimension does not cross into the metric core, the filter's input calculation has an input field that falls within the order. The field is {[order amount]}.

[0471] Therefore, the link key is {[customer FK], [address FK], [order amount]}.

[0472] Step 7: Deduplicate the compiled dimension-metric subplot using the dimension and link fields.

[0473] We added the dimension [Customer Age Group] to the link field to remove duplicates. Figure 20D The deduplicated, compiled dimension-metric subgraph is shown.

[0474] Step 8: In the simplification algorithm, Step 7 is similar to the deduplication step. Unlike the simplification algorithm, we cannot place all metric core objects under the deduplication step. Without a primary key, we may not be able to create grouping operations that maintain the same granularity of the metric core.

[0475] Instead, we kept the measurement core separate in the previous steps. Now, we combine the two compiled subgraphs in a way that prevents duplication and avoids losing the granularity of the measurement core due to overly coarse grouping operations.

[0476] Specifically, an inner join is performed on the link field between the compiled metric subgraph and the deduplicated compiled dimension-metric subgraph.

[0477] Essentially, the steps function similarly to a self-connection between the metric objects appearing in the metric core and the metric objects appearing in the dimension-metric subgraph.

[0478] Since the non-metric core object is left-joined onto the metric core object, the inner join does not cause any rows to be dropped unless a filter is applied (in which case, the dropped rows are compliant with the design).

[0479] The join field acts similarly to a quasi-primary key (PK) to ensure that dimension-metric subqueries do not introduce duplicates. The intuitive idea here is that if a dimension-metric subquery is grouped only by the join field, the table will have a many-to-one relationship relative to the metric core.

[0480] We effectively perform self-joins on orders in both the metric core and the dimension-metric subgraph. This results in... Figure 20E The final query is shown in the image.

[0481] Query optimization - cardinality

[0482] Given a general model with all many-to-many relationships, the above deduplication steps are correct.

[0483] The cost of correctness is adding at least one metric object twice and performing a deduplication grouping operation. For a simple model with a metric from one object and a dimension from another object, we obtain... Figure 20F The query shown in the image.

[0484] In certain situations, we can use cardinality information to reduce these costs.

[0485] To discuss these two optimizations, we will use... Figure 20GThe image shows a simplified version of a supermarket model.

[0486] Here, we use cardinality information to reason about how connecting one object to another affects the granularity of the first object.

[0487] Optimization 1:

[0488] We can extend the measurement core along the edges of many-to-one and one-to-one relationships. This is because attaching objects does not change the relative cardinality of the measurement core.

[0489] This optimization is very effective because, in the case of snowflakes, if the metric is at the root, it can completely eliminate grouping operations.

[0490] Suppose we use a metric from orders and a dimension from states. Joining states to orders does not increase the cardinality of orders, so we can simplify the query to... Figure 20H The query shown in the image.

[0491] Optimization 2:

[0492] Here, we use cardinality information to attempt to extract the primary key. If the relation clause is on one side of the relation, we can infer that the relation clause is the primary key.

[0493] When deduplicating a dimension-metric subgraph, we can do so based on the metric objects within the subgraph and the primary keys of the dimensions. This differs from the basic algorithm, which deduplicates by linking fields and dimensions.

[0494] At this point, the dimension-measure subquery is at the granularity of its contained measure objects.

[0495] This means we only need to connect metric objects from the metric core that are not yet included in the dimension-metric subgraph. In the best case, this could mean that the deduplicated dimension-metric subgraph is the entire query.

[0496] Suppose we use a metric from the state and a dimension from the order. By bringing one side of the relationship into the state, we can extract the state's primary key. Deduplication using this primary key (and dimension) ensures we won't have undue duplicates. Therefore, we don't need to join to the state again, so we can simplify our subquery to... Figure 20I The subquery is shown in the image.

[0497] IV.B.1.f. Example of a Measurement-Dimension Subgraph

[0498] Figure 21A , Figure 21B and Figure 21C The dimension-metric subgraph is shown according to some implementation methods.

[0499] Figure 21A It begins with the object field subgraph {A, B, C} and the metric core {A}. Dimensions depend on {B} and {C}, which are not in the metric core. The smallest subgraph containing these dimensions is {A, B, C}. The operation is complete because the subgraph contains objects from the metric core.

[0500] Figure 21B We begin with the object field subgraph {A, B, C, D} and the metric core {A, D}. Dimensions depend on {B} and {C}, which are not in the metric core. The smallest subgraph containing these dimensions is {A, B, C}. Since the subgraph contains objects from the metric core, the operation is complete. In this case, we don't need to import the entire metric core; we only need to import A.

[0501] Figure 21C It begins with the object field subgraph {A, B, C, D} and the metric core {A, B}. Dimensions depend on {D} which is not in the metric core. The smallest subgraph containing these dimensions is {D}. Subgraphs do not include objects from the metric core. The smallest subgraph containing both dimensions and the metric core is {B, C, D}.

[0502] IV.C. Query Semantics for Multi-Fact Object Models

[0503] This section describes how the query semantics described in previous sessions for a single fact table can be extended to include analysis of multiple fact tables.

[0504] IV.C.1. Scenario 1: Query semantics of a single tree object model (single fact table) (object model version 1)

[0505] When all fields in the visual specification share a common tree and all fields from non-shared objects come from the same tree, use the existing object model semantics. See Section IV.B.

[0506] IV.C.1.b. Scenario 2: Query Semantics for Multi-Fact Object Models

[0507] This chapter refers to the Multi-Fact Object Model 2200 for discussion, such as... Figure 22 As shown.

[0508] To reiterate some of the nomenclature used in the public text, each tree has a root table. The root table always starts from the leftmost side of the object model. A shared tree is a tree that can be traced back to two or more roots. A shared tree does not contain any root table.

[0509] exist Figure 22 In this context, the product (logical table 7) is a shared tree because the product can be traced back to the marketing root table (logical table 1), the sales root table (logical table 2), and the support root table (logical table 3).

[0510] When an object is determined to be a shared object, any object to the right of the shared object is part of the shared tree that contains the object. (Return to reference) Figure 22 Because the product (logical table 7) is a shared object, and the subcategory (logical table 9) and category (logical table 10) are to its right, the product (logical table 7), subcategory (logical table 9), and category (logical table 10) belong to their own tree (e.g., a shared tree). Recall that in Figure 14A In this context, a shared tree refers to a tree that does not include the root object.

[0511] exist Figure 22 In this example, the date (logical table 4) is also a shared tree. The date is also a tree of itself.

[0512] "Shared" or "non-shared" is an inherent property of the object model. Every object in the object model is either shared or non-shared. An exception is when a dimension can be collapsed into a tree (see the example in Scenario 1 in Table 1 below) to maintain backward compatibility. Dimensions collapsed into a tree are considered non-shared.

[0513] Tree traversal is directional. When we trace back to the root, we can only traverse in the left direction. Figure 22 In the middle, the parts (logic table 6) are not a shared tree because when traversing in the left direction, they can only be traced back to a root.

[0514] The following are some standard scenarios where measures come from different fact tables and shared dimensions can be used to compare measure results. (Reference) Figure 22 Let's discuss these scenarios.

[0515] Scenario 2.1 Non-shared dimensions from a tree: collapse into the same semantics as object model v1.

[0516] ● Figure 22 Examples of non-shared dimensions in the tree are D1, D2, D3, and D6. They belong to different trees.

[0517] ●Although D4 is a shared dimension, if D1 and D4 are used together, they will collapse into a single tree.

[0518] ● Similarly, if a query uses D1, D4, and D7, these dimension fields will also collapse into a single tree and be treated as if they were part of a single tree. Even though D4 can be traced back to Tables 2 and 3, if the query does not retrieve fields from these root tables, D4 is anchored back to the single tree with D1.

[0519] ●Connection type: Intraconnection

[0520] For example, an inner join of D1 and D4; or an inner join of D1, D4 and D7.

[0521] ● As another example, imagine analysts start with D1, D4, and D7. Later, they decide to add D2 and / or D3. Queries / analyses generated before the introduction of D2 and / or D3 will behave as if D1, D4, and D7 were part of a single tree.

[0522] Scenario 2.2 Non-shared dimensions from multiple trees: First, inner join the dimensions from the same tree, then cross join the dimensions from different trees.

[0523] ●According to Figure 22 Exemplary non-shared dimensions from multiple trees are: D1, D2, D3, and D6.

[0524] ●Taking D2 (e.g., sales type) and D3 (e.g., support type) as examples, we:

[0525] ○ Use sales type inner joins to connect all dimensions in the sales tree (Result 1)

[0526] ○ Use supported type inner joins to support all dimensions in the tree (Result 2)

[0527] ○ Cross-connection results 1 and 2

[0528] Scene 2.3 Shared dimension from a single shared tree: Inner joins are performed within the shared dimension.

[0529] ●According to Figure 22 Exemplary shared dimensions from a single shared tree are: D7, D9, and D10.

[0530] ●Connection Types: Inner Joins (These Dimensions)

[0531] Scene 2.4 Shared dimensions from multiple shared trees: If these dimensions are evaluated as shared across different trees, cross-connects are performed across trees.

[0532] ●According to Figure 22 The shared dimensions from multiple shared trees are: D4, D5, and / or D7.

[0533] ● Multiple shared trees share multiple shared roots, so they remain ambiguous. Therefore, we use cross joins.

[0534] ● If D9 or D10 is also specified, these dimensions will first be inner-joined with D7 to obtain the inner-join result (result A). Result A will then be cross-joined with D4 and / or D5.

[0535] Scene 2.5Shared and non-shared dimensions in a tree: Inner joins are performed within the tree (same semantics as object model v1).

[0536] ●Example: D1 and D4.

[0537] ●Join type: Inner join D1 and D4. This collapses into a single tree.

[0538] Scene 2.6 Shared and non-shared dimensions in multiple trees: Inner joins are performed using the non-shared dimensions in each tree, and then outer joins are performed using the shared dimensions between the trees.

[0539] ●Example: D1 and D5. Because D1 does not share with D5, these two dimensions will be cross-connected.

[0540] Scene 2.7 Non-shared metrics. Recall that the query generation algorithm in Chapter IV.B.1 includes the following three steps:

[0541] Step 1 - Construct dimensional subqueries (to obtain dimensional cores).

[0542] Step 2 - Constructing metric subqueries

[0543] Step 3 - Combinatorial Subquery

[0544] Scenario 2.1 through 2.6 above involve dimensional subquery construction (step 1 of the query generation algorithm). If a metric is specified (e.g., in a visual specification), a metric subquery is generated for the metric. The subquery depends on whether the metric is shared or non-shared.

[0545] ● Scene 2.7a Non-shared dimensions from a tree + non-shared metrics: use the same query semantics as object model v1.

[0546] ● Scene 2.7b Non-shared dimensions from multiple trees + non-shared measures: Aggregate measures to non-shared dimensions from the trees, and then copy the entire measure (without dimensions) to non-shared dimensions in other trees.

[0547] ● Scene 2.7c Shared dimensions from a single shared tree + non-shared metrics: Applying scenario 2.7b to shared dimensions

[0548] ● Scene 2.7d Shared dimensions from multiple shared trees + non-shared measures: Aggregate measures to shared dimensions within the tree, then copy the entire measure (without dimensions) to other trees.

[0549] ● Scene 2.7eShared and non-shared dimensions in a tree + non-shared metrics: Same as scenarios 2.7b and 2.7d.

[0550] ● Scene 2.7f Shared and non-shared dimensions in multiple trees + non-shared metrics: Same as scenarios 2.7b and 2.7d.

[0551] Scenario 2.8. Shared metrics. Shared metrics are metrics that belong to different trees.

[0552] ● Scene 2.8a Non-shared dimensions from a tree + shared measures: Use OM v1 to aggregate measures into non-shared dimensions.

[0553] ● Scene 2.8b Non-shared dimensions from multiple trees + shared measures: Aggregate measures to non-shared dimensions within the tree (using OM v1), then copy the measures (without dimensions) to other trees.

[0554] ● Scene 2.8c Shared dimension from a single shared tree + shared metric: Copy the metric (without dimension) to the shared dimension.

[0555] ● Scene 2.8d Shared dimensions and shared metrics from multiple shared trees: Same as scenario 2.8c

[0556] ● Scene 2.8e Shared and non-shared dimensions in a tree + shared metrics: Same as scenarios 2.8b and 2.8c.

[0557] ● Scene 2.8f Shared and non-shared dimensions in multiple trees + shared metrics: Same as scenarios 2.8b and 2.8c.

[0558] Scene 2.9 Filter.

[0559] ● When a filter is applied to a shared dimension, the filter is applied whenever facts about the shared dimension are introduced into the query.

[0560] ● As an example, apply the filter to "customer name" (e.g., Figure 22 (D5 in the table). Because "Customer Name" is a dimension field shared by both Sales (Logical Table 2) and Support (Logical Table 3), a filter is applied whenever a metric is introduced from Sales or Support.

[0561] ● As another example, if the filter is applied to "sales type" (e.g., Figure 22 In D2 of the table, because "Sales Type" is a non-shared dimension, the filter is limited to facts in the sales table.

[0562] Scene 2.10 Ambiguous situations. Suppose the query is for "product counts for different months". Figure 22 In this context, because products are shared with marketing, sales, and support, product counts for different months can be targeted at marketing, sales, or support. For the example, because there are multiple paths to the core of a dimension, the computing device (e.g., data visualization application 230) resolves the query by: locally aggregating within the product table to obtain the total product count, and then replicating the total product count for each dimension associated with marketing, sales, and support.

[0563] IV.C.1.bi Multi-fact model query semantics example

[0564] This chapter will illustrate this using examples from Object Model 2300, such as... Figure 23 As shown, Sales and Marketing are two distinct trees in object model 2200. They share the characteristics of Date and Category. The data values ​​for the Category are "Shipping" and "Equipment". Marketing includes the dimension field "Marketing Type".

[0565] Figure 24A The table corresponding to object model 2200 is shown, based on the shared dimension date. The first table; the shared dimension is date. Sales by category occur in January, March, and April. Marketing spending occurs in January, February, March, and May. Outer join semantics are used in this example.

[0566] Figure 24B This shows a data visualization (e.g., a text table) generated when the query consists only of metric fields (i.e., no dimension fields). Note that there is no further breakdown of the metric values.

[0567] Figure 24C This shows a data visualization (e.g., a text table) generated when the query consists only of dimension fields (i.e., no metric fields). In the example, the query specifies "month" and "category". Note that for each month, the data values ​​for the category (i.e., "equipment" and "transportation") are copied to each other. This is the exemplary scenario 2.4 above.

[0568] Figure 24D A data visualization of sales from a single fact table (e.g., a text table) is shown. This is essentially a re-summary of Object Model V1. Note that the data visualization shows the total sales for the month and the categories where sales are not null values.

[0569] In the example, because there were no sales in February, Figure 24D The data visualization in the document does not include rows of data for February.

[0570] Figure 24E This illustrates a data visualization (e.g., a text table) when dimensions are added to measures from many trees.

[0571] Figure 24F This illustrates a data visualization (e.g., a text table) when a filter is applied to filter data values ​​for the dimension field category to "device". Because "category" is a shared object, applying the filter to a shared object ensures it is applied to the tree of all connections used in the visualization.

[0572] Figure 24G This illustrates a data visualization (e.g., a text table) when a filter is applied to filter data values ​​for the dimension field "Marketing Type" to "Online Marketing". In the example, because Marketing Type is a non-shared dimension, the filter is limited to facts in the Marketing table.

[0573] Figure 24H This illustrates a scenario where analysts can evaluate aggregated metrics across multiple fact trees at a shared dimension detail level. In the example, analysts can normalize SUM (Sales) using SUM (Spending). Figure 24H This indicates that there may be missing values ​​in the SUM (Sales) or SUM (Spending) columns, and the aggregation calculations must be validated and adjusted accordingly.

[0574] IV.C.2. Object Tree Properties

[0575] Each tree begins with a root object. Multiple roots can exist in a data model, and root objects cannot be related to each other. In some implementations, all roots must be connected (via a shared object).

[0576] All objects have only one path back to any associated root. Objects with more than one root are "shared," in which case their dimension is a shared dimension. In some implementations, a shared object must belong to at least two trees of the object model (i.e., a shared object does not necessarily belong to all trees). In other implementations, a shared object must belong to all trees of the object model.

[0577] In some implementations, shared objects can be related to each other, and the order of the relationships is also important. Figure 25 An object model is shown based on some implementation methods. Figure 25 In this context, although the product-subcategory-category is related and the marketing is related to the category object, it cannot resolve to other shared objects: product-subcategory.

[0578] Shared objects are context-dependent. Figure 25In the example, if the product-subcategory dimension is used to evaluate metrics in inventory and sales, then the product-subcategory is considered shared, but between inventory and marketing, the product-subcategory dimension is located in the inventory tree.

[0579] IV.C.3. Evaluation Logic

[0580] The results of a single tree remain the same as those of object model v1. See section IV.B. (Query Semantics (Object Model v1)).

[0581] Metrics are evaluated through their individual tree memberships. For example, metrics in a shared object (i.e., that can belong to multiple trees) need to be identified by the tree (e.g., computed via a level of detail). Metrics across multiple trees are aggregated, and their components come from the individual trees. Filters are also applied tree-wise.

[0582] Use shared dimensions to combine tree-based metric results.

[0583] Use the current vizQL layout algebra to cross non-shared dimensions.

[0584] (To the left) Tracing back to an object with one and only one root will belong to the subtree of the root object.

[0585] Objects that trace back to two or more root objects are defined as shared objects within the data model.

[0586] Shared objects are not special objects, but are defined by the context of the analysis (i.e., visualization specifications or other content in the query).

[0587] Any non-shared object can be the root object of its subtree; the layout is determined by the data modeler. Any non-shared object within a subtree can be the root.

[0588] Even if the dimensions in a shared object are not used in any relation, the dimensions in those shared objects are still shared if the fields used in the query come from multiple subtrees.

[0589] Measures in shared objects may require additional information to identify which tree they will be aggregated through.

[0590] The filter scope on the shared object is propagated to all affected subtrees.

[0591] Filters on non-shared objects are limited to their respective subtrees. However, if shared dimensions (i.e., those from shared objects) are used, and their domains are affected by filters within the subtrees used, the shared dimension domains are removed from the final coverage result.

[0592] Computations across multiple subtrees will require shared objects.

[0593] IV.C.4. Shared Dimensional Semantics in Object Models

[0594] IV.C.4a. Background

[0595] During the development of Object Model v1, it was necessary to track subqueries so that they could be executed independently and in parallel, merged, and the final outer join performed locally if necessary. To this end, object model queries were created as an intermediate query representation (between the Abstract Query and the Logical Query). Some implementations of Object Model v1 first create an object model query builder that gathers the information needed to compute the subqueries. Then, (e.g., by a computer device), the builder is requested to generate the object model query.

[0596] IV.C.4.b. Problem

[0597] According to some implementations in the publicly available text, the desired semantics for a data model with shared dimensions require a computer device to perform a full Abstract Query that may span multiple trees, and to compute and combine object model v1 subqueries (“tree subqueries”) for each tree, and then combine the tree subqueries to obtain the final result.

[0598] IV.C.4.c. Solution.

[0599] Prerequisites. Some implementations create a shared dimension tree view structure when we have an SQLQuery.

[0600] Splitting SQL Queries. In some implementations, the computing device uses SQLQuery objects instead of AbstractQuery objects. For the purposes of this public text, there is no meaningful difference between them. To implement Object Model v1 semantics within any particular tree, some implementations split the complete SQLQuery into separate SQLQuery objects for each tree. This is achieved by first computing the shared dimension tree structure, determining which trees are active, and then, for each active tree, creating an SQLQuery containing all objects referencing the fields in that tree. In some implementations, the computing device may end by repeating some objects (e.g., if a selected column is shared between two trees, the selected column should appear in the SQLQuery objects for both trees it belongs to). Any tree-independent settings should be copied from the complete SQLQuery object.

[0601] Compute tree subqueries

[0602] Some implementations parse each tree-scoped SQLQuery into an object model v1 subquery by iterating through a set of tree-scoped SQLQuery objects. In today's context, where we use the full ObjectGraph, we use an appropriate tree subgraph instead.

[0603] To ensure that object model v1 subqueries are kept together, we need to associate each tree subquery and query component (e.g., Order By, Top N) with the appropriate tree. Some implementations maintain the tree ID of the tree that the computing device is currently processing.

[0604] Currently, when we create a metric subquery and add it to a base table subquery, we create an `IObjectModelQueryBuilder`. To support multiple sets of subqueries, some implementations build the `IObjectModelQueryBuilder` in `ConstructQueryWithObjectModelSemanticsImpl` and pass it to where the subquery is created, thus adding the subquery and other query components. Some implementations modify the `IObjectModelQueryBuilder` API to facilitate the addition of subqueries targeting a specific tree, as well as other query components. Some implementations modify the refactoring actions so that they can be associated with a specific tree.

[0605] Combining tree subqueries. For an object model query that builds the final Logical Query, it first runs through a refactoring pipeline. When multiple sets of subqueries exist, the refactoring pipeline is run on each tree to form the tree subqueries. The refactoring state is how we obtain the final query, so when we run the refactoring pipeline, we need to combine tree subqueries. We can achieve this by adding an additional set of loops on the active tree. After the refactoring pipeline has been run for a particular tree, we combine it with the previous tree subqueries.

[0606] Operation order. Some implementations perform different joins between trees based on whether the trees have any dimensions in their common active nodes. First, join all tree subqueries that share dimensions in their common active nodes, then join trees that do not have any common dimension nodes.

[0607] Identify shared activity nodes. The requirement for joining on one or more shared dimension columns is:

[0608] ●These columns must exist in the visualization;

[0609] ● These columns must be in the "Grouping Operations" set in the SQLQuery;

[0610] ● Two or more root nodes must be associated with nodes that contain these columns;

[0611] ● These nodes must be shared nodes (i.e., adjacent to all active root nodes associated with them).

[0612] In some implementations, the following algorithm is used to determine a set of shared active nodes:

[0613] 1. Find a set of shared nodes for the activity.

[0614] 2. Filter the nodes found in step 1 to only those nodes that have a dimension column from which we exist.

[0615] Create a JoinLogicalOp for tree subqueries with shared nodes. For two trees that share a dimension column between them, we create a JoinLogicalOp with JoinType::FullJoin, provided that the shared dimension column between the two trees is equal. Then, we use ProjectOp to merge these two dimension columns. This is in Figure 26 As shown in the image.

[0616] Note that we must rename the dimension column on one side, import it, and then calculate and project the IFNULL (if null) values ​​between the dimension from the left and the renamed dimension onto the shared column name. Where we share multiple dimension columns or multiple nodes, we use OR to combine each equality join condition. We also overlay an additional ProjectOp for each shared dimension column (and import each renamed column). When there are three or more trees, we add additional outer joins as described above.

[0617] Create a JoinLogicalOp for tree subqueries without shared nodes. In this scenario, we use cross joins to combine tree subqueries without common active nodes, implemented as JoinLogicalOp with JoinType::Inner, but without any conditions. This is in Figure 27 As shown in the image.

[0618] V. Flowchart

[0619] Figures 28A to 28E A flowchart is provided for method 2600 for generating an object model (e.g., a data model) across multiple fact tables, based on some implementation. Method 2600 is also referred to as a process.

[0620] Method 2600 is executed (2602) at a computing device 200 having a display 208, one or more processors 202, and memory 214. Memory 214 stores (2604) one or more programs configured for execution by the one or more processors 202. In some implementations, Figures 1A to 1C , Figure 4A , Figure 4B , Figures 5A to 5D , Figure 6A , Figure 6B , Figure 7 , Figures 8A to 8C , Figures 9A to 9C , Figure 10 , Figure 11 , Figure 12 , Figures 13A to 13U , Figure 14A , Figure 14B , Figures 15A to 15C , Figures 16A to 16H , Figures 17A to 17E , Figures 18A to 18I , Figures 19A to 19G , Figures 20A to 20I , Figures 21A to 21C , Figure 22 , Figure 23 , Figures 24A to 24H , Figure 25 , Figure 26 and Figure 27 The operations illustrated correspond to instructions stored in memory 214 or other non-transitory computer-readable storage media. The computer-readable storage media may include disk or optical disk storage devices, solid-state storage devices such as flash memory, or one or more other non-volatile memory devices. In some implementations, the instructions stored on the computer-readable storage medium include one or more of the following: source code, assembly language code, object code, or other instruction formats interpreted by one or more processors. Some operations in method 2600 may be combined and / or the order of some operations may be changed. In some implementations, some operations in method 2600 may be combined with other operations in method 2700 and / or method 2800.

[0621] The computing device displays (2606) a first object icon and a second object icon located to the right of the first object icon in a user interface (e.g., a logical layer of the UI displaying the data source). The first object icon represents a first object (e.g., a first logical table) of the first data source. The second object icon represents a second object (e.g., a second logical table) of the first data source. The first object icon is connected to the second object icon via a first connector (e.g., a link) representing the relationship between the first object and the second object. The relationship between the first object and the second object has a first cardinality.

[0622] In some implementations, the first cardinality is one of the following (2608): many-to-many, many-to-one, and one-to-many relationships. In some implementations, if the cardinality is unknown, the computing device assumes that all relationships are many-to-many.

[0623] In some implementations, in response to receiving a user selection of a first object icon, the computing device displays (2610) multiple data rows and columns in the user interface representing information corresponding to one or more data fields in a third object.

[0624] In some implementations, the first object includes (2612) a first fact table (e.g., a logical table or fact subtree).

[0625] In response to receiving (2614) a first user input to add a third object (e.g., a third logical table), the computing device displays a third object icon representing the third object in the user interface.

[0626] In some implementations, the third object includes (2616) a second fact table that is not related to the first fact table (e.g., there is no aggregation path of dimensions and measures between the first and second fact tables, or the first and second fact tables are different base tables).

[0627] In some implementations, the third object is (2618) the object of the first data source.

[0628] In some implementations, the third object is (2620) an object of a second data source that is different from the first data source.

[0629] refer to Figure 28B In response to receiving a second user input (2622) on a third object icon, the computing device, based on determining that the second and third objects include at least one common data field, generates and displays a second connector in the user interface that links the third object icon to the second object icon. The second connector represents the relationship between the third object and the second object. The relationship between the third object and the second object has a second cardinality.

[0630] In some implementations, the second cardinality is one of the following (2624): many-to-many, many-to-one, and one-to-many relationships. In some implementations, if the cardinality of the relationship is unknown, the computing device assumes that all relationships are many-to-many.

[0631] In some implementations, the second user input includes (2626) a user selection of at least a portion (e.g., an edge or side) of a third object icon (e.g., a circular icon from which a user can “drag” lines).

[0632] In some implementations, in response to a user selection (2628), the computing device generates and displays a freeform line in the user interface. A first end of the line connects to a third object icon, and a second end corresponds to the position of the mouse cursor in the user interface. For example, in some implementations, by positioning the mouse or stylus over other object icons in the user interface, the user can “search” the existing object models displayed in the user interface to determine if there are related / related objects that the second object can relate to. In some implementations, when the computing device determines that the two object models corresponding to the two object icons include at least one related (e.g., common) data field, the freeform line becomes a connector line (e.g., a second connector) connecting the two object icons.

[0633] In some implementations, generating and displaying the second connector also includes converting (2630) the second object from the subtree of the first object into a shared object (e.g., a shared object shared between the first tree to which the first object belongs and the second tree to which the second object belongs).

[0634] In some implementations, the shared object comprises a logical table consisting of one or more dimension data fields (2632). A dimension table is a logical table consisting only of dimension data fields (i.e., there are no metric data fields in a dimension table).

[0635] In some implementations, the shared object includes a logical table consisting of dimension fields and metric fields.

[0636] In some implementations, at least one common data field includes a (2634) geographic data field. Examples of geographic data fields include country, region, state, province, city, postal code, longitude, or latitude.

[0637] In some implementations, at least one common (e.g., related) data field includes (2636) date / time data fields (e.g., month, day, year, or day).

[0638] Now for reference Figure 28C In some implementations, after the third object icon is connected to the second object icon via the second connector, and in response to receiving a user interaction with the second connector (e.g., a hovering action), the computing device displays (2638) an identifier of at least one common data field.

[0639] In some implementations, after the third object icon is connected to the second object icon via the second connector, the computing device vertically aligns (2640) the first object icon and the third object icon (e.g., arranging the icons in columns) for display in the user interface.

[0640] In some implementations, after the third object icon is connected to the second object icon via the second connector, the computing device arranges the first and third object icons in alphabetical order (2642) for display in the user interface.

[0641] refer to Figure 28D In some implementations, the computing device displays (2644) a fourth object icon representing the fourth object in the user interface. The fourth object icon is connected to the second object icon via a third connector representing the relationship between the fourth object and the second object. The relationship between the fourth object and the second object has a third cardinality. The fourth object icon is connected to the fifth object icon representing the fifth object via a fourth connector representing the relationship between the fourth object and the fifth object. The relationship between the fourth object and the fifth object has a fourth cardinality. The third and fourth connectors include overlapping portions.

[0642] In some implementations, the third cardinality is one of the following (2646): many-to-many, many-to-one, and one-to-many relationships. In some implementations, if the cardinality of the relationship is unknown, the computing device assumes that all relationships are many-to-many.

[0643] In some implementations, the fourth cardinality is one of the following (2648): many-to-many, many-to-one, and one-to-many relationships. In some implementations, if the cardinality of the relationship is unknown, the computing device assumes that all relationships are many-to-many.

[0644] In some implementations, in response to receiving (2650) a user interaction (e.g., a hovering action) that overlaps with the third and fourth connectors, the computing device simultaneously displays (i) the identifier of a first related data field associated with the fourth and second objects, and (ii) the identifier of a second related data field associated with the fourth and fifth objects. The first object icon, second object icon, third object icon, fourth object icon, and fifth object icon are (2652) different icons. The first related data field and the second related data field are (2654) different data fields.

[0645] In some implementations, in response to a user selection (2656) of the identifier of a first related data field associated with the fourth object and the second object, the computing device simultaneously visually emphasizes the fourth object, the second object, and the third connector.

[0646] Now for reference Figure 28EIn some implementations, the computing device displays (2658) in the user interface: a fourth object icon representing the fourth object, a fifth object icon representing the fifth object, and a third connector connecting the fourth object icon and the fifth object icon. The third connector indicates a many-to-many relationship between the fourth object and the fifth object. The fourth object icon, the fifth object icon, and the third connector are not connected to any of the first object icon, the second object icon, and the third object icon (2660).

[0647] In some implementations, in response to receiving (2662) third user input on the fifth object icon, the computing device generates and displays a freeform line in the user interface. The first end of the line is connected to the fifth object icon, and the second end of the line corresponds to the position of the mouse cursor in the user interface.

[0648] In some implementations, in response to the interaction between the second end of the (2664) line and the second object icon, the computing device converts the freeform line into a third connector connecting the fifth and second object icons. The third connector represents a many-to-many relationship between the fifth and second objects.

[0649] In some implementations, a first object icon, a second object icon, and a third object icon are displayed in the first part of the user interface (2666). A fourth object icon and a fifth object icon are displayed in the second part of the user interface. Converting the freeform line into a third connector connecting the fifth object icon and the second object icon involves redisplaying the fourth and fifth object icons in the first part of the user interface.

[0650] Figures 29A to 29D A flowchart is provided for a method 2700 for performing guided analysis using a multi-fact object model (e.g., a data model), based on some implementation. Method 2700 is also referred to as a process.

[0651] Method 2700 is executed (2702) at a computing device 200 having a display 208, one or more processors 202, and memory 214. Memory 214 stores (2704) one or more programs configured for execution by the one or more processors 202. In some implementations, Figures 1A to 1C , Figure 4A , Figure 4B , Figures 5A to 5D , Figure 6A , Figure 6B , Figure 7 , Figures 8A to 8C , Figures 9A to 9C , Figure 10 , Figure 11 , Figure 12 , Figures 13A to 13U , Figure 14A , Figure 14B , Figures 15A to 15C , Figures 16A to 16H , Figures 17A to 17E , Figures 18A to 18I , Figures 19A to 19G , Figures 20A to 20I , Figures 21A to 21C , Figure 22 , Figure 23 , Figures 24A to 24H , Figure 25 , Figure 26 and Figure 27 The operations illustrated correspond to instructions stored in memory 214 or other non-transitory computer-readable storage media. The computer-readable storage media may include disk or optical disk storage devices, solid-state storage devices such as flash memory, or one or more other non-volatile memory devices. In some implementations, the instructions stored on the computer-readable storage medium include one or more of the following: source code, assembly language code, object code, or other instruction formats interpreted by one or more processors. Some operations in method 2700 may be combined and / or the order of some operations may be changed. In some implementations, some operations in method 2700 may be combined with other operations in method 2600 and / or method 2800.

[0652] The computing device displays (2706) multiple data field icons corresponding to multiple data fields in the user interface (e.g., in the mode area of ​​the user interface). Each of these data fields is associated with a corresponding object (e.g., a logical table) of multiple objects (e.g., multiple logical tables) in the object model.

[0653] In response to (2708) receiving (i) a user selection of a first data field icon corresponding to a first data field from among a plurality of data field icons and (ii) placement of the first data field icon in a shelf area of ​​the user interface, the computing device generates and displays a first data visualization in the user interface. The first data field is associated with a first object among a plurality of objects.

[0654] In some implementations, generating the first data visualization includes executing (2710) a first query that specifies the aggregation of data values ​​of a first data field (or the aggregation of data values ​​of the first data field based on a first dimension data field) (e.g., aggregating campaign spending or aggregating campaign spending based on marketing type).

[0655] The computing device updates the visual characteristics (e.g., visual appearance) of a subset of (one or more) data field icons displayed in the user interface (e.g., a subset of data field icons is associated with a third object among a plurality of objects) from a first visual characteristic (2712) to a second visual characteristic. Each data field icon in the subset of data field icons is associated with (2714) a second object among a plurality of objects that is different from the first object. The subset of data field icons is (2716) selectable by the user, regardless of the first or second visual characteristic. In other words, a data field icon is selectable when its appearance corresponds to either the first or second visual characteristic (e.g., a subset of data field icons is selectable by the user when it has either the first or second visual characteristic).

[0656] In some implementations, updating the visual characteristics of a subset of data field icons from a first visual characteristic to a second visual characteristic includes (2718) visually de-emphasizing (e.g., graying out) the subset of data field icons relative to other data field icons among a plurality of data field icons, while maintaining the user selectability (e.g., clickability) of the subset of data field icons.

[0657] Now for reference Figure 29B In some implementations, when the visual characteristics of the first subset of data fields are the second visual characteristics, in response to user interaction (e.g., hovering over) a second data field icon (associated with a second object) from the subset of data field icons corresponding to a second data field among multiple data fields, the computing device displays (2720) information that the second data field is not related to the first data field.

[0658] In some implementations, when the visual characteristic of the first subset of data fields is the second visual characteristic, in response to receiving (i) a user selection of a second data field icon (e.g., “sales type”) from the subset of data field icons that corresponds to the second data field among the multiple data fields and (ii) a user placement of the second data field icon in the shelf area, the computing device generates (2722) and displays the second data visualization in the user interface.

[0659] In some implementations, generating a second data visualization includes executing (2724) a first query that repeats (e.g., copies or reproduces) the aggregated data values ​​of the first data field for each data value of the third data field.

[0660] In some implementations, while displaying the second data visualization, the computing device displays (2726) a warning visual indicator adjacent to the first data field icon (and / or the second data field icon) in the shelf area. In response to user interaction with the warning visual indicator (e.g., hovering over it), the computing device displays (2728) information about the second data field that is unrelated to the first data field.

[0661] Continue to refer to Figure 29C In some implementations, method 2700 further includes: after updating (2730) the visual characteristics of a subset of data field icons to a second visual characteristic: in response to receiving (i) a user selection of a third data field icon from a plurality of data field icons, wherein the third data field icon corresponds to a third data field and is not a data field icon from a subset of data field icons, and (ii) placement of the third data field icon in the shelf area: performing a second query specifying the aggregation of the data values ​​of the first data field based on the third data field to generate a third data visualization.

[0662] In some implementations, the third data field is (2732) a shared data field between the first and second objects.

[0663] In some implementations, the third data field (2734) is associated with a dimension logical table consisting of one or more dimension data fields. A dimension logical table is a logical table that contains only dimension data fields (i.e., it does not contain any metric data fields).

[0664] In some implementations, the third data field (2734) is associated with a logical table that includes one or more dimension fields and one or more metric fields.

[0665] In some implementations, the third data field is a (2736) dimension data field.

[0666] In some implementations, the third data field is the (2738) geographic data field.

[0667] In some implementations, the third data field is a (2740) date / time data field.

[0668] In some implementations, method 2700 includes displaying (2742) a third data visualization in the user interface.

[0669] refer to Figure 29D In some implementations, while displaying the third data visualization, the computing device updates (2744) (e.g., restores) the visual characteristics of a subset of data fields from the second visual characteristics to the first visual characteristics.

[0670] In some implementations, updating the visual characteristics of a subset of data fields from a first characteristic to a second characteristic includes visually de-emphasizing (e.g., graying out) the subset of data field icons relative to other data field icons among a plurality of data field icons. In some implementations, updating (restoring) the visual characteristics of a subset of data fields from the second characteristic to the first characteristic includes restoring the view of the user interface to its state before the visual de-emphasization.

[0671] In some implementations, method 2700 further includes: after displaying the third data visualization: in response to receiving (i) a user selection of a fourth data field icon corresponding to the fourth data field from a subset of data field icons and (ii) placement of the fourth data field icon in the shelf area: performing (2746) a third query specifying the data value of the fourth data field ["Total Sales"] aggregated according to the third data field ["Product Name"] to generate the fourth data visualization. The method includes displaying (2748) the fourth data visualization in the user interface.

[0672] In some implementations, the fourth data visualization is displayed simultaneously with the third data visualization (2750) in the user interface.

[0673] In some instances, the third and fourth data visualizations share a common data axis (2752).

[0674] Figures 30A to 30D A flowchart is provided outlining methods for generating data visualizations using a multi-fact object model (e.g., a data model), based on various implementations. Method 2800 is also referred to as a process.

[0675] Method 2800 is executed (2802) at a computing device 200 having a display 208, one or more processors 202, and memory 214. Memory 214 stores (22804) one or more programs configured for execution by the one or more processors 202. In some implementations, Figures 1A to 1C , Figure 4A , Figure 4B , Figures 5A to 5D , Figure 6A , Figure 6B , Figure 7 , Figures 8A to 8C , Figures 9A to 9C , Figure 10 , Figure 11 , Figure 12 , Figures 13A to 13U , Figure 14A , Figure 14B , Figures 15A to 15C , Figures 16A to 16H , Figures 17A to 17E , Figures 18A to 18I , Figures 19A to 19G , Figures 20A to 20I , Figures 21A to 21C , Figure 22 , Figure 23 , Figures 24A to 24H , Figure 25 , Figure 26 and Figure 27 The operations illustrated correspond to instructions stored in memory 214 or other non-transitory computer-readable storage media. The computer-readable storage media may include disk or optical disk storage devices, solid-state storage devices such as flash memory, or one or more other non-volatile memory devices. In some implementations, the instructions stored on the computer-readable storage medium include one or more of the following: source code, assembly language code, object code, or other instruction formats interpreted by one or more processors. Some operations in method 2800 may be combined and / or the order of some operations may be changed. In some implementations, some operations in method 2800 may be combined with other operations in method 2600 and / or method 2700.

[0676] The computing device receives (2806) (e.g., via a user interface, such as user interface 2332) a first user input, which specifies a first-dimensional data field and a second-dimensional data field for generating a first data visualization.

[0677] In some implementations, at least one of the first-dimensional data field or the second-dimensional data field is a (2808) geographic data field.

[0678] In some implementations, at least one of the first-dimensional data field or the second-dimensional data field is a (2810) date / time data field.

[0679] The computing device determines (2812) that the first dimension data field belongs to a first object of the object model (e.g., a first logical table) and the second dimension data field belongs to a second object of the object model that is different from the first object (e.g., a second logical table).

[0680] refer to Figure 30B In some implementations, the computing device constructs a (2814) dimension subquery based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object. In some implementations, the characteristics include whether the first dimension data field is a shared or non-shared dimension, and / or whether the second dimension data field is a shared or non-shared dimension, whether the first object can be traced back to a single root table or multiple root tables, and / or whether the second object can be traced back to a single root table or multiple root tables.

[0681] The computing device determines (2816) the join type (e.g., inner join, cross join, outer join, left join, right join) for combining (i) a first data row containing data values ​​of a first dimension data field and (ii) a second data row containing data values ​​of a second dimension data field.

[0682] The computing device constructs a (2824) dimension subquery based on the determined connection type. The dimension subquery references the first and second objects;

[0683] The computing device executes a (2820) dimension subquery against one or more data sources corresponding to the first dimension data field and the second dimension data field to obtain a first tuple that is a unique ordered combination of the data values ​​of the first dimension data field and the second dimension data field.

[0684] In some implementations, one or more data sources include (2822) multiple data sources.

[0685] The computing device constructs (2824) one or more metric subqueries. Each of these metric subqueries references one or more metric data fields in the object model;

[0686] The computing device executes one or more metric subqueries (2826) to obtain the second tuple;

[0687] The computing device forms an extended tuple (2828) by combining the first tuple and the second tuple.

[0688] The computing device generates (2830) based on the extended tuple and displays the first data visualization.

[0689] refer to Figure 30C In some implementations, the first-dimensional data field and the second-dimensional data field are non-shared dimensions from a tree (e.g., scenario 2.1 in section IV.C.1.b). In some implementations, constructing a dimension subquery based on the characteristics of the first-dimensional data field, the second-dimensional data field, the first object, and / or the object includes, based on the computing device determining (2832): (i) the first-dimensional data field can be traced to a (e.g., one and only one) (i.e., a single) root object (e.g., a fact table) (e.g., by traversing leftward in the object model) and (ii) the second-dimensional data field can be traced to the same root object (i.e., the first and second objects belong to the same root object), the computing device uses an inner join to combine the data columns of the first-dimensional data field and the second-dimensional data field.

[0690] As mentioned above, it can be traced back to only one root object whose dimension data field is a non-shared dimension data field (i.e., it is not shared by other fact tables). Using Figure 22 Using object model 2200 as an example, the first dimension data field can be D1 (e.g., marketing type), and the second dimension data field can be D4 (e.g., date). Because D1 and D4 are non-shared dimensions from a tree, the query semantics used to construct dimension queries are the same as those in object model v1 (see, for example, section IV.B).

[0691] In some implementations, the first and second dimension data fields are non-shared dimensions from multiple trees, as described in scenario 2.2 of section IV.C.1.b. In some implementations, constructing a dimension subquery based on the characteristics of the first and second dimension data fields, the first object, and / or the second object includes: determining, based on the computing device, that (i) the first dimension data field is traceable to a first root object and (ii) the second dimension data field is traceable to a second root object different from the first root object (e.g., and the second object is not a shared object of the first root object), the computing device forms (2834) a first object tree including the first object and the first root object, and combines data columns from the objects in the first object tree using an inner join based on the data values ​​of the first dimension data field to form a first table. The computing device forms (2836) a second object tree including the second object and the second root object, and combines data columns from the objects in the second object tree using an inner join based on the data values ​​of the second dimension data field to form a second table. The computing device combines (2838) the data columns of the first and second tables via a cross join. Figure 22 Using object model 2200 as an example, in one example, the first dimension data field is D1 (e.g., marketing type), and the second dimension data field is D6 (e.g., part). In the example, the computing device (i) forms a marketing object tree (in this case, the marketing tree consists only of marketing objects) (Result 1), and (ii) forms a support tree that includes part objects (logical table 6) and support objects (i.e., root objects) and inner joins all dimensions using parts (Result 2), and cross joins Result 1 and Result 2. In some instances, the first object is the first root object. In some implementations, the second object is a second root object that is different from the first root object.

[0692] In some implementations, the first-dimensional data field and the second-dimensional data field are shared dimensions from a single shared tree, as described in scenario 2.3 of section IV.C.1.b. In some implementations, constructing a dimensional subquery based on the characteristics of the first-dimensional data field, the second-dimensional data field, the first object, and / or the second object includes: determining, based on the computing device, that the first-dimensional data field and the second-dimensional data field belong to the same object (e.g., a shared tree) shared by two or more root objects (e.g., where the first object is not a root object and the second object is not a root object); and the computing device using an inner join to combine the data columns of the first-dimensional data field and the second-dimensional data field. Figure 22 The exemplary object model 2200 in the example can be D7 for the first dimension data field and D9 for the second dimension data field.

[0693] Continue to refer to Figure 30D In some implementations, the first-dimensional data field and the second-dimensional data field are shared dimensions from multiple shared trees, as discussed relative to scenario 2.4 in section IV.C.1.b. In some implementations, constructing a dimensional subquery based on the characteristics of the first-dimensional data field, the second-dimensional data field, the first object, and / or the second object includes, based on the computing device determining that (i) the first object (to which the first-dimensional data field belongs) is shared by a first set of root objects (e.g., two or more root objects) and (ii) the second object (to which the second-dimensional data field belongs) is shared by a second set of root objects (e.g., two or more root objects), the computing device uses a cross join to combine the data columns of the first-dimensional data field and the second-dimensional data field. In some implementations, the first set of root objects is the same as the second set of root objects. In some implementations, the first set of root objects and the second set of root objects have at least one different root object. Using object model 2200 as an example, the first-dimensional data field could be D4, and the second-dimensional data field could be D5.

[0694] In some implementations, the first dimension data field is a non-shared dimension data field, the second dimension data field is a shared dimension data field, and the first and second dimension data fields belong to the same tree, as discussed relative to scenario 2.5 in section IV.C.1.b. In some implementations, constructing a dimension subquery based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object includes determining, based on the computing device, that: (i) the first object (to which the first dimension data field belongs) is the first root object (meaning the first object (e.g., the first root object) and therefore the first dimension data field is not shared), (ii) the second object can be traced back to the first root object, and (iii) the second dimension data field is not shared by another root object; the computing device uses an inner join to combine the data columns of the first and second dimension data fields (2844). Using object model 2200 as an example, the first dimension data field could be D1, and the second dimension data field could be D4.

[0695] Each of the executable modules, applications, or assemblies identified above may be stored in one or more of the previously mentioned memory devices and corresponds to an instruction set for performing the functions described above. The modules or programs identified above (i.e., instruction sets) need not be implemented as separate software programs, programs, or modules, and therefore various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, the memory stores a subset of the modules and data structures identified above. Furthermore, the memory may store additional modules or data structures not described above.

[0696] The terminology used in the description of this invention herein is for the purpose of describing particular implementations only and is not intended to limit the invention. As used in the description of the invention and the appended claims, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or,” as used herein, refers to and covers any and all possible combinations of one or more of the associated listed items. It should also be understood that, when used in this specification, the terms “comprising” and / or “including” specify the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0697] As used in this article, the phrase “based on” does not mean “based on only” unless otherwise explicitly stated. In other words, the phrase “based on” describes “based on only” and “based on at least”.

[0698] As used herein, the term “exemplary” means “used as an example, instance, or illustration” and does not necessarily indicate any preference or superiority of the example relative to any other configuration or implementation.

[0699] As used herein, the term “and / or” covers any combination of the listed elements. For example, “A, B and / or C” includes the following sets of elements: A only, B only, C only, A and B without C, A and C without B, B and C without A, and combinations of all three elements A, B and C.

[0700] For purposes of explanation, the foregoing description has been described with reference to specific implementations. However, the above illustrative discussion is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the foregoing teachings. These implementations were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling those skilled in the art to best utilize the invention and its various implementations with various modifications suitable for the particular intended use.

Claims

1. A method for generating an object model across multiple fact tables, comprising: At a computing device having a display, one or more processors, and memory configured for executing one or more programs by said one or more processors: The user interface displays a first object icon and a second object icon located to the right of the first object icon, wherein: The first object icon represents the first object of the first data source; The second object icon represents the second object of the first data source; and The first object icon is connected to the second object icon via a first connector representing the relationship between the first object and the second object, and the relationship between the first object and the second object has a first cardinality; In response to receiving a first user input to add a third object, an icon representing the third object is displayed in the user interface; and In response to receiving a second user input on the third object icon: Based on the determination that the second object and the third object include at least one common data field, a second connector is generated and displayed in the user interface to connect the icon of the third object to the icon of the second object, the second connector representing the relationship between the third object and the second object, the relationship between the third object and the second object having a second cardinality.

2. The method according to claim 1, wherein: The first cardinality is one of the following: many-to-many relationship, many-to-one relationship, and one-to-many relationship; and The second cardinality is one of the following: many-to-many relationship, many-to-one relationship, and one-to-many relationship.

3. The method according to claim 1 or 2, wherein: The second user input includes user selection of at least a portion of the third object icon; as well as The method further includes: In response to the user's selection: Freeform lines are generated and displayed in the user interface, wherein a first end of the freeform line is connected to the third object icon, and a second end of the freeform line corresponds to the position of the mouse cursor in the user interface.

4. The method according to any one of claims 1 to 3, further comprising: After connecting the third object icon to the second object icon via the second connector: In response to receiving a user interaction with the second connector, the identifier of the at least one common data field is displayed.

5. The method according to any one of claims 1 to 4, further comprising: In response to receiving a user selection of the first object icon: The user interface displays multiple data rows and columns representing information corresponding to one or more data fields in the first object.

6. The method according to any one of claims 1 to 5, further comprising: After the third object icon is connected to the second object icon via the second connector, the first object icon and the third object icon are vertically aligned for display in the user interface.

7. The method according to any one of claims 1 to 6, further comprising: After the third object icon is connected to the second object icon via the second connector, the first object icon and the third object icon are arranged in alphabetical order for display in the user interface.

8. The method according to any one of claims 1 to 7, wherein displaying the second connector connecting the third object icon to the second object icon further comprises: Convert the second object from the subtree of the first object into a shared object.

9. The method of claim 8, wherein the shared object comprises a logical table consisting of one or more dimensional data fields.

10. The method according to any one of claims 1 to 9, wherein: The first object includes a first fact table; and The third object includes a second fact table that is not related to the first fact table.

11. The method according to any one of claims 1 to 10, wherein the at least one common data field includes a geographic data field or a date / time data field.

12. The method according to any one of claims 1 to 11, wherein the third object is an object of the first data source.

13. The method according to any one of claims 1 to 12, wherein the third object is an object from a second data source different from the first data source.

14. The method according to any one of claims 1 to 13, further comprising: The user interface displays an icon representing the fourth object, wherein: The fourth object icon is connected to the second object icon via a third connector representing the relationship between the fourth object and the second object, and the relationship between the fourth object and the second object has a third cardinality; The fourth object icon is connected to the fifth object icon representing the fifth object via a fourth connector indicating the relationship between the fourth object and the fifth object, the relationship between the fourth object and the fifth object having a fourth cardinality; and The third connector and the fourth connector include overlapping portions; and In response to receiving a user interaction with the overlapping portion of the third connector and the fourth connector: Simultaneously display (i) the identifier of a first related data field associated with the fourth object and the second object and (ii) the identifier of a second related data field associated with the fourth object and the fifth object, wherein: The first object icon, the second object icon, the third object icon, the fourth object icon, and the fifth object icon are different icons; and The first related data field and the second related data field are different data fields.

15. The method of claim 14, further comprising: In response to a user selection of the identifier of the first relevant data field associated with the fourth object and the second object, the fourth object, the second object, and the third connector are visually emphasized.

16. The method according to claim 14 or 15, wherein: The third cardinality is one of the following: many-to-many relationships, many-to-one relationships, and one-to-many relationships; and The fourth cardinal number is one of the following: many-to-many relationship, many-to-one relationship, and one-to-many relationship.

17. The method according to any one of claims 1 to 16, further comprising: The following is displayed in the user interface: The icon representing the fourth object; The icon representing the fifth object; and The third connector links the fourth object icon and the fifth object icon, indicating a many-to-many relationship between the fourth and fifth objects. The fourth object icon, the fifth object icon, and the third connector are not connected to any one of the first object icon, the second object icon, or the third object icon. In response to receiving third user input on the fifth object icon, a freeform line is generated and displayed in the user interface, wherein a first end of the freeform line is connected to the fifth object icon, and a second end of the freeform line corresponds to the position of the mouse cursor in the user interface; and In response to the interaction received between the second end of the freeform line and the second object icon: The freeform line is converted into a third connector that connects the fifth object icon and the second object icon, the third connector representing a many-to-many relationship between the fifth object and the second object.

18. The method of claim 17, wherein: The first object icon, the second object icon, and the third object icon are displayed in a first part of the user interface; The fourth object icon and the fifth object icon are displayed in the second part of the user interface; as well as Converting the freeform line into a third connector that links the fifth object icon and the second object icon includes: The fourth object icon and the fifth object icon are redisplayed in the first part of the user interface.

19. A computing device, comprising: One or more processors; Memory; monitor; and One or more programs, stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the method of any one of claims 1 to 18.

20. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a computing device having one or more processors, a memory, and a display, said one or more programs including instructions for performing the method of any one of claims 1 to 18.

21. A method for performing guided analysis using a multi-fact object model, comprising: At a computing device having a display, one or more processors, and memory configured for executing one or more programs by said one or more processors: The user interface displays multiple data field icons corresponding to multiple data fields, each of which is associated with a corresponding object among multiple objects in the object model; In response to receiving (i) a user selection of a first data field icon corresponding to a first data field from among the plurality of data field icons and (ii) placement of the first data field icon in the shelf area of ​​the user interface, wherein the first data field is associated with a first object among the plurality of objects: The first data visualization is generated and displayed in the user interface; and The visual characteristics of a subset of the multiple data field icons displayed in the user interface are updated from a first visual characteristic to a second visual characteristic, wherein: Each data field icon in the subset of the data field icons is associated with a second object among the plurality of objects that is different from the first object; as well as The data field icons in the subset are user-selectable and are independent of the first or second visual feature.

22. The method according to claim 21, wherein: Updating the visual characteristics of a subset of the data field icons from the first visual characteristic to the second visual characteristic includes: visually de-emphasizing a subset of the data field icons relative to other data field icons among the plurality of data field icons, while maintaining user selectability of the subset of data field icons.

23. The method according to claim 21 or 22, further comprising: When the visual characteristic of a subset of the data field is the second visual characteristic: In response to user interaction with a second data field icon corresponding to a second data field among the plurality of data fields, from a subset of the data field icons: Displays information in the second data field that is unrelated to the first data field.

24. The method according to any one of claims 21 to 23, further comprising: When the visual characteristic of a subset of the data field is the second visual characteristic: In response to receiving (i) a user selection of a second data field icon corresponding to a second data field among the plurality of data fields from a subset of the data field icons and (ii) a user placement of the second data field icon in the shelf area: A second data visualization is generated and displayed in the user interface.

25. The method according to claim 24, wherein: Generating the first data visualization includes executing a first query, the first query specifying the aggregation of data values ​​of the first data field; as well as Generating the second data visualization includes executing a second query that repeats the aggregated data values ​​of the first data field for each data value of the third data field.

26. The method according to claim 24 or 25, further comprising: While displaying the second data visualization: A warning visual indicator is displayed in the shelf area adjacent to the icon of the first data field; as well as In response to user interaction with the warning visual indicator, information unrelated to the first data field is displayed for the second data field.

27. The method according to any one of claims 21 to 26, further comprising: After updating the visual characteristics of a subset of the data field icons to the second visual characteristics: In response to receiving (i) a user selection of a third data field icon from the plurality of data field icons, wherein the third data field icon corresponds to a third data field and is not a subset of the data field icons, and (ii) the placement of the third data field icon in the shelf area: Execute a second query that aggregates the data values ​​of the first data field based on the third data field to generate a third data visualization; The third data visualization is displayed in the user interface.

28. The method of claim 27, further comprising: While displaying the third data visualization, the visual characteristics of a subset of the data fields are updated from the second visual characteristic to the first visual characteristic.

29. The method of claim 27 or 28, wherein the third data field is a shared data field shared between the first object and the second object.

30. The method according to any one of claims 27 to 29, wherein the third data field is associated with a dimension logical table.

31. The method according to any one of claims 27 to 30, wherein the third data field is a dimension data field.

32. The method according to any one of claims 27 to 31, wherein the third data field is a geographic data field.

33. The method according to any one of claims 27 to 32, wherein the third data field is a date / time data field.

34. The method according to any one of claims 27 to 33, further comprising: After displaying the third data visualization: In response to receiving (i) a user selection of a fourth data field icon corresponding to a fourth data field from a subset of the data field icons and (ii) the placement of the fourth data field icon in the shelf area: Execute a third query that aggregates the data values ​​of the specified fourth data field based on the third data field to generate a fourth data visualization; and The fourth data visualization is displayed in the user interface.

35. The method of claim 34, wherein the fourth data visualization and the third data visualization are simultaneously displayed in the user interface.

36. The method of claim 35, wherein the third data visualization and the fourth data visualization share a common data axis.

37. A computing device, comprising: One or more processors; Memory; monitor; and One or more programs, stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the method of any one of claims 21 to 36.

38. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a computing device having one or more processors, a memory, and a display, said one or more programs including instructions for performing the method of any one of claims 21 to 36.

39. A method for generating data visualizations using a multi-fact object model, comprising: At a computing device having a display, one or more processors, and memory configured for executing one or more programs by said one or more processors: Receive first user input, whereby the first user input specifies a first-dimensional data field and a second-dimensional data field for generating a first data visualization; It is determined that the first dimension data field belongs to the first object of the object model, and the second dimension data field belongs to the second object of the object model that is different from the first object; Constructing dimensional subqueries based on the characteristics of the first dimension data field, the second dimension data field, the first object, and / or the second object, including: Determine the connection type for combining (i) a first data row containing data values ​​from the first dimension data field and (ii) a second data row containing data values ​​from the second dimension data field; and The dimension subquery is constructed based on the determined connection type, and the dimension subquery references the first object and the second object; The dimension subquery is executed for one or more data sources corresponding to the first dimension data field and the second dimension data field to obtain a first tuple that is a unique ordered combination of the data values ​​of the first dimension data field and the second dimension data field; Construct one or more metric subqueries, each of which references one or more metric data fields in the object model; Execute one or more metric subqueries to obtain the second tuple; An extended tuple is formed by combining the first tuple and the second tuple obtained; and The first data visualization is generated and displayed based on the extended tuples.

40. The method of claim 39, wherein constructing the dimensional subquery based on the first dimensional data field, the second dimensional data field, the first object, and / or the characteristics determined by the object comprises: Based on the determination that (i) the first dimension data field can be traced back to a root object and (ii) the second dimension data field can be traced back to the same root object: Use an inner join to combine data columns from the first dimension data field and the second dimension data field.

41. The method of claim 39, wherein constructing the dimensional subquery based on the characteristics of the first dimensional data field, the second dimensional data field, the first object, and / or the second object comprises: Based on the determination that (i) the first dimension data field can be traced back to the first root object and (ii) the second dimension data field can be traced back to a second root object different from the first root object: A first object tree is formed, including the first object and the first root object, and data columns from the objects in the first object tree are combined using inner joins based on the data values ​​of the first dimension data field to form a first table; A second object tree is formed, including the second object and the second root object, and data columns from the objects in the second object tree are combined using inner joins based on the data values ​​of the second dimension data field to form a second table; as well as The data columns of the first table and the second table are combined via cross join.

42. The method of claim 39, wherein constructing the dimensional subquery based on the characteristics of the first dimensional data field, the second dimensional data field, the first object, and / or the second object comprises: Based on the determination that the first dimension data field and the second dimension data field belong to the same object shared by two or more root objects: Use an inner join to combine data columns from the first dimension data field and the second dimension data field.

43. The method of claim 39, wherein constructing the dimensional subquery based on the characteristics of the first dimensional data field, the second dimensional data field, the first object, and / or the second object comprises: Based on the determination that (i) the first object is shared by the first group of root objects and (ii) the second object is shared by the second group of root objects: Use cross joins to combine data columns from the first dimension data field and the second dimension data field.

44. The method of claim 39, wherein constructing the dimensional subquery based on the characteristics of the first dimensional data field, the second dimensional data field, the first object, and / or the second object comprises: Based on the determination that (i) the first object is the first root object, (ii) the second object can be traced back to the first root object, and (iii) the second dimension data field is not shared by another root object: Use an inner join to combine data columns from the first dimension data field and the second dimension data field.

45. The method according to any one of claims 39 to 44, wherein at least one of the first dimension data field or the second dimension data field is a geographic data field.

46. ​​The method according to any one of claims 39 to 45, wherein at least one of the first dimension data field or the second dimension data field is a date / time data field.

47. A computing device, comprising: One or more processors; Memory; and One or more programs, stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the method of any one of claims 39 to 46.

48. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a computing device having one or more processors, a memory, and a display, said one or more programs including instructions for performing the method of any one of claims 39 to 46.

Images