[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-31。"],[],[],null,["# Error: Measures with Looker aggregations (sum, average, min, max, list types) may not reference other measures\n\nWhile developing in a project, you might see an error like the following in an [Explore](/looker/docs/creating-and-editing-explores) or in the [LookML Validator](/looker/docs/lookml-validation#validating_your_lookml): \n\n```\n Measures with Looker aggregations (sum, average, min, max, list types) may not reference other measures.\n```\n\n\nThis error is caused by an [aggregate measure](/looker/docs/reference/param-measure-types#measure_type_categories) referencing another aggregation or [measure](/looker/docs/reference/param-field-measure) of any type in its LookML definition, such as: \n\n```\n SELECT AVG((COUNT(*)) ) AS users.average_count FROM demo_db.users AS users\n```\n\n\nSQL statements such as this generate a double or nested aggregation in SQL --- most SQL dialects are unable to double aggregate, or nest aggregations, so such an attempt triggers the error.\n\nSolutions\n---------\n\nThere are two possible solutions:\n\n1. [Use non-aggregate measures to perform non-aggregating SQL statements between measures.](#using_non_aggregate_measures)\n2. [Use a derived table to nest aggregations or double aggregate.](#using_derived_table_for_nested_aggregations)\n\n\u003cbr /\u003e\n\n### Using non-aggregate measures\n\n\n[Non-aggregate measures](/looker/docs/reference/param-measure-types#measure_type_categories) --- such as [`type: yesno`](/looker/docs/reference/param-measure-types#yesno) and [`type: number`](/looker/docs/reference/param-measure-types#number) --- are the only measures that can reference other measures or aggregations. Non-aggregate measures do not perform any aggregation and thus will not perform a double or nested aggregation. Measures of `type: number` or `type: yesno` act as placeholders so other measures or combinations of measures can be referenced within them.\n\n\nFor example, measures of `type: number` are used to perform calculations between measures and take any valid SQL expression that results in a number or an integer.\n\n\nThe following example uses a `type: number` to calculate the percentage of all orders that are cancelled: \n\n```\nmeasure: order_count { # Base measure #1\n type: count\n sql: ${order_id} ;;\n}\n\nmeasure: cancelled_orders { # Base measure #2\n type: count\n filters: [status: \"Cancelled\"]\n}\n\nmeasure: percent_cancelled_orders { # New measure\n type: number\n sql: (1.0*${cancelled_orders})/ISNULL(${order_count},0) ;;\n}\n```\n\n### Using a derived table for double or nested aggregations\n\n\nBut what if a nested aggregation is necessary for performing an analysis? For example, what if you need to know the average amount that customers spend in their customer lifetime (\"average customer lifetime value\")? This requires two levels --- a doubling or nesting --- of aggregations, including:\n\n1. A sum of sales, grouped by customer\n\n2. An average of that sum\n\n\nTo achieve this with LookML, you might try: \n\n```\nmeasure: total_revenue {\n type: sum\n sql: ${sale_price} ;;\n}\n\nmeasure: avg_customer_lifetime_value {\n type: average\n sql: ${total_revenue} ;;\n}\n```\n\n\nHowever, this will trigger the error because the `avg_customer_lifetime_value` measure is performing an aggregation on the `total_revenue` measure, which is already an aggregation. As previously discussed, most SQL dialects will trigger an error when double or nested aggregates are used in a query.\n\n\nTo achieve an average of the `total_revenue` sum in SQL, a subquery such as the following is needed: \n\n```\n SELECT AVG(s.sum) FROM (SELECT SUM(x) as sum FROM ...) AS s\n```\n\n\nThe equivalent solution in Looker is to create a [derived table](/looker/docs/derived-tables) to \"flatten\" the `total_lifetime_value` measure into a field that can be aggregated --- in Looker, this is called [*dimensionalizing a measure*](/looker/docs/best-practices/how-to-dimensionalize-a-measure). With a derived table, the `total_lifetime_value` measure becomes a [dimension](/looker/docs/reference/param-field-dimension). You can then create a measure of [`type: average`](/looker/docs/reference/param-measure-types#average) that references the `customer_lifetime_value` dimension: \n\n```\nview: customer_facts {\n derived_table: {\n sql:\n SELECT\n user_id,\n COALESCE(SUM(sale_price), 0) AS customer_lifetime_value\n FROM orders\n GROUP BY user_id;;\n }\n\n dimension: customer_lifetime_value {\n type: number\n sql: ${TABLE}.\"customer_lifetime_value\" ;;\n }\n\n measure: average_customer_lifetime_value {\n type: average\n sql: ${customer_lifetime_value} ;;\n }\n}\n```\n\n\nOnce the `customer_facts` derived table is [joined](/looker/docs/reference/param-explore-join) into an Explore, the `average_customer_lifetime_value` measure can be used to perform the desired analysis in an Explore without triggering any error."]]