Fixes

Author: igorlukanin

docs/pages/product/apis-integrations/_meta.js

@@ -1,6 +1,5 @@
 module.exports = {
   "queries": "Queries",
-  "recipes": "Recipes",
   "dax-api": "DAX API",
   "mdx-api": "MDX API",
   "microsoft-excel": "Cube Cloud for Excel",
@@ -11,4 +10,5 @@ module.exports = {
   "graphql-api": "GraphQL API",
   "javascript-sdk": "JavaScript SDK",
   "orchestration-api": "Orchestration API",
+  "recipes": "Recipes"
 };

docs/pages/product/caching/matching-pre-aggregations.mdx

@@ -112,8 +112,13 @@ pitfalls](#common-pitfalls) to understand why that part was an issue.
 ### Common pitfalls
 
 - Most commonly, a query would not match a pre-aggregation because they contain
-[non-additive measures][ref-measure-additivity]. See [this
-recipe][ref-non-additive-recipe] for workarounds.
+[non-additive measures][ref-measure-additivity].
+
+  <ReferenceBox>
+  
+  See [this recipe][ref-non-additive-recipe] for workarounds.
+
+  </ReferenceBox>
 
 - If a query uses any time zone other than `UTC`, please check the section on
 [matching time dimensions](#matching-time-dimensions) and the
@@ -130,7 +135,7 @@ configuration option.
 [ref-leaf-measures]: /product/data-modeling/concepts#leaf-measures
 [ref-calculated-measures]: /product/data-modeling/overview#4-using-calculated-measures
 [ref-non-strict-date-range-match]: /product/data-modeling/reference/pre-aggregations#allow_non_strict_date_range_match
-[ref-non-additive-recipe]: /product/data-modeling/recipes/non-additivity
+[ref-non-additive-recipe]: /product/caching/recipes/non-additivity
 [ref-conf-scheduled-refresh-time-zones]: /product/configuration/reference/config#scheduled_refresh_time_zones
 [ref-ungrouped-queries]: /product/apis-integrations/queries#ungrouped-query
 [ref-primary-key]: /product/data-modeling/reference/dimensions#primary_key

docs/pages/product/caching/recipes/non-additivity.mdx

@@ -21,8 +21,7 @@ age:
 
 - count of unique age values (`distinct_ages`)
 - average age (`avg_age`)
-- 90th [percentile](/product/data-modeling/recipes/percentiles) of age
-  (`p90_age`)
+- 90th [percentile][ref-percentile-recipe] of age (`p90_age`)
 
 <CodeTabs>
 
@@ -244,3 +243,6 @@ Please feel free to check out the
 [full source code](https://github.com/cube-js/cube/tree/master/examples/recipes/non-additivity)
 or run it with the `docker-compose up` command. You'll see the result, including
 queried data, in the console.
+
+
+[ref-percentile-recipe]: /product/data-modeling/recipes/percentiles

docs/pages/product/caching/using-pre-aggregations.mdx

@@ -182,13 +182,21 @@ new results, then the pre-aggregation will be refreshed.
 
 [Partitioning][wiki-partitioning] is an extremely effective optimization for
 accelerating pre-aggregations build and refresh time. It effectively "shards"
-the data between multiple tables, splitting them by a defined attribute. Cube
-can be configured to incrementally refresh only the last set of partitions
+the data between multiple tables, splitting them by a defined attribute.
+
+Cube can be configured to incrementally refresh only the last set of partitions
 through the `updateWindow` property. This leads to faster refresh times due to
 unnecessary data not being reloaded, and even reduced cost for some databases
 like [BigQuery](/product/configuration/data-sources/google-bigquery) or
 [AWS Athena](/product/configuration/data-sources/aws-athena).
 
+<ReferenceBox>
+
+See [this recipe][ref-incremental-refresh-recipe] for an example of optimized
+incremental refresh.
+
+</ReferenceBox>
+
 Any `rollup` pre-aggregation can be partitioned by time using the
 `partition_granularity` property in [a pre-aggregation
 definition][ref-schema-ref-preaggs]. In the example below, the
@@ -1065,3 +1073,4 @@ or a decimal type, depending on the nature of your data.
 [ref-cube-store]: /product/caching/running-in-production#architecture
 [ref-cube-store-storage]: /product/caching/running-in-production#storage
 [ref-member-sql]: /product/data-modeling/reference/dimensions#sql
+[ref-incremental-refresh-recipe]: /product/caching/recipes/incrementally-building-pre-aggregations-for-a-date-range

docs/pages/product/data-modeling/concepts.mdx

@@ -27,6 +27,16 @@ We'll use a sample e-commerce database with two tables, `orders` and
 | 4      | 71             | 4            | 8            | 223       | 2019-12-23 00:00:00.000000 |
 | 5      | 64             | 5            | 5            | 75        | 2019-04-20 00:00:00.000000 |
 
+We'll be following the [entity-first](#entity-first-approach) approach to
+designing the data model.
+
+<ReferenceBox>
+
+See [this recipe][ref-entities-vs-metrics-recipe] to learn about entity-first and
+metrics-first approaches.
+
+</ReferenceBox>
+
 ## Cubes
 
 _Cubes_ represent datasets in Cube and are conceptually similar to [views in
@@ -50,6 +60,13 @@ cubes:
 
 </CodeTabs>
 
+<ReferenceBox>
+
+If you're using dbt, see [this recipe][ref-cube-with-dbt] to streamline defining cubes
+on top of dbt models.
+
+</ReferenceBox>
+
 You can also use the [`sql` property][ref-schema-ref-sql] to accommodate more
 complex SQL queries:
 
@@ -338,8 +355,9 @@ you need to use weeks starting on Sunday, fiscal years, etc.
 
 <ReferenceBox>
 
-See [this recipe][ref-custom-granularity-recipe] for more custom granularity
-examples.
+See the following recipes:
+- For a [custom granularity][ref-custom-granularity-recipe] example.
+- For a [custom calendar][ref-custom-calendar-recipe] example.
 
 </ReferenceBox>
 
@@ -502,6 +520,14 @@ See the [measure type reference][ref-ref-measure-types] for details.
 
 </ReferenceBox>
 
+<ReferenceBox>
+
+See the following recipes:
+- To learn how to define [average and percentile measures][ref-avg-and-percentile-recipe],
+- To learn how to calculate [period-over-period changes][ref-period-over-period-recipe].
+
+</ReferenceBox>
+
 ### Measure additivity
 
 Additivity is a property of measures that detemines whether measure values,
@@ -810,4 +836,9 @@ See the reference documentaton for the full list of pre-aggregation
 [ref-mls]: /product/auth/member-level-security
 [ref-ref-hierarchies]: /product/data-modeling/reference/hierarchies
 [ref-ref-folders]: /product/data-modeling/reference/view#folders
-[ref-multi-stage-calculations]: /product/data-modeling/concepts/multi-stage-calculations
+[ref-multi-stage-calculations]: /product/data-modeling/concepts/multi-stage-calculations
+[ref-entities-vs-metrics-recipe]: /product/data-modeling/recipes/designing-metrics
+[ref-avg-and-percentile-recipe]: /product/data-modeling/recipes/percentiles
+[ref-period-over-period-recipe]: /product/data-modeling/recipes/period-over-period
+[ref-custom-calendar-recipe]: /product/data-modeling/recipes/custom-calendar
+[ref-cube-with-dbt]: /product/data-modeling/recipes/dbt

docs/pages/product/data-modeling/concepts/calculated-members.mdx

@@ -388,7 +388,16 @@ GROUP BY 1, 2, 3
 
 **Subquery dimensions reference measures from other cubes.** Subquery dimensions
 provide a way to define measures that aggregate values of other measures. They can be
-useful to calculate [nested aggregates][ref-nested-aggregates-recipe].
+useful to calculate nested and filtered aggregates.
+
+<ReferenceBox>
+
+See the following recipes:
+
+- To learn how to calculate [nested aggregates][ref-nested-aggregates-recipe].
+- To learn how to calculate [filtered aggregates][ref-filtered-aggregates-recipe].
+
+</ReferenceBox>
 
 If you have `first_cube` that is [joined][ref-joins] to `second_cube`, you can use a
 subquery dimension to bring `second_cube.measure` to `first_cube` as `dimension` (or
@@ -561,6 +570,7 @@ GROUP BY 1, 2
 [ref-schema-ref-joins]: /product/data-modeling/reference/joins
 [ref-decomposition-recipe]: /product/data-modeling/recipes/non-additivity#decomposing-into-a-formula-with-additive-measures
 [ref-nested-aggregates-recipe]: /product/data-modeling/recipes/nested-aggregates
+[ref-filtered-aggregates-recipe]: /product/data-modeling/recipes/filtered-aggregates
 [ref-non-additive]: /product/data-modeling/concepts#measure-additivity
 [link-postgres-division]: https://www.postgresql.org/docs/current/functions-math.html#FUNCTIONS-MATH
 [wiki-correlated-subquery]: https://en.wikipedia.org/wiki/Correlated_subquery

docs/pages/product/data-modeling/recipes/_meta.js

@@ -6,8 +6,7 @@ module.exports = {
   "filtered-aggregates": "Filtered aggregates",
   "period-over-period": "Period-over-period changes",
   "passing-dynamic-parameters-in-a-query": "Dynamic parameters",
-  "schema-generation": "Data model generation",
-  "using-dynamic-measures": "Dynamic measures",
+  "using-dynamic-measures": "Dynamic data modeling",
   "dynamic-union-tables": "Dynamic union tables",
   "string-time-dimensions": "String time dimensions",
   "custom-granularity": "Custom time dimension granularities",

docs/pages/product/data-modeling/recipes/designing-metrics.mdx

@@ -1,10 +1,11 @@
-# Designing Metrics
+# Designing metrics
 
-Cube is a dataset-centric semantic layer, where all primary objects, cubes and views, are table-like datasets.
-When designing how your semantic layer will be exposed and consumed by end users, you can follow either entity-first approach or metrics-first. 
-In both cases, views will be used to build the semantic layer interface. 
+Cube is a dataset-centric semantic layer, where all primary objects (cubes and views)
+are table-like datasets. When designing how your semantic layer will be exposed and
+consumed by end users, you can follow either an [entity-first](#entity-first-approach)
+or a [metrics-first](#metrics-first-approach) approach. 
 
-## Entity-first
+## Entity-first approach
 
 In entity-first approach, views are built around entities in your data model. 
 Views are built as denormalzied tables, bringing measures and dimensions from different cubes needed to fully decscribe the entity.
@@ -83,7 +84,8 @@ views:
 Views are exposed as tables in Cube SQL API, dimensions can be queried as is 
 
 
-## Metrics-first
+## Metrics-first approach
+
 In metrics-first approach, views are built around measures, or metrics, in your data model.
 Views are built as denormalzied tables, containing one measure and all the relevant dimensions from different cubes. These include all the dimensions you would group or filter by, and up to one time dimension.  
 Views are usually named after that single measure.
@@ -141,30 +143,4 @@ views:
 
           - status
           - shipped_at
-```
-
-## Integrations with BI Tools
-Some metrics-based BI tools will specify requirements for the views or be able to accept additional metadata to enrich the experience.  
-Below is an example of using the `meta` property to do this.
-
-```yaml
-views:
-  - name: order_count_by_order_date
-    description: For finance team to track orders on accrual/earned basis.
-    meta:
-      type: metric
-      owner: [email protected]
-
-    cubes:
-      - join_path: orders
-        includes:
-          # MEASURE
-          - order_count
-
-          # TIME
-          - created_at
-
-          # DIMENSIONS
-          - status
-          - city
-```
+```

docs/pages/product/data-modeling/recipes/schema-generation.mdx

@@ -1,4 +1,4 @@
-# Cube Style Guide
+# Cube style guide
 
 This style guide includes best practices on data modeling in Cube.