[[["易于理解","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-30。"],[],[],null,["# How to dimensionalize a measure in Looker\n\nAs a general rule in SQL --- and, by extension, Looker --- you cannot group a query by\nthe results of an aggregate function\n(represented in Looker as [measures](/looker/docs/reference/param-field-measure)).\nYou can only group by unaggregated fields (represented in Looker as [dimensions](/looker/docs/reference/param-field-dimension)).\nIf you try to aggregate a measure in Looker, you will see the following\n[error](/looker/docs/best-practices/error-measures-with-looker-aggregations-reference-other-aggregations): \n\n```\nMeasures with Looker aggregations (sum, average, min, max, list types) may not reference other measures.\n```\n\n\nWhat if you need a way to change a measure (COUNT, SUM, AVG, MAX, etc.) into\na dimension, so that you can group by it to aggregate it (like a SUM of a COUNT or an AVG of a SUM),\n[filter](/looker/docs/filtering-and-limiting) by it (in the WHERE clause rather than a\n[HAVING](/looker/docs/filtering-and-limiting#filtering_measures:_calculates_first,_then_restricts_the_results) clause), or\n[pivot](/looker/docs/creating-and-editing-explores#pivoting_dimensions) on it in an Explore?\n\nUsing derived tables to dimensionalize a measure\n------------------------------------------------\n\n\nInternally at Looker the solution is called *dimensionalizing a measure* . This\nis because you redefine a measure as a*dimension* . This\nis accomplished by creating a\n[derived table](/looker/docs/derived-tables)\nthat includes the measure you want to dimensionalize in its SQL\ndefinition.\n\n### The process\n\n\nThe following example is based on a sample e-commerce dataset. The goal for this example is\nto create an [`type: average`](/looker/docs/reference/param-measure-types#average) measure that is based on an existing **Total Revenue** [`type: sum`](/looker/docs/reference/param-measure-types#sum) measure.\n\u003e *The following steps outline how to generate a SQL-based derived table. You can elect to create a LookML-based derived table, also known as a [native derived table (NDT)](/looker/docs/creating-ndts), as an alternative to SQL.*\n\n1. Start by setting up an [Explore query](/looker/docs/creating-and-editing-explores). Choose the appropriate fields, including the measure you want to dimensionalize.\n\n \u003cbr /\u003e\n\n In the example use case, the Explore **Data** table features **Total Revenue** grouped by **Users State** and **Users ID** :\n\n \u003cbr /\u003e\n\n2. Choose **Open in SQL Runner** from the **SQL** tab in the **Data** table to open the query in [SQL Runner](/looker/docs/sql-runner-basics):\n\n \u003cbr /\u003e\n\n3. After running the query in SQL Runner (by clicking the **Run** button) and confirming the results, choose the [**Add to Project**](/looker/docs/sql-runner-create-derived-tables#adding_to_a_lookml_project) option from the SQL Runner gear menu to open the **Add to Project** pop-up. *At this point you need to remove any row limit clause in the derived\n table SQL to ensure that all desired results are included in the query.*\n\n \u003cbr /\u003e\n\n \u003e *You can also choose [**Get Derived Table LookML**](/looker/docs/sql-runner-create-derived-tables#getting_the_lookml_for_a_derived_table) from the menu to copy and paste the generated LookML into your project manually.*\n4. From the **Add to Project** pop-up, select a project name from the **Project** drop-down, enter a name for your derived table view file, and select **Add**.\n5. Now that the derived table is in a view file, you can create a measure that aggregates the dimensionalized measure. For example, you can now create a `type: average` measure for the new total revenue dimension, `order_items_total_revenue`: \n\n ```\n dimension: order_items_total_revenue {\n type: number\n sql: ${TABLE}.order_items.total_revenue ;;\n value_format_name: usd\n }\n\n measure: average_revenue {\n type: average\n sql: ${order_items_total_revenue} ;;\n value_format_name: usd\n }\n \n ```\n6. Double-check that a [primary key](/looker/docs/reference/param-field-primary-key) is defined in the derived table.\n7. [Join](/looker/docs/reference/param-explore-join) the new view into the original Explore (or create a new Explore) to be able to create queries and content with the new fields.\n\nConclusion\n----------\n\n\nDimensionalizing measures with Looker derived tables unlocks new capabilities\nand provides the power to make further insights with your data. With the ability\nto **group by**a dimensionalized measure, filter by it\nin a WHERE clause (instead of HAVING), pivot on it, and create other dimensions\nbased on it, you can take your Explore queries, and content, to the next dimension.\n\n\nVisit the [Derived tables](/looker/docs/derived-tables) documentation page for more information about creating and using derived tables, along with considerations and performance optimization tips."]]