DAX 주간 계산 – LuckyTemplates 시간 인텔리전스 문제

오늘의 자습서에서는 시간 인텔리전스 계산에서 DAX 주간 세분성으로 인해 발생하는 일반적인 문제를 처리하는 방법에 대한 몇 가지 기술과 팁을 제공합니다. 이 블로그 하단에서 이 튜토리얼의 전체 비디오를 볼 수 있습니다.

최근에 LuckyTemplates에서 이전 주 값을 얻는 방법에 대한 자습서를 수행했습니다. 그 이후로 시간 인텔리전스, 특히 DAX 주간 값과 관련된 몇 가지 질문을 받았습니다. 몇 주가 실제로 시간 인텔리전스 영역에서 가장 제대로 작동하지 않는 단위이기 때문에 이는 놀라운 일이 아닙니다.

월의 경우 1년은 항상 12개월입니다. 분기의 경우 항상 4개 분기가 있습니다. 1주일은 7일이고 1년은 52주(364일)이기 때문에 주는 다릅니다. 그래서, 당신은 거기에 어울리는 여분의 날이 있습니다. 윤년에는 이틀이 더 있습니다.

따라서 ISO 주 번호에 대한 번호 매기기 체계에 따라 때로는 52주, 때로는 53주로 몇 년 후에 끝납니다. 53주차는 가장 많은 문제를 일으킬 것입니다.

목차

• DAX 주간 계산의 시간 인텔리전스 문제
• 결론

DAX 주간 계산의 시간 인텔리전스 문제

이 예에서는 총 현물 가격을 사용하고 있습니다. 합계를 사용하면 시각화하고 이야기하기가 더 쉽습니다.

이 경우 각 연도에 해당 연도에 53주가 있었는지 여부에 관계없이 53주에 대한 선을 표시하려고 합니다. 따라서 2018년과 2019년에는 53주차가 없지만 2020년에는 있습니다. 우리는 53번째 줄이 매년 포함되도록 일관성을 유지하기를 원합니다. 그러나 53년이 아닌 연도에 대해서는 메트릭이 공백이 됩니다.

이를 수행하는 일반적인 방법 중 하나는 데이터가 없는 항목 표시로 이동하여 켜져 있는지 확인하는 것입니다. 이 경우에는 켜져 있지만 실제 행이 있지만 해당 행과 연결된 데이터가 없을 때 작동하기 때문에 도움이 되지 않습니다. 이 경우 행이 없습니다.

또는 Remove Filters 사용과 같은 기술은 제거할 것이 없기 때문에 작동하지 않습니다. 해당 행의 필터가 존재하지 않습니다. 따라서 문제는 해당 행이 존재하지 않는 각 연도에 해당 행을 삽입하는 방법입니다. 그리고 이것은 실제로 데이터 모델링 문제가 됩니다.

우리가 잠재적으로 할 수 있는 것 중 하나는 매년 53번째 주를 시각적 개체에 강제로 적용하는 것으로 날짜 테이블을 필터링하는 눈송이 체계로 이동하는 것입니다. 이를 위해 떠오르는 함수는 입니다 .

CROSSJOIN은 관계가 있을 수도 있고 없을 수도 있는 두 필드를 일치시키는 데 사용됩니다. 또는 또는 다른 테이블 함수 와 달리 관계를 가질 필요가 없습니다 .

이 경우 CROSSJOIN은 두 개의 열을 가져와 데이터 세트에 존재하는지 여부에 관계없이 두 열의 모든 조합을 생성합니다. 그것이 바로 우리가 원하는 것입니다.

열에서 테이블을 생성하기 위한 있습니다 . CROSSJOIN은 두 개의 테이블을 가져온 다음 ISO 주 번호에 대한 VALUES를 가져오고 우리는 그것들을 함께 일치시킵니다. 그러면 매년 53주가 됩니다.

그런 다음 테이블에 세 번째 열을 추가합니다. 파워 쿼리에서 이 작업을 수행할 수 있지만 DAX에서 논리를 표시하는 것이 더 쉽습니다. 여기서 우리가 하는 일은 실제로 연도를 하이픈으로 연결한 다음 주 번호를 연결하여 Dates 테이블에 연결할 키 필드를 갖게 하는 것입니다.

그러나 Dates 테이블에서 키 필드가 작동하는 방식이 4자리 연도 하이픈과 2자리 주이기 때문에 여기에서 조금 더 작업을 수행해야 합니다. 따라서 ISO 주 번호가 두 자리인 경우 간단한 연결을 수행할 수 있습니다. 한 자리 숫자인 경우에는 연도 번호를 취한 다음 하이픈, 선행 0, 주 번호와 연결해야 합니다.

데이터가 있으면 데이터 모델에서 해당 테이블을 가져오고 Week & Year 열을 찾을 수 있습니다. 그런 다음 일대다 관계로 연결합니다. 저는 항상 이 옵션을 관련 필드를 카드 상단에 고정하여 확인할 때 바로 볼 수 있도록 하는 것을 좋아합니다.

비주얼로 돌아가면 행을 변경해야 합니다. 연도 및 주 번호 대신 CROSSJOIN 테이블의 연도 및 주 번호를 사용하려고 합니다. 이제 2018년 53번째 주에 공백이 있고 2019년 53번째 주에 공백이 있습니다. 2020년에는 53번째 주가 있기 때문에 실제 숫자가 있습니다.

이제 Star Schema 모델에서 벗어났다는 사실을 제외하면 여기서 멈출 수 있습니다. LuckyTemplates의 스타 스키마에서 벗어날 때마다 일반적으로 모범 사례로 간주되는 영역을 벗어나게 됩니다.

따라서 Snowflake Schema의 경우 큰 위반이 아닙니다. 꼭 사용하고 싶은 경우가 있지만 피할 수 있으면 해보세요. 중복을 줄이지 만 반드시 크기는 아닙니다. 스트레이트 카운트 측정을 사용할 수 있지만 성능 문제와 잠재적인 유용성 문제가 있으며 DAX 복잡성이 확실히 증가합니다. 이는 테이블 간에 계층 구조를 구축하는 것을 방지하며 아마도 가장 문제가 되는 것은 여러 필드 간에 슬라이서를 동기화하는 기능을 망칠 수 있다는 것입니다.

이렇게 하면 문제가 해결되지만 좋지 않은 방식으로 해결됩니다. 이것보다 더 잘할 수 있는지 봅시다. 다른 데이터 모델을 살펴보겠습니다. 이 모델에서는 정확히 동일한 데이터, 날짜 및 현물 가격을 사용했지만 이번에는 CROSSJOIN 테이블을 제거했습니다. 여전히 존재하지만 연결되어 있지 않습니다.

그러나 DAX를 보면 다른 보고서에서 해당 테이블을 만든 것과 정확히 동일한 DAX라는 것을 알 수 있습니다. 따라서 물리적 관계로 연결한 다음 Star Schema를 위반하고 Snowflake Schema로 변환하는 대신 Star Schema를 유지하고 가상 관계만 사용할 수 있습니다.

이를 위해 라는 함수를 사용합니다 . 테이블 간의 관계를 생성하지만 가상으로 수행합니다. 컨텍스트를 변경할 것이기 때문에 사용하여 이 작업을 수행합니다 . 이 경우 문맥은 관계에 관한 것입니다. 따라서 총 현물 가격과 TREATAS가 있습니다. 해당 열을 테이블로 변환하는 있습니다 .

그런 다음 우리가 만든 키인 연도 및 주 필드가 있습니다. Dates 테이블의 Week & Year에 가상 방식으로 결합했습니다. 이제 물리적 관계가 있을 때와 동일한 방식으로 Star Schema를 위반하지 않고 Dates 테이블을 필터링하는 Crossjoint 테이블이 있습니다.

이제 해당 총 현물 가격 TREATAS를 매트릭스로 가져오고 드롭할 수 있으며 우리가 보는 것은 정확히 동일한 총계입니다. 이러한 방식으로 우리는 데이터 모델을 방해하지 않고 Snowflake Schema와 관련하여 언급한 단점을 발생시키지 않고 그렇게 했습니다.

DAX 및 파워 쿼리를 사용하여 LuckyTemplates 이전 주 값 가져오기 LuckyTemplates에서
DAX로 주간 판매 계산 DAX에서
시간 인텔리전스: 시작 기간을 동적으로 선택하는 방법

결론

이 자습서에서는 LuckyTemplates에서 DAX 주간 계산 문제를 해결하는 몇 가지 방법을 보여 주었습니다. 하나는 CROSSJOIN을 사용하는 것이지만 몇 가지 단점이 있습니다. 두 번째 방법은 TREATAS를 사용하여 가상 관계를 만들고 스타 스키마 접근 방식을 위반하지 않는 것입니다.

그것은 그 주 53 문제를 다루는 데 매우 유용한 기술 중 하나입니다. 도움이 되었기를 바랍니다. 나는 이것에 대한 당신의 생각을 알고 싶습니다. 아래 댓글로 알려주세요.

모두 제일 좋다,