다음을 통해 공유

Power BI Desktop의 복합 모델 지침

  • 아티클

이 문서는 Power BI 복합 모델을 개발하는 데이터 모델러를 대상으로 작성되었습니다. 복합 모델 사용 사례를 설명하고 디자인 지침을 제공합니다. 특히, 이 지침은 복합 모델이 솔루션에 적합한지 여부를 결정하는 데 도움이 됩니다. 그러므로 이 문서는 최적의 복합 모델 및 보고서를 디자인하는 데 도움이 될 것입니다.

참고 항목

복합 모델에 대한 소개는 이 문서에서 다루지 않습니다. 복합 모델에 대해 잘 모르는 경우 먼저 Power BI Desktop에서 복합 모델 사용 문서를 읽는 것이 좋습니다.

복합 모델은 하나 이상의 DirectQuery 원본으로 구성되기 때문에 모델 관계, DirectQuery 모델, DirectQuery 모델 디자인 지침을 자세히 이해하는 것도 중요합니다.

복합 모델 사용 사례

정의에 따라 복합 모델은 여러 원본 그룹을 결합합니다. 원본 그룹은 가져온 데이터 또는 DirectQuery 원본에 대한 연결을 나타낼 수 있습니다. DirectQuery 원본은 관계형 데이터베이스 또는 Power BI 의미 체계 모델 또는 Analysis Services 테이블 형식 모델일 수 있는 다른 테이블 형식 모델일 수 있습니다. 테이블 형식 모델이 다른 테이블 형식 모델에 연결되는 것을 체인이라고 합니다. 자세한 내용은 Power BI 의미 체계 모델 및 Analysis Services에 DirectQuery 사용을 참조하세요.

참고 항목

모델이 테이블 형식 모델에 연결되지만 추가 데이터로 확장하지 않는 경우 복합 모델이 아닙니다. 이 경우 원격 모델에 연결하는 DirectQuery 모델이므로 하나의 원본 그룹만 구성됩니다. 이 유형의 모델을 생성하여 테이블 이름, 열 정렬 순서 또는 형식 문자열과 같은 원본 모델 개체 속성을 수정할 수 있습니다.

테이블 형식 모델에 연결하는 것은 엔터프라이즈 의미 체계 모델(Power BI 의미 체계 모델 또는 Analysis Services 모델인 경우)을 확장할 때 특히 관련이 있습니다. 엔터프라이즈 의미 체계 모델은 데이터 웨어하우스의 개발 및 운영의 기본 요소입니다. 비즈니스 정의 및 용어를 제시하기 위해 데이터 웨어하우스의 데이터에 대한 추상화 계층을 제공합니다. 일반적으로 물리적 데이터 모델과 Power BI와 같은 보고 도구 사이의 링크로 사용됩니다. 대부분의 조직에서는 중앙 팀에서 관리하므로 엔터프라이즈로 설명됩니다. 자세한 내용은 엔터프라이즈 BI 사용 시나리오를 참조하세요.

다음과 같은 상황에서 복합 모델 개발을 고려할 수 있습니다.

  • 모델이 DirectQuery 모델일 수 있으며 성능을 향상시키려고 합니다. 복합 모델에서는 각 테이블에 대해 적절한 저장소를 설정하여 성능을 향상시킬 수 있습니다. 사용자 정의 집계를 추가할 수도 있습니다. 이러한 최적화는 모두 이 문서의 뒷부분에서 설명합니다.
  • DirectQuery 모델을 모델로 가져와야 하는 추가 데이터와 결합하려고 합니다. 다른 데이터 원본 또는 계산된 테이블에서 가져온 데이터를 로드할 수 있습니다.
  • 두 개 이상의 DirectQuery 데이터 원본을 단일 모델로 결합하려고 합니다. 이러한 원본은 관계형 데이터베이스 또는 기타 테이블 형식 모델일 수 있습니다.

참고 항목

복합 모델은 특정 외부 분석 데이터베이스에 대한 연결을 포함할 수 없습니다. 이러한 데이터베이스에는 SAP HANA를 다차원 원본으로 취급할 때 SAP Business Warehouse 및 SAP HANA가 포함됩니다.

다른 모델 디자인 옵션 평가

Power BI 복합 모델은 특정 디자인 문제를 해결할 수 있지만 성능 저하에 영향을 줄 수 있습니다. 또한 경우에 따라 예기치 않은 계산 결과가 발생할 수 있습니다(이 문서의 뒷부분에서 설명). 이러한 이유로 다른 모델 디자인 옵션이 있는 경우에 평가합니다.

가능하면 가져오기 모드에서 모델을 개발하는 것이 좋습니다. 이 모드는 가장 뛰어난 디자인 유연성과 최고의 성능을 제공합니다.

그러나 대규모 데이터 볼륨 또는 거의 실시간 데이터에 대한 보고와 관련된 과제를 항상 가져오기 모델로 해결할 수는 없습니다. 이러한 사용 사례에서는 단일 데이터 원본에 데이터가 저장되는 경우 DirectQuery 모드에서 지원하는 DirectQuery 모델을 고려할 수 있습니다. 자세한 내용은 Power BI Desktop의 DirectQuery 모델을 참조하세요.

팁

목표가 더 많은 데이터를 사용하여 기존 테이블 형식 모델을 확장하는 것뿐이라면 가능할 때마다 해당 데이터를 기존 데이터 원본에 추가합니다.

테이블 스토리지 모드

복합 모델에서는 계산된 테이블을 제외하고 각 테이블에 대해 저장소 모드를 구성할 수 있습니다.

  • DirectQuery: 대규모 데이터 볼륨을 나타내는 테이블 또는 거의 실시간 결과를 제공해야 하는 테이블에 이 모드를 설정하는 것이 좋습니다. 이러한 테이블로 데이터를 가져올 수 없습니다. 일반적으로 이러한 테이블은 요약된 테이블인 팩트 형식 테이블입니다.
  • 가져오기: 이 모드는 DirectQuery 또는 하이브리드 모드에서 팩트 테이블을 필터링하고 그룹화하는 데 사용하지 않는 테이블에 설정하는 것이 좋습니다. 또한 이 모드는 DirectQuery 모드에서 지원되지 않는 원본을 기반으로 하는 테이블의 유일한 옵션입니다. 계산된 테이블은 항상 가져오기 테이블입니다.
  • 이중: 동일한 원본에서 DirectQuery 팩트 유형 테이블과 함께 쿼리될 가능성이 있는 차원 유형 테이블에 이 모드를 설정하는 것이 좋습니다.
  • 하이브리드: 최신 데이터 변경 내용을 실시간으로 포함하고 싶거나 가져오기 파티션을 통해 가장 자주 사용하는 데이터에 빠르게 액세스하고 자주 사용하지 않는 데이터 대부분은 데이터 웨어하우스에 남겨두고 싶다면, 가져오기 파티션과 단일 DirectQuery 파티션을 추가하여 이 모드를 설정하는 것이 좋습니다.

Power BI가 복합 모델을 쿼리할 수 있는 몇 가지 시나리오는 다음과 같습니다.

  • 쿼리가 가져오기 또는 이중 테이블만 반환: Power BI는 모델 캐시에서 모든 데이터를 검색합니다. 가능한 가장 빠른 성능을 제공합니다. 이 시나리오는 필터 또는 슬라이서 시각적 개체가 쿼리하는 차원 유형 테이블에 일반적입니다.
  • 동일한 원본에서 이중 테이블 또는 DirectQuery 테이블을 쿼리: Power BI는 하나 이상의 기본 쿼리를 DirectQuery 원본에 전송하여 검색됩니다. 특히 원본 테이블에 적절한 인덱스가 있을 때 우수한 성능을 제공합니다. 이 시나리오는 이중 차원 유형 테이블 및 DirectQuery 팩트 유형 테이블과 관련된 쿼리에 일반적입니다. 이러한 쿼리는 원본 그룹 내이므로 모든 일대일 또는 일대다 관계는 일반 관계로 평가됩니다.
  • 동일 원본의 이중 테이블 또는 하이브리드 테이블 쿼리: 이 시나리오는 이전 두 시나리오의 조합에 해당합니다. Power BI는 가져오기 파티션에서 사용할 수 있을 때 모델 캐시에서 데이터를 검색하고, 그렇지 않으면 하나 이상의 네이티브 쿼리를 DirectQuery 원본으로 보냅니다. 데이터 웨어하우스에서 데이터 한 조각만 쿼리되므로 가장 빠른 성능을 제공하며, 원본 테이블에 적절한 인덱스가 있다면 성능이 더욱 개선됩니다. 이중 차원 유형 테이블과 DirectQuery 팩트 유형 테이블의 경우 이러한 쿼리는 원본 그룹 내에 있으며, 따라서 일대일 또는 일대다 관계는 일반 관계로 평가됩니다.
  • 기타 모든 쿼리: 이러한 쿼리에는 원본 그룹 간 관계가 포함됩니다. 이는 가져오기 테이블이 DirectQuery 테이블과 관련이 있거나, 이중 테이블이 다른 원본의 DirectQuery 테이블과 관련되어 있기 때문입니다(이 경우에는 가져오기 테이블로 동작함). 모든 관계는 제한된 관계로 평가됩니다. 또한 DirectQuery가 아닌 테이블에 적용된 그룹화는 구체화된 하위 쿼리(가상 테이블)로 DirectQuery 원본에 전송되어야 함을 의미합니다. 이 경우 기본 쿼리는 특히, 대규모 그룹화 집합에서는 비효율적일 수 있습니다.

요약하면, 다음과 같이 하는 것이 좋습니다.

  • 복합 모델이 적합한 솔루션이라고 간주합니다. 이 모델은 다른 데이터 원본의 모델 수준 통합을 허용하지만 디자인 복잡성 때문에 불리한 면도 있을 수 있습니다(이 문서의 뒷부분에서 설명).
  • 테이블이 대규모 데이터 볼륨을 저장하는 팩트 유형 테이블인 경우 또는 거의 실시간 결과를 제공해야 하는 경우 저장소 모드를 DirectQuery로 설정합니다.
  • 증분 새로 고침 정책과 실시간 데이터를 정의하거나 TOM, TMSL 또는 타사 도구를 사용해 팩트 테이블을 분할하여 하이브리드 모드를 사용하는 것이 좋습니다. 자세한 내용은 의미 체계 모델에 대한 증분 새로 고침 및 실시간 데이터 및 고급 데이터 모델 관리 사용 시나리오를 참조하세요.
  • 테이블이 차원 유형 테이블이고 동일한 원본 그룹에 있는 DirectQuery 또는 하이브리드 팩트 유형 테이블과 함께 쿼리되는 경우 저장소 모드를 이중으로 설정합니다.
  • 원본 데이터베이스와 동기화된 이중 및 하이브리드 테이블(및 모든 계산된 종속 테이블)에 대한 모델 캐시를 유지하기 위해 적절한 새로 고침 빈도를 설정합니다.
  • 제한된 관계는 관련 열 값이 일치하지 않을 때 쿼리 결과에서 행을 제거하므로 원본 그룹(모델 캐시 포함) 전체에서 데이터 무결성을 보장하기 위해 노력합니다.
  • 가능하면 효율적인 조인, 필터링 및 그룹화를 위해 적절한 인덱스를 사용하여 DirectQuery 데이터 원본을 최적화합니다.

사용자 정의 집계

DirectQuery 테이블에 사용자 정의 집계를 추가할 수 있습니다. 이는 상위 세분성 쿼리의 성능을 개선하기 위한 것입니다.

집계는 모델에 캐시되는 경우 모델 테이블처럼 사용할 수는 없지만 가져오기 테이블로 동작합니다. DirectQuery 모델에 가져오기 집계를 추가하면 복합 모델이 생성됩니다.

참고 항목

일부 파티션이 가져오기 모드에서 작동하므로 하이브리드 테이블은 집계를 지원하지 않습니다. 개별 DirectQuery 파티션 수준으로 집계를 추가할 수는 없습니다.

집계는 기본 규칙을 따르는 것이 좋습니다. 행 수가 기본 테이블의 1/10 이하여야 합니다. 예를 들어 기본 테이블이 10억 행을 저장하는 경우 집계 테이블은 1억 행을 초과하지 않아야 합니다. 이 규칙은 집계를 만들고 유지 관리하는 비용을 기준으로 적절한 성능 향상을 보장합니다.

교차 원본 그룹 관계

모델 관계가 원본 그룹에 걸쳐 있는 경우 이를 교차 원본 관계라고 합니다. 교차 원본 그룹 관계도 "한쪽"이 보장되지 않기 때문에 제한된 관계입니다. 자세한 내용은 관계 평가를 참조하세요.

참고 항목

경우에 따라 교차 원본 그룹 관계를 만들지 않도록 할 수 있습니다. 이 도움말 뒷부분의 동기화 슬라이서 사용 항목을 참조하세요.

교차 원본 그룹 관계를 정의할 때는 다음 권장 사항을 고려합니다.

  • 낮은 카디널리티 관계 열 사용: 최상의 성능을 위해 관계 열의 카디널리티는 낮은 것이 좋습니다. 즉, 50,000개 미만의 고유 값을 저장해야 합니다. 이 권장 사항은 테이블 형식 모델을 결합할 때와 텍스트가 아닌 열에 대해 특히 그렇습니다.
  • 큰 텍스트 관계 열은 사용하지 않음: 관계에서 텍스트 열을 사용해야 하는 경우 카디널리티에 텍스트 열의 평균 길이를 곱하여 필터의 예상 텍스트 길이를 계산합니다. 가능한 텍스트 길이는 1,000,000자를 초과하면 안 됩니다.
  • 관계 세분성 향상: 가능하면 더 높은 수준의 세분성으로 관계를 만듭니다. 예를 들어 날짜 키에 날짜 테이블을 연결하는 대신 월 키를 대신 사용합니다. 이 디자인 접근 방식을 사용하려면 관련 테이블에 월 키 열이 포함되어야 하며 보고서는 일일 팩트를 표시할 수 없습니다.
  • 간단한 관계 디자인을 달성하기 위해 노력: 필요할 경우에만 교차 원본 그룹 관계를 만들고 관계 경로의 테이블 수를 제한합니다. 이 디자인 접근 방식은 성능을 향상하고 모호한 관계 경로를 방지하는 데 도움이 됩니다.

Warning

Power BI Desktop은 원본 그룹 간 관계의 유효성을 철저히 검사하지 않기 때문에 모호한 관계를 만들 수 있습니다.

교차 원본 그룹 관계 시나리오 1

복잡한 관계 디자인의 시나리오와 서로 다르지만 그것이 어떻게 유효한 결과를 생성하는지 생각해보세요.

이 시나리오에서 원본 그룹 A의 Region 테이블은 원본 그룹 B의 Date 테이블 및 Sales 테이블과 관계가 있습니다. Region 테이블과 Date 테이블 간의 관계는 활성 상태이고 Region 테이블과 Sales 테이블 간의 관계는 비활성화 상태입니다. 또한 원본 그룹 B에 있는 Region 테이블과 Sales 테이블 간에 활성 관계가 있습니다. Sales 테이블에는 TotalSales라는 측정값이 포함되고 Region 테이블에는 RegionalSales 및 RegionalSalesDirect라는 두 개의 측정값이 포함됩니다.

이전 단락에 설명된 시나리오 1 모델 디자인을 보여 주는 다이어그램

측정값 정의는 다음과 같습니다.

TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID]))

RegionalSales 측정값은 TotalSales 측정값을 참조하지만 RegionalSalesDirect 측정값은 참조하지 않습니다. 대신 RegionalSalesDirect 측정값은 TotalSales 측정값의 식인 SUM(Sales[Sales]) 식을 사용합니다.

결과의 차이는 미묘합니다. Power BI는 RegionalSales 측정값을 평가할 때 Region 테이블의 필터를 Sales 테이블과 Date 테이블 모두에 적용합니다. 따라서 필터도 Date 테이블에서 Sales 테이블로 전파됩니다. 반대로 Power BI는 RegionalSalesDirect 측정값을 평가할 때 Region 테이블에서 Sales 테이블로만 필터를 전파합니다. 식이 의미상 동일하더라도 RegionalSales 측정값과 RegionalSalesDirect 측정값에서 반환된 결과는 다를 수 있습니다.

Important

원격 원본 그룹의 측정값인 식과 함께 CALCULATE 함수를 사용할 때마다 계산 결과를 철저하게 테스트합니다.

교차 원본 그룹 관계 시나리오 2

교차 원본 그룹 관계에 카디널리티가 높은 관계 열이 있는 시나리오를 생각해보세요.

이 시나리오에서 Date 테이블은 DateKey 열의 Sales 테이블과 관련됩니다. DateKey 열의 데이터 형식은 정수이며 yyyymmdd 형식을 사용하는 정수를 저장합니다. 테이블은 다른 원본 그룹에 속합니다. 또한 Date 테이블의 가장 빠른 날짜는 1900년 1월 1일이고 가장 늦은 날짜는 2100년 12월 31일이므로 높은 카디널리티 관계입니다. 따라서 테이블에는 총 73,414개의 행이 있습니다(1900-2100 시간 범위의 각 날짜에 대한 행 하나).

이전 단락에 설명된 시나리오 2 모델 디자인을 보여 주는 다이어그램

우려되는 문제는 두 가지가 있습니다.

하나는 Date 테이블 열을 필터로 사용하면 필터 전파가 Sales 테이블의 DateKey 열을 필터링하여 측정값을 평가합니다. 2022년과 같이 1년으로 필터링하는 경우 DAX 쿼리에는 Sales[DateKey] IN { 20220101, 20220102, …20221231 }과 같은 필터 식이 포함됩니다. 필터 식의 값 수가 많거나 필터 값이 긴 문자열인 경우 쿼리의 텍스트 크기가 매우 커질 수 있습니다. Power BI가 긴 쿼리를 생성하고 데이터 원본이 쿼리를 실행하는 데 비용이 많이 듭니다.

다른 하나는 Year, Quarter 또는 Month와 같은 Date 테이블 열을 그룹화 열로 사용하면 다음과 같은 필터가 생성됩니다. 연도, 분기 또는 월 및 DateKey 열 값의 모든 고유한 조합을 포함합니다. 그룹화 열 및 관계 열에 대한 필터를 포함하는 쿼리의 문자열 크기가 매우 커질 수 있습니다. 그룹화 열의 수 및/또는 조인 열(DateKey 열)의 카디널리티가 큰 경우 특히 그렇습니다.

성능 문제를 해결하려면 다음을 수행하면 됩니다.

  • 데이터 원본에 Date 테이블을 추가하면 단일 원본 그룹 모델이 생성됩니다(즉, 더 이상 복합 모델이 아님).
  • 관계의 세분성을 높입니다. 예를 들어 두 테이블에 MonthKey 열을 추가하고 해당 열에서 관계를 만들 수 있습니다. 그러나 관계의 세분성을 높이면 일일 판매 활동에 대해 보고하는 기능이 손실됩니다(Sales 테이블의 DateKey 열을 사용하지 않는 한).

교차 원본 그룹 관계 시나리오 3

교차 원본 그룹 관계의 테이블 간에 일치하는 값이 없는 시나리오를 생각해보세요.

이 시나리오에서 원본 그룹 B의 Date 테이블은 해당 원본 그룹의 Sales 테이블 및 A 그룹의 Target 테이블과 관계가 있습니다. 모든 관계는 Year 열과 관련된 Date 테이블의 일대다 관계입니다. Sales 테이블에는 판매 금액을 저장하는 SalesAmount 열이 있고 Target 테이블에는 목표 금액을 저장하는 TargetAmount 열이 있습니다.

이전 단락에 설명된 시나리오 3 모델 디자인을 보여 주는 다이어그램

Date 테이블에는 2021년과 2022년이 저장됩니다. Sales 테이블에는 2021년(100) 및 2022년(200년)의 매출액이 저장되고 Target 테이블은 향후 연도인 2021년(100), 2022년(200), 2023년(300)의 목표 금액을 저장합니다.

이전 단락에 설명된 시나리오 3 테이블 데이터를 보여 주는 다이어그램

Power BI 테이블 시각적 개체가 Date 테이블의 Year 열을 그룹화하고 SalesAmount 및 TargetAmount 열을 합산하여 복합 모델을 쿼리하는 경우 2023년 목표 금액이 표시되지 않습니다. 교차 원본 그룹 관계는 제한된 관계이므로 양쪽에 일치하는 값이 없는 행을 제거하는 INNER JOIN 의미 체계를 사용하기 때문입니다. 그러나 Date 테이블 필터가 평가에 적용되지 않기 때문에 올바른 목표 금액 합계(600)를 생성합니다.

2023 목표 금액을 표시하지 않는 테이블 시각적 개체를 보여 주는 다이어그램. 또한 총 목표 금액 600은 2021년과 2022년에 표시된 두 값(100과 200)과 같지 않음

Date 테이블과 Target 테이블 간의 관계가 내부 원본 그룹 관계인 경우(Target 테이블이 원본 그룹 B에 속한다고 가정), 시각적 개체에는 2023년(및 기타 일치하지 않는 연도) 목표 금액을 표시하는 (공백) 연도가 포함됩니다.

Important

잘못된 보고를 방지하려면 차원 및 팩트 테이블이 서로 다른 원본 그룹에 있을 때 관계 열에 일치하는 값이 있는지 확인합니다.

제한된 관계에 대한 자세한 내용은 관계 평가를 참조하세요.

새 명명된 집합

복합 모델에 계산 열 및 계산 그룹을 추가할 때 특정 제한 사항을 고려해야 합니다.

계산 열

Microsoft SQL Server와 같은 관계형 데이터베이스에서 해당 데이터를 가져오는 DirectQuery 테이블에 추가된 계산 열은 한 번에 하나의 행에서 작동하는 식으로 제한됩니다. 이러한 식은 SUMX와 같은 DAX 반복기 함수 또는 CALCULATE와 같은 필터 컨텍스트 수정 함수를 사용할 수 없습니다.

참고 항목

연결된 테이블 형식 모델을 사용하는 계산된 열 또는 계산된 테이블을 추가할 수 없습니다.

원격 DirectQuery 테이블의 계산된 열 식은 행 내 평가로만 제한됩니다. 그러나 이러한 식을 작성할 수 있지만 시각적 개체에서 사용하면 오류가 발생합니다. 예를 들어 [Product Sales] / SUM (DimProduct[ProductSales]) 식을 사용하여 DimProduct라는 원격 DirectQuery 테이블에 계산 열을 추가하면 모델에 식을 성공적으로 저장할 수 있습니다. 그러나 시각적 개체에서 사용되는 경우 행 내 평가 제한을 위반하기 때문에 오류가 발생합니다.

반대로, 테이블 형식 모델(Power BI 의미 체계 모델 또는 Analysis Services 모델)인 원격 DirectQuery 테이블에 추가된 계산 열은 더 유연합니다. 이 경우 식이 원본 테이블 형식 모델 내에서 평가되기 때문에 모든 DAX 함수가 허용됩니다.

많은 식에서 계산 열을 그룹이나 필터로 사용하거나 집계하기 전에 Power BI에서 계산 열을 구체화해야 합니다. 계산 열이 큰 테이블에서 구체화되는 경우 계산 열이 사용하는 열의 카디널리티에 따라 CPU 및 메모리 측면에서 비용이 많이 들 수 있습니다. 이 경우 해당 계산 열을 원본 모델에 추가하는 것이 좋습니다.

참고 항목

복합 모델에 계산 열을 추가하는 경우 모든 모델 계산을 테스트해야 합니다. 업스트림 계산은 필터 컨텍스트에 미치는 영향을 고려하지 않았기 때문에 올바르게 작동하지 않을 수 있습니다.

계산 그룹

Power BI 의미 체계 모델 또는 Analysis Services 모델에 연결하는 원본 그룹에 계산 그룹이 있는 경우 Power BI가 예기치 않은 결과를 반환할 수 있습니다. 자세한 내용은 계산 그룹, 쿼리 및 측정값 평가를 참조하세요.

모델 디자인

항상 별모양 스키마 디자인을 채택하여 Power BI 모델을 최적화해야 합니다.

팁

자세한 내용은 별모양 스키마 및 Power BI에서의 중요도 이해를 참조하세요.

Power BI가 조인을 올바르게 해석하고 효율적인 쿼리 계획을 생성할 수 있도록 팩트 테이블과 별개의 차원 테이블을 만들어야 합니다. 이 지침은 모든 Power BI 모델에 해당되지만 사용자가 복합 모델의 원본 그룹이 될 것으로 인식하는 모델에 특히 해당됩니다. 이를 통해 다운스트림 모델의 다른 테이블을 더 간단하고 효율적으로 통합할 수 있습니다.

가능하면 다른 원본 그룹의 팩트 테이블과 관련된 하나의 원본 그룹에 차원 테이블을 두지 마세요. 이는 특히 카디널리티가 높은 관계 열의 경우 교차 원본 그룹 관계보다 내부 원본 그룹 관계를 갖는 것이 더 낫기 때문입니다. 앞에서 설명한 것처럼 교차 원본 그룹 관계는 관계 열에 일치하는 값이 있어야 합니다. 그렇지 않으면 보고서 시각적 개체에 예기치 않은 결과가 표시될 수 있습니다.

행 수준 보안

모델에 사용자 정의 집계, 가져오기 테이블의 계산된 열 또는 계산된 테이블이 포함된 경우 RLS(행 수준 보안)가 올바르게 설정되고 테스트되었는지 확인합니다.

복합 모델이 다른 테이블 형식 모델에 연결되는 경우 RLS 규칙은 정의된 원본 그룹(로컬 모델)에만 적용됩니다. 다른 원본 그룹(원격 모델)에는 적용되지 않습니다. 또한 다른 원본 그룹의 테이블에 RLS 규칙을 정의하거나 다른 원본 그룹과 관계가 있는 로컬 테이블에 RLS 규칙을 정의할 수 없습니다.

보고서 디자인

경우에 따라 최적화된 보고서 레이아웃을 디자인하여 복합 모델의 성능을 향상시킬 수 있습니다.

단일 원본 그룹 시각적 개체

가능하면 단일 원본 그룹의 필드를 사용하는 시각적 개체를 만듭니다. 시각적 개체에서 생성된 쿼리는 단일 원본 그룹에서 결과를 검색할 때 성능이 향상되기 때문입니다. 서로 다른 두 원본 그룹에서 데이터를 검색하는 두 개의 시각적 개체를 나란히 배치하는 것이 좋습니다.

동기화 슬라이서 사용

경우에 따라 동기화 슬라이서를 설정하여 모델에서 원본 그룹 간 관계가 생성되지 않도록 할 수 있습니다. 더 나은 성능을 발휘할 수 있는 원본 그룹을 시각적으로 결합할 수 있습니다.

모델에 두 개의 원본 그룹이 있는 경우의 시나리오를 생각해보세요. 각 원본 그룹에는 재판매인 및 인터넷 판매를 필터링하는 데 사용되는 제품 차원 테이블이 있습니다.

이 시나리오에서 원본 그룹 A에는 ResellerSales 테이블과 관련된 Product 테이블이 포함되어 있습니다. 원본 그룹 B에는 InternetSales 테이블과 관련된 Product2 테이블이 포함되어 있습니다. 교차 원본 그룹 관계는 없습니다.

이전 단락에 설명된 모델 디자인을 보여 주는 다이어그램

보고서에서 Product 테이블의 Color 열을 사용하여 페이지를 필터링하는 슬라이서를 추가합니다. 기본적으로 슬라이서는 ResellerSales 테이블을 필터링하지만 InternetSales 테이블은 필터링하지 않습니다. 그런 다음, Product2 테이블의 Color 열을 사용하여 숨겨진 슬라이서를 추가합니다. 동일한 그룹 이름을 설정하면(동기화 슬라이서 고급 옵션에 있음) 보이는 슬라이서에 적용된 필터가 자동으로 숨겨진 슬라이서로 전파됩니다.

참고 항목

동기화 슬라이서를 사용하면 교차 원본 그룹 관계를 생성할 필요가 없지만 모델 디자인의 복잡성이 증가합니다. 중복 차원 테이블을 사용하여 모델을 디자인한 이유를 다른 사용자에게 교육해야 합니다. 다른 사용자가 사용하는 것을 원하지 않는 차원 테이블은 숨겨서 혼동을 방지하세요. 숨겨진 테이블에 설명 텍스트를 추가하여 용도를 문서화할 수도 있습니다.

자세한 내용은 별도의 슬라이서 동기화를 참조하세요.

기타 지침

다음은 복합 모델을 디자인하고 유지 관리하는 데 도움이 되는 몇 가지 다른 지침입니다.

  • 성능 및 크기 조정: 보고서가 이전에 Power BI 의미 체계 모델 또는 Analysis Services 모델에 라이브로 연결된 경우 Power BI 서비스는 보고서 전체에서 시각적 캐시를 다시 사용할 수 있습니다. 라이브 연결을 변환하여 로컬 DirectQuery 모델을 만든 후에는 보고서가 더 이상 이러한 캐시의 이점을 누릴 수 없습니다. 따라서 성능이 저하되거나 새로 고침 오류가 발생할 수 있습니다. 또한 Power BI 서비스에 대한 워크로드가 증가하므로 용량을 확장하거나 다른 용량에 워크로드를 분산해야 할 수 있습니다. 데이터 새로 고침 및 캐싱에 대한 자세한 내용은 Power BI의 데이터 새로 고침을 참조하세요.
  • 이름 바꾸기: 복합 모델에서 사용하는 의미 체계 모델의 이름을 바꾸거나 작업 영역의 이름을 바꾸는 것은 권장되지 않습니다. 이는 복합 모델이 내부 고유 식별자가 아닌 작업 영역 및 의미 체계 모델 이름을 사용하여 Power BI 의미 체계 모델에 연결하기 때문입니다. 의미 체계 모델 또는 작업 영역의 이름을 바꾸면 복합 모델에서 사용하는 연결이 끊어질 수 있습니다.
  • 거버넌스: 단일 버전의 진실 모델이 복합 모델인 것은 권장하지 않습니다. 이는 다른 데이터 원본이나 모델에 종속되어 업데이트될 경우 복합 모델이 손상될 수 있기 때문입니다. 대신 엔터프라이즈 의미 체계 모델을 단일 버전의 진실로 게시하는 것이 좋습니다. 이 모델을 신뢰할 수 있는 기반으로 생각해보세요. 그런 다음 다른 데이터 모델러는 기본 모델을 확장하여 특수 모델을 만드는 복합 모델을 만들 수 있습니다.
  • 데이터 계보: 복합 모델 변경 내용을 게시하기 전에 데이터 계보 및 의미 체계 모델 영향 분석 기능을 사용합니다. 이러한 기능은 Power BI 서비스에서 사용할 수 있으며 의미 체계 모델이 관련되고 사용되는 방식을 이해하는 데 도움이 될 수 있습니다. 계보 보기에 표시되지만 실제로는 다른 작업 영역에 있는 외부 의미 체계 모델에 대해서는 영향 분석을 수행할 수 없다는 점을 이해하는 것이 중요합니다. 외부 의미 체계 모델에 대해 영향 분석을 수행하려면 원본 작업 영역으로 이동해야 합니다.
  • 스키마 업데이트: 업스트림 데이터 원본에 대한 스키마 변경이 수행되면 Power BI Desktop 복합 모델을 새로 고쳐야 합니다. 그런 다음, 모델을 Power BI 서비스를 다시 게시해야 합니다. 계산 및 종속 보고서를 철저히 테스트해야 합니다.

관련 콘텐츠

이 문서와 관련된 보다 자세한 내용을 알아보려면 다음 리소스를 참조하세요.