온라인에서 제품을 판매하는 회사가 있고 총수익과 주주 배당금을 계산하기 위한 측정을 정의한다고 가정해 보겠습니다. 이를 수행할 수 있는 방법 중 하나는 다음과 같이 total_profit 측정 및 shareholder_dividends 측정 등 두 측정을 정의하는 것입니다.
measure: total_profit {
type: number
sql: SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost}) ;;
}
measure: shareholder_dividends
description: "We give shareholders 60% of our total profits."
type: number
sql: 0.6 * (SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost})) ;;
이 예시에서는 SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost}) 계산은 두 측정 모두에 대한 sql 매개변수에서 재사용됩니다. 오류 수정과 같이 이 계산의 정의를 업데이트해야 하는 경우 두 측정 모두에 대해 계산을 수동으로 업데이트해야 합니다.
shareholder_dividends 측정의 계산 내에서 total_profit 측정을 재사용하면 이러한 측정 정의를 더 쉽게 유지할 수 있습니다.
measure: total_profit {
type: number
sql: SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost}) ;;
}
measure: shareholder_dividends
description: "We give shareholders 60% of our total profits."
type: number
sql: 0.6 * ${total_profit} ;;
total_profit의 계산을 다른 계산에서 재사용할 수 있는 보다 간단한 측정으로 나눌 수 있습니다. 예를 들어 total_sales, total_revenue, total_cost, total_salary라는 type: sum 측정을 만들 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[],[],null,["# Maximizing code reusability with DRY LookML: Defining reusable measures for complex calculations\n\n| **Note:** This page is part of the [Looker cookbook: Maximizing code reusability with DRY LookML](/looker/docs/best-practices/dry-lookml-cookbook).\n\nWhen you're defining complex calculations in LookML, it can be helpful to break them down into intermediate steps that involve simpler calculations. By creating intermediate measures, you make your calculations more readable, easier to maintain, and less error-prone, since you only need to ensure that each intermediate calculation is correct in one place.\n\nThis page provides an [example](#example_breaking_a_complex_calculation_into_intermediate_measures) of how you can make your calculations in LookML more readable and maintainable by defining intermediate measures to break complex calculations into smaller, more manageable steps.\n\nIngredients\n-----------\n\n- The LookML [`measure`](/looker/docs/reference/param-field-measure) parameter\n- The [`sql`](/looker/docs/reference/param-field-sql) parameter of a measure\n- A measure of [`type: sum`](/looker/docs/reference/param-measure-types#sum)\n- A measure of [`type: number`](/looker/docs/reference/param-measure-types#number)\n- The LookML [`hidden`](/looker/docs/reference/param-field-hidden) parameter (for fields)\n\nPrerequisites\n-------------\n\n- [A configured LookML model](/looker/docs/generating-a-model#when_you_need_to_configure_models)\n- [Permissions to develop LookML](/looker/docs/admin-panel-users-roles#permission_sets)\n\nExample: Breaking a complex calculation into intermediate measures\n------------------------------------------------------------------\n\nSuppose you have a company that sells products online, and you want to define measures to calculate total profit and shareholder dividends. One way to do this would be to define two measures: a `total_profit` measure and a `shareholder_dividends` measure, as follows: \n\n\n measure: total_profit {\n type: number\n sql: SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost}) ;;\n }\n\n measure: shareholder_dividends\n description: \"We give shareholders 60% of our total profits.\"\n type: number\n sql: 0.6 * (SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost})) ;;\n\nIn this example, the calculation `SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost})` is reused in the `sql` parameter for both measures. If you need to update the definition of this calculation, such as to correct an error, you would have to update the calculation manually for both measures.\n\nYou can make these measure definitions easier to maintain by reusing the `total_profit` measure within the calculation in the `shareholder_dividends` measure: \n\n\n measure: total_profit {\n type: number\n sql: SUM(${orders.sale_price}) - SUM(${employees.salary}) - SUM(${products.cost}) ;;\n }\n\n measure: shareholder_dividends\n description: \"We give shareholders 60% of our total profits.\"\n type: number\n sql: 0.6 * ${total_profit} ;;\n\nYou may want to break the calculation in `total_profit` into even simpler measures that can be reused in other calculations. For example, you can create measures of `type: sum` called `total_sales`, `total_revenue`, `total_cost`, and `total_salary`: \n\n\n measure: total_sales {\n hidden: yes\n type: sum\n sql: ${orders.sale_price} ;;\n }\n\n measure: total_revenue {\n hidden: yes\n type: number\n sql: ${total_sales} ;;\n }\n\n measure: total_cost {\n hidden: yes\n type: sum\n sql: ${products.cost} ;;\n }\n\n measure: total_salary {\n hidden: yes\n type: sum\n sql: ${employees.salary} ;;\n }\n\n| **Note:** You can set the `hidden` parameter to `yes` to hide intermediate fields that you don't want to surface in the Explore UI for users.\n\nYou can then reuse the intermediate fields you have defined as follows: \n\n\n measure: total_expenses {\n type: number\n sql: ${total_cost} + ${total_salary} ;;\n }\n\n measure: total_profit {\n type: number\n sql: ${total_revenue} - ${total_expenses} ;;\n }\n\n measure: shareholder_dividends {\n description: \"We give shareholders 60% of our total profits.\"\n type: number\n sql: 0.6 * ${total_profit} ;;\n }\n\nAlthough you have defined more measures, these intermediate measures can be reused within other calculations, and it will be easier correct a mistake or make any changes to calculations that are used in multiple measures."]]