LuckyTemplates의 확장된 테이블

이 자습서에서는 여러분 모두가 DAX로 작업하는 동안 이미 접했을 것이라고 확신하는 매우 구체적인 시나리오인 확장된 테이블 을 살펴보겠습니다 . 확장된 표는 실제 작동 방식을 모르는 경우 계산을 망칠 수 있습니다. 이 블로그 하단에서 이 튜토리얼의 전체 비디오를 볼 수 있습니다.

이 예에서는 판매 테이블 , 고객 테이블 , 날짜 테이블 , 제품 테이블 , 제품 범주 테이블 및 제품 하위 범주 테이블 을 포함하는 Contoso 데이터베이스를 사용하고 있습니다 .

왼쪽 끝에는 제품, 범주, 하위 범주 및 판매 테이블 간에 일대다 관계가 있습니다. 우리는 또한 날짜와 판매뿐만 아니라 고객과 판매 사이에 일대다 관계가 있습니다.

목차

• 예 #1
• 예 #2
• 레드 판매 #1
• 레드 판매 #2
• 레드 판매 #3
• 확장된 테이블 확인
• 확장 테이블 정의
• 범주 열 분할 및 확장 테이블 사용
• 레드세일즈2 설명하기
• 레드 세일 설명하기 3
• DAX Studio를 사용하여 확장된 테이블 확인
• 결론

예 #1

범주 테이블의 이 범주 열에서 보고서를 만들고 고객 테이블에 있는 고객 수를 계산하는 측정값을 사용한다고 가정해 보겠습니다. 범주별로 고객 테이블의 숫자를 분할하려고 합니다.

범주 테이블에 필터를 적용하면 해당 필터는 하위 범주 테이블로 이동한 다음 제품 테이블에 도달한 다음 마지막으로 판매 테이블에 도달하여 필터링합니다. 그러나 양방향 필터링을 설정하지 않으면 해당 필터는 고객의 테이블을 필터링할 수 없습니다.

이 계산을 수정하기 위해 보고서로 돌아가 보겠습니다. CALCULATE 함수 내에서 이 계산을 래핑한 다음 Sales라고 쓸 수 있습니다. 이번에는 시각적 개체의 각 셀에 대해 동일한 숫자를 반복하지 않는다는 것을 알 수 있습니다.

이 계산이 올바른지 확인하기 위해 판매 테이블에서 고객 키를 가져와 집계한 다음 그에 대해 Count(Distinct)를 수행할 수 있습니다.

각 행에 대해 동일한 값을 반환하고 있음을 알 수 있습니다. CALCULATE 함수 내부의 판매 테이블을 사용하여 계산을 수정할 수 있었습니다.

예 #2

다음 예제로 넘어가겠습니다. 이를 위해 2007년, 2008년 또는 2009년에 빨간색 제품의 판매량을 확인하려고 합니다. 슬라이서의 선택에 따라 저도 1년 전으로 돌아가고 싶습니다.

예를 들어 2009년을 선택하면 2008년의 빨간색 판매를 보고하고 싶습니다. 2008을 선택하면 2007년의 빨간색 판매도 보고하고 싶습니다.

레드 판매 #1

Total Sales의 계산은 기본적으로 판매 데이터의 합계입니다. 행 컨텍스트에서 수량에 순 가격을 곱합니다.

새 측정값을 만들고 이름을 Red Sales로 지정하겠습니다. CALCULATE를 작성한 다음 Total Sales를 작성합니다. 제품의 색상이 빨간색임을 표시하기 위해 Sales 테이블을 할 것입니다 .

그런 다음 날짜 열의 날짜에 씁니다 .

이 계산을 카드 시각적 개체로 가져오면 공백이 생깁니다.

레드 판매 #2

여기서 무슨 일이 일어나고 있습니까? 그 계산을 다시 써보고 결과를 얻을 수 있는지 봅시다. 새 측정값을 만들고 이름을 Red Sales 2로 지정하고 계산의 첫 번째 부분을 Red Sales 1에 사용합니다.

첫 번째 CALCULATE에 대해 또 다른 CALCULATE를 시작하겠습니다.

이 측정값을 행렬로 가져오고 결과를 살펴보겠습니다. 2008을 선택하면 51,947이 됩니다. 2009년을 선택하면 24,343이 됩니다. 마지막으로 2010년을 선택하면 39,724가 됩니다.

레드 판매 #3

이 계산을 작성하는 다른 방법이 있습니다. 새 측정값을 작성하고 Red Sales 3이라고 지정한 다음 CALCULATE 함수를 사용합니다.

총 판매액을 계산하고 제품의 색상을 빨간색으로 작성하겠습니다. 그런 다음 날짜에 SAMEPERIODLASTYEAR 함수를 사용하십시오.

측정값 #3을 카드 시각적 개체로 드래그하면 이 두 카드 값이 동일한 값을 반환하는 것을 볼 수 있습니다. 이는 정확합니다.

그러나 올바른 값이 아닌 공백을 반환하기 때문에 첫 번째 계산에 문제가 있습니다.

여기서 실제로 무슨 일이 일어나는지 봅시다. 이제 확장된 테이블에 대한 몇 가지 계산을 살펴보았으므로 계산의 이면에 있는 이론을 이해해 보겠습니다.

확장 테이블이 무엇인지 이해하기 전에 여기에 있는 모든 테이블이 기본 테이블 이라는 것을 이해해야 합니다 .

그렇다면 이 테이블은 언제 확장 테이블이 될까요? 한 테이블과 다른 테이블 간에 다대일 관계를 생성하면 기본 테이블이 확장 테이블이 됩니다.

확장된 테이블 확인

그러나 테이블 확장이 실제로 발생하는지 어떻게 확인할 수 있습니까? 음, 모든 테이블에서 관련 키워드를 사용할 수 있습니다. 한쪽에서 열에 액세스할 수 있으면 테이블 확장이 발생할 수 있음을 알 수 있습니다.

판매 테이블로 이동하여 새 계산 열을 만들어 보겠습니다.

이 특정 제품 키에 대한 제품 테이블에서 제품 색상을 검색한다고 가정해 보겠습니다. 판매 테이블에서 실제로 확장할 수 있는 IntelliSense의 열 목록만 제공하는 RELATED를 사용합니다.

고객 테이블과 판매 테이블이 다대일 관계임을 알 수 있습니다. 고객 테이블 열, 날짜 테이블 열 및 제품 열 목록도 볼 수 있습니다.

Products[색상]을 선택하면 RELATED 키워드를 사용하여 판매 테이블에 새 열을 만들 수 있습니다. RELATED는 기본 테이블이 실제로 확장될 수 있는 테이블의 열에 대한 액세스만 제공합니다.

해당 관계의 특성을 다대일에서 다대다로 변경하면 해당 계산이 작동하지 않습니다.

이 관계의 특성을 다대다로 변경해 보겠습니다. 하단에서 경고 기호가 표시되는 것을 볼 수 있습니다.

판매 테이블로 돌아가면 Products[Color] 열이 존재하지 않거나 어떤 테이블과도 관계가 없다는 오류 메시지가 표시됩니다.

현재 컨텍스트에서 우리가 받는 경고는 그다지 사용자 친화적이지 않습니다. 기본적으로 특정 행 항목에 대해 하나의 단일 값에만 액세스할 수 없기 때문에 판매 테이블을 제품 테이블로 확장할 수 없음을 의미합니다.

그리고 다대다 관계를 사용하고 있기 때문에 테이블 확장이 발생하지 않고 RELATED가 작동하지 않습니다.

다이어그램 보기로 돌아가서 이 계산을 수정해 보겠습니다. 관계의 특성을 다대일로 변경하고 계산이 작동하도록 해당 관계를 활성화합니다.

확장 테이블 정의

보고서에서 이미 수행한 계산을 살펴보기 전에 확장 테이블의 정의를 반복해 보겠습니다.

스타 스키마가 있는 데이터 모델이 있는 경우 차원과 팩트 테이블 간에 다대일 관계가 있는 경우 팩트 테이블은 데이터 모델의 모든 테이블로 확장됩니다.

눈송이 스키마가 있는 경우 제품 하위 범주 테이블과 범주 테이블이 기본 테이블로 확장되며 이 경우에는 제품 테이블입니다. 판매 테이블은 다른 모든 테이블로 확장되는 기본 테이블입니다.

무대 뒤에서 판매 테이블에는 하나의 단일 테이블에 모든 열이 있습니다. 테이블 확장은 논리적 개념일 뿐이므로 데이터 모델의 크기를 확장하거나 늘리지는 않습니다.

확장 테이블은 테이블(기본 테이블)을 참조할 때와 다른 테이블과 다대일 관계가 있을 때만 나타납니다.

범주 열 분할 및 확장 테이블 사용

보고서 보기에서 이미 수행한 계산을 수정해 보겠습니다. 이 예에서는 제품 범주 테이블에서 범주 열을 기준으로 슬라이싱하고 고객 수를 세려고 합니다.

그래서 우리는 실제로 여기서 무엇을하고 있습니까? 확장된 판매 테이블을 참조로 사용하고 있습니다. 필터 컨텍스트에 범주 테이블의 값이 포함되면 해당 필터는 하위 범주 제품의 판매 테이블과 직접 판매에 도달합니다.

판매는 확장된 테이블이고 CALCULATE 함수 내에서 해당 참조를 사용하고 있으므로 판매 테이블에는 고객 테이블의 열도 포함됩니다. 판매 테이블에 필터를 적용하면 간접적으로 고객 테이블도 필터링됩니다.

빨간색 판매 계산으로 돌아가서 실제로 무슨 일이 일어나고 있는지 이해해 봅시다. 빈 계산부터 시작하겠습니다. 해당 측정값을 선택하면 중첩된 코드를 작성하고 있음을 알 수 있습니다. CALCULATE, 총 매출, 매출에 대한 FILTER, SAMEPERIODLASTYEAR가 있습니다.

그 계산을 단계적으로 중단합시다. 먼저 계산 외부에 존재하는 외부 필터 컨텍스트를 식별해야 합니다.

Calendar Year Number 슬라이서에서 2008년을 선택했습니다.

이 필터 컨텍스트에서 판매 테이블이 평가됩니다. 판매 테이블에는 2008년 달력 연도에 대한 행만 포함되며 제품 색상은 빨간색입니다. 여기에 두 개의 필터가 있습니다. 하나는 필터 컨텍스트에 의해 생성되고 다른 하나는 필터에 의해 생성됩니다 .

SAMEPERIODLASTYEAR는 연도가 2008년인 필터 컨텍스트에서 평가되고 있습니다. 2008년 날짜 목록을 수신하고 해당 날짜를 2008년에서 2007년으로 이동합니다. 이에 의해 반환될 테이블에는 다음 항목만 포함됩니다. 2007년 날짜.

이 두 작업이 완료되면 CALCULATE 함수는 필터 컨텍스트를 준비하고 이 두 필터를 필터 컨텍스트에 적용합니다. 이를 적용하면 제품 색상이 빨간색인 필터 컨텍스트가 있고 연도 열에는 2007년과 2008년에 대한 필터가 있습니다.

따라서 이 데이터 모델의 경우 서로 다른 두 해에 존재하는 단일 트랜잭션이 없습니다. CALCULATE가 and 조건 에서 이 두 필터를 병합하려고 하면 연도는 2008년과 2007년이어야 하고 제품 색상은 빨간색이어야 한다고 말합니다.

2008년의 필터 컨텍스트로 판매 테이블을 필터링할 때 날짜 테이블도 간접적으로 필터링합니다. 판매 안정은 날짜 안정과 다대일 관계를 가집니다.

관련 날짜에 대해 날짜 테이블에 있는 행 수를 식별하는 새 계산을 만들어 보겠습니다. CALCULATE를 작성한 다음 날짜 테이블의 작성할 것입니다 . 그런 다음 모든 판매 테이블을 필터링하고 달력 연도의 관련 날짜가 2008년과 같아야 한다고 말할 것입니다.

CALCULATE 내에서 날짜 테이블에 대한 필터를 참조하지 않았습니다. 달력 연도의 날짜가 2008년부터인지 확인하는 것뿐입니다. 이상적으로는 이 필터가 날짜 테이블을 필터링할 수 없어야 합니다. 또한 슬라이서에서 오는 필터 컨텍스트를 무시하는 함수를 사용하고 있습니다 .

이 계산을 위해 새 카드를 만들어 보겠습니다. 348개의 행을 반환하고 있음을 알 수 있습니다.

그렇다면 2500행의 날짜 테이블에서 348행만 반환하는 것이 어떻게 가능할까요? 확장된 테이블을 사용하려는 경우 다대일 관계를 통해 연결된 다른 테이블도 간접적으로 필터링합니다.

현재 연도에는 필터가 없지만 한쪽에 있는 차원 테이블에 대해 표시되는 행 수는 계속 제한됩니다.

판매 테이블을 반환할 때 날짜 테이블, 고객 테이블, 제품 테이블, 제품 범주 테이블 및 제품 하위 범주 테이블의 필터링된 버전도 반환합니다.

레드세일즈2 설명하기

다음 계산인 Red Sales 2로 이동하겠습니다. 시나리오에서 이 함수를 중첩하는 경우 외부 CALCULATE가 내부 CALCULATE에 대한 필터 컨텍스트를 준비해야 하기 때문에 외부 CALCULATE부터 시작하겠습니��.

슬라이서에서 달력 연도 2008년을 선택합니다. SAMEPERIODLASTYEAR 함수가 2008년 날짜를 가져오면 해당 날짜를 2007년으로 이동하고 내부 계산을 위한 FILTER 컨텍스트가 됩니다. 이 내부 CALCULATE는 2007년을 평가합니다.

FILTER 함수는 판매 테이블을 필터링하고 판매 테이블은 연도가 2007인 행으로만 제한됩니다. 2007에 대한 행이 있으면 관련 제품이 빨간색인지 확인합니다.

첫 번째 계산과 달리 서로 다른 두 계층을 반환하지 않습니다. 이러한 두 개의 서로 다른 계층은 FILTER 컨텍스트에 적용되지 않으므로 FILTER 함수에서 반환된 테이블에는 판매 테이블의 모든 행이 포함됩니다.

이 필터를 적용하면 2007년의 판매 금액과 빨간색에 해당하는 제품을 얻을 수 있지만 첫 번째 계산에서는 2008년과 2007년을 반환했습니다.

이번에는 SAMEPERIODLASTYEAR 함수를 사용하고 다른 CALCULATE 내에 CALCULATE 함수를 중첩하여 판매 테이블에 대한 필터 컨텍스트를 준비했습니다.

레드 세일 설명하기 3

세 번째 예에는 두 개의 명령문이 있는 매우 간단한 CALCULATE 함수가 있습니다. 하나는 제품 색상이 빨간색과 같다는 것이고 그 다음에는 날짜에 대한 SAMEPERIODLASTYEAR가 있습니다.

SAMEPERIODLASTYEAR 함수는 2007년 날짜만 포함하는 필터 컨텍스트에서 평가됩니다. 제품 색상은 제품 테이블 위에 빨간색 필터 컨텍스트를 적용하고, 차례로 판매 테이블을 필터링하고 다음에 대한 행만 포함합니다. 레드 제품.

이 두 값이 필터 컨텍스트에 적용되면 판매 테이블을 필터링하지만 확장된 판매 테이블은 필터링하지 않습니다. 코드의 어느 곳에서도 확장된 판매 테이블을 참조하지 않았음을 알 수 있습니다.

이것은 확장된 테이블을 참조하려는 경우 사용해야 하는 이상적인 시나리오입니다. 확장된 테이블을 사용할 때 계산이 매우 복잡해질 수 있으며 때때로 계산이 잘못된 결과를 반환하는 이유를 식별할 수 없습니다.

확장 테이블의 개념을 이해하지 못하는 경우 이 특정 코드를 모델 측정으로 개발한 다음 프로덕션에 배포할 수 있습니다. 다른 사용자는 이 측정값에 대해 다른 측정값을 만들기 시작할 수 있으며 단순히 DAX 언어에 대한 이해 수준이 없기 때문에 계산이 작동하지 않는 이유를 파악하지 못할 수 있습니다.

DAX로 작업하는 경우 단일 열을 사용하면 확장 테이블의 개념이 적용되지 않으므로 항상 단일 열에 필터를 배치하려고 합니다. 예를 들어 PRODUCTS [Color] = “Red” 를 사용하면 필터가 판매 테이블에 도달하지만 확장된 판매 테이블을 사용하지 않기 때문에 해당 필터는 고객의 테이블에 도달할 수 없습니다.

단일 열을 사용할 때 확장 테이블 개념을 언급하지 않습니다. 다른 테이블로 전파되지 않는 판매 테이블에 기본 필터를 적용하기만 하면 됩니다.

DAX Studio를 사용하여 확장된 테이블 확인

마무리하기 전에 DAX 스튜디오를 사용하여 Red Sales 3용 코드를 확인하겠습니다. 보기 탭으로 이동하여 성능 분석기를 클릭한 다음 기록을 시작하겠습니다. 해당 시각적 개체를 새로 고치고 빈 카드를 선택합니다.

외부 도구에서 DAX 스튜디오를 시작할 예정입니다.

하단의 결과 화면에서 공백이 표시되는 것을 볼 수 있습니다.

뒤에서 생성되는 쿼리를 이해하기 위해 서버 타이밍을 켭니다. Server Timings 탭으로 이동하여 모든 것을 볼 수 있도록 확장합니다.

왼쪽의 판매 테이블에서 JOIN을 수행하고 있습니다. 또한 제품 테이블의 제품 키에 대해 JOIN을 수행하고 있습니다.

WHERE 절에는 달력 연도의 날짜가 2008년과 같아야 하고 제품 색상이 빨간색이어야 한다고 명시되어 있습니다.

그런 다음 Dates[Date]라는 또 다른 조건이 있고 날짜 범위가 뒤따릅니다. 이 날짜는 무엇입니까? 이상적으로 이러한 날짜는 2008년에 속해야 하지만 Excel에서 이러한 숫자의 형식을 변경하면 2007년부터입니다.

이것이 우리가 빈 값을 반환하는 이유입니다. 역년은 2008년이어야 하고 날짜가 2007년이어야 한다는 AND 조건을 적용하는 것입니다. 이 2007년은 계산에 사용한 SAMEPERIODLASTYEAR 함수 때문입니다.

측정값과 참조를 Red Sales 2로 변경해 보겠습니다. 코드를 실행하면 날짜 테이블에서 날짜를 가져온 다음 2008년 달력 연도에 대한 날짜 열을 필터링하고 있음을 알 수 있습니다.

이번에는 WHERE 절에 필터를 적용하지 않고 달력 연도의 날짜가 2008년과 같아야 하기 때문에 결과를 반환할 수 있습니다.

LuckyTemplates에서 DISTINCTCOUNT를 사용하여 시간 경과에 따라 고객을 계산하는 숨겨진 DAX 트랩을 찾을 수 있는 위치
고급 DAX를 사용한 신규 고객 분석

결론

이 튜토리얼이 확장된 테이블이 무엇인지, 어떻게 계산을 망칠 수 있는지 이해하는 데 도움이 되었기를 바랍니다. 확장 테이블은 실제로 직관적이지 않으며 이해하기 쉽지도 않습니다.

확장된 테이블에 대한 자세한 내용을 보려면 LuckyTemplates TV 채널을 구독하는 것을 잊지 마십시오. 저와 다양한 콘텐츠 제작자가 항상 제공하는 엄청난 양의 콘텐츠가 있으며 모두 LuckyTemplates 및 Power Platform을 사용하는 방식을 개선하는 데 전념하고 있습니다.