Power BI Desktop의 복합 모델 사용

  • 아티클

이전에는 Power BI Desktop에서 DirectQuery를 보고서에 사용할 때 해당 보고서에 대해 DirectQuery 또는 가져오기 등 다른 데이터 연결이 허용되지 않았습니다. 복합 모델을 사용하면 해당 제한이 제거됩니다. 둘 이상의 DirectQuery 또는 가져오기 데이터 연결의 데이터 연결을 보고서에 원하는 조합으로 원활하게 포함할 수 있습니다.

Power BI Desktop의 복합 모델 기능은 다음 세 가지 관련 기능으로 구성됩니다.

  • 복합 모델: 보고서에 서로 다른 원본 그룹의 데이터 연결이 두 개 이상 있을 수 있습니다. 이러한 원본 그룹은 하나 이상의 DirectQuery 연결 및 가져오기 연결, 둘 이상의 DirectQuery 연결 또는 이들의 조합일 수 있습니다. 이 문서에서는 복합 모델에 대해 자세히 설명합니다.

  • 다 대 다 관계: ‘복합 모델’을 사용하면 테이블 간에 다 대 다 관계를 설정할 수 있습니다. 이 방법은 테이블의 고유한 값에 대한 요구 사항을 제거합니다. 또한 관계 설정 목적으로만 새 테이블을 도입하는 것과 같은 이전 해결 방법도 제거됩니다. 자세한 내용은 Power BI Desktop의 다 대 다 관계 적용을 참조하세요.

  • 스토리지 모드: 이제 백 엔드 데이터 원본을 쿼리하는 시각적 개체를 지정할 수 있습니다. 이 기능은 성능을 개선하고 백 엔드 로드를 줄이는 데 도움이 됩니다. 이전에는 슬라이서와 같은 간단한 시각적 개체도 백 엔드 원본에 대한 쿼리를 시작했습니다. 자세한 내용은 Power BI Desktop의 스토리지 모드 관리를 참조하세요.

복합 모델 사용

복합 모델을 사용하면 Power BI Desktop 또는 Power BI 서비스를 사용할 때 다양한 종류의 데이터 원본에 연결할 수 있습니다. 다음과 같은 몇 가지 방법으로 이러한 데이터 연결을 만들 수 있습니다.

  • 데이터를 가져오는 가장 일반적인 방법인 Power BI로 데이터를 가져옵니다.
  • DirectQuery를 사용하여 원래의 원본 리포지토리에 있는 데이터에 직접 연결합니다. DirectQuery에 대한 자세한 내용은 Power BI에서 DirectQuery 사용을 참조하세요.

DirectQuery를 사용하는 경우 복합 모델에서는 다음 중 하나 또는 둘 다를 수행하는 Power BI 모델(예: 단일 .pbix Power BI Desktop 파일)을 만들 수 있습니다.

  • 하나 이상의 DirectQuery 원본의 데이터를 결합합니다.
  • DirectQuery 원본의 데이터와 가져오기 데이터를 결합합니다.

예를 들어, 복합 모델을 사용하면 다음과 같은 유형의 데이터를 결합하는 모델을 빌드할 수 있습니다.

  • 엔터프라이즈 데이터 웨어하우스의 판매 데이터.
  • 부서별 SQL Server 데이터베이스의 판매 대상 데이터.
  • 스프레드시트에서 가져온 데이터입니다.

둘 이상의 DirectQuery 원본의 데이터를 결합하거나 DirectQuery와 가져오기 데이터를 결합하는 모델을 복합 모델이라고 합니다.

서로 다른 원본에서 테이블을 가져온 경우에도 평소와 같이 테이블 간에 관계를 만들 수 있습니다. 교차 원본인 관계는 실제 카디널리티에 관계없이 다 대 다 카디널리티로 생성됩니다. 일 대 다, 다 대 일 또는 일 대 일로 변경할 수 있습니다. 어떤 카디널리티를 설정하건 교차 원본 관계의 동작은 각기 다릅니다. DAX(Data Analysis Expressions) 함수를 사용하여 many 쪽에서 one 쪽의 값을 검색할 수 없습니다. 동일한 원본 내의 다대다 관계와 성능 영향을 비교해서 확인할 수도 있습니다.

참고 항목

복합 모델의 컨텍스트 내에서 모든 가져온 테이블은 실제 기본 데이터 원본과 관계없이 실질적으로 단일 원본입니다.

복합 모델의 예

복합 모델의 예로는 DirectQuery를 사용하여 SQL Server의 회사 데이터 웨어하우스에 연결된 보고서를 고려해 보세요. 이 경우 데이터 웨어하우스에는 다음 이미지와 같이 국가, 분기 및 Bike(제품) 별 영업 데이터가 포함됩니다

Screenshot of an example with composite models in Relationship view.

이 시점에서 이 원본의 필드를 사용하여 단순한 시각적 개체를 빌드할 수 있습니다. 다음 이미지는 선택한 분기에 대한 ProductName별 총 매출을 보여줍니다.

Screenshot of a visual based on data from the previous example.

그러나 각 제품에 할당된 제품 관리자에 대한 데이터가 마케팅 우선 순위와 함께 Excel 스프레드시트에 있는 경우에는 어떻게 될까요? 제품 관리자에서 판매액을 보려는 경우 이 로컬 데이터를 회사 데이터 웨어하우스에 추가하지 못할 수 있습니다. 아니면 잘해야 몇 달이 걸릴 수도 있습니다.

DirectQuery를 사용하는 대신 데이터 웨어하우스에서 해당 판매 데이터를 가져올 수 있습니다. 그런 다음, 판매 데이터를 스프레드시트에서 가져온 데이터와 결합할 수 있습니다. 그러나 해당 방법은 처음부터 DirectQuery를 사용하도록 한 이유 때문에 불합리적입니다. 이유는 다음과 같습니다.

  • 보안 규칙의 일부 조합이 기본 원본에 적용됩니다.
  • 최신 데이터를 볼 수 있어야 합니다.
  • 데이터의 순수한 규모입니다.

여기에 복합 모델이 도입되었습니다. 복합 모델에서는 DirectQuery를 사용하여 데이터 웨어하우스에 연결한 다음, 추가 원본에 데이터 가져오기를 사용할 수 있습니다. 이 예제에서는 먼저 회사 데이터 웨어하우스에 대한 DirectQuery 연결을 설정합니다. 데이터 가져오기를 사용하여 Excel을 선택한 다음, 로컬 데이터가 포함된 스프레드시트로 이동합니다. 마지막으로 제품명, 할당된 판매 관리자 및 우선 순위가 포함된 스프레드시트를 가져옵니다.

Screenshot of the navigator window after selecting an excel file as a source.

필드 목록에는 SQL Server의 원래 Bike 테이블과 새 ProductManagers 테이블이라는 두 개의 테이블이 표시됩니다. 새 테이블에는 Excel에서 가져온 데이터가 포함됩니다.

Screenshot of the Fields pane with the Bike and ProductManagers fields selected.

마찬가지로 Power BI Desktop의 관계 보기에 이제 ProductManagers라는 다른 테이블이 표시됩니다.

Screenshot of the tables in Relationship view.

이제 이 테이블을 모델의 다른 테이블과 연결해야 합니다. 항상 그렇듯이 SQL Server에서 Bike 테이블과 가져온 ProductManagers 테이블 간의 관계를 만듭니다. 즉, Bike[ProductName]와 ProductManagers[ProductName] 간의 관계입니다. 앞에서 설명한 것처럼 원본 간의 모든 관계는 기본적으로 다 대 다 카디널리티로 설정됩니다.

Screenshot of the Create relationship window.

이제 이 관계를 설정했으므로 예상대로 Power BI Desktop의 관계 보기에 표시됩니다.

Screenshot of the Create relationship window after new relationships are created.

이제 필드 목록의 필드 중 하나를 사용하여 시각적 개체를 만들 수 있습니다. 이 방법은 여러 원본의 데이터를 원활하게 혼합합니다. 예를 들어, 각 제품 관리자의 총 SalesAmount가 다음 이미지에 표시됩니다.

Screenshot of the Fields pane with SalesAmount highlighted and the visual shown.

다음 예제는 제품 또는 고객과 같이 다른 곳에서 가져온 일부 추가 데이터로 확장되는 차원 테이블의 일반적인 경우를 표시합니다. 테이블에 DirectQuery를 사용하여 다양한 원본에 연결할 수도 있습니다. 예제를 계속 진행하기 위해 Country 및 Period별 Sales Targets가 별도의 부서별 데이터베이스에 저장된다고 가정합니다. 일반적으로 다음 이미지와 같이 데이터 가져오기를 사용하여 해당 데이터에 연결할 수 있습니다.

Screenshot of the Navigator window with sales targets selected.

이전에 수행한 작업처럼 새 테이블과 모델의 다른 테이블 간에 관계를 만듭니다. 그런 다음 테이블 데이터를 결합하는 시각적 개체를 만들 수 있습니다. 새로운 관계를 설정한 관계 보기를 다시 살펴보겠습니다.

Screenshot of the Relationship view with many tables.

다음 이미지는 새 데이터 및 생성된 관계를 기반으로 합니다. 왼쪽 아래의 시각적 개체에서는 판매액 대 대상이 표시되고 편차 계산에서는 차이가 표시됩니다. 판매액 및 대상 데이터는 서로 다른 두 SQL Server 데이터베이스에서 가져옵니다.

Screenshot of the Report view with more data.

스토리지 모드 설정

복합 모델의 각 테이블에는 테이블이 DirectQuery를 기반으로 하는지 가져오기를 기반으로 하는지 나타내는 스토리지 모드가 있습니다. 스토리지 모드는 속성 창에서 보고 수정할 수 있습니다. 스토리지 모드를 표시하려면 필드 목록에서 테이블을 마우스 오른쪽 단추로 클릭한 다음, 속성을 선택합니다. 다음 이미지는 SalesTargets 테이블의 스토리지 모드를 보여줍니다.

각 테이블의 도구 설명에서도 스토리지 모드를 볼 수 있습니다.

Screenshot of a tooltip displaying the storage mode.

DirectQuery의 일부 테이블과 일부 가져오기 테이블을 포함하는 Power BI Desktop 파일(.pbix 파일)의 경우 상태 표시줄에 혼합이라는 스토리지 모드가 표시됩니다. 상태 표시줄에서 해당 용어를 선택하여 모든 테이블을 가져오기로 쉽게 전환할 수 있습니다.

스토리지 모드에 대한 자세한 내용은 Power BI Desktop의 스토리지 모드 관리를 참조하세요.

참고 항목

Power BI Desktop 및 Power BI 서비스에서 혼합 스토리지 모드를 사용할 수 있습니다.

계산된 테이블

DirectQuery를 사용하는 Power BI Desktop의 모델에 계산 테이블을 추가할 수 있습니다. 계산된 테이블을 정의하는 DAX(데이터 분석 식)는 가져온 테이블이나 DirectQuery 테이블 또는 둘의 조합을 참조할 수 있습니다.

계산된 테이블은 항상 가져오며 테이블을 새로 고칠 때 해당 데이터가 새로 고쳐집니다. 계산된 테이블이 DirectQuery 테이블을 참조하는 경우 DirectQuery 테이블을 참조하는 시각적 개체는 항상 기본 원본의 최신 값을 표시합니다. 또는 계산된 테이블을 참조하는 시각적 개체는 계산된 테이블을 마지막으로 새로 고친 시점의 값을 보여줍니다.

Important

계산된 테이블은 이 기능을 사용하여 Power BI 서비스 지원되지 않습니다. 자세한 내용은 이 문서의 의미 체계 모델 섹션을 기반으로 복합 모델 작업 섹션을 참조하세요.

보안 의미

복합 모델에는 일부 보안 의미가 있습니다. 한 데이터 원본에 전송된 쿼리는 다른 원본에서 검색된 데이터 값을 포함할 수 있습니다. 이전 예제에서 제품 관리자별 (판매액)을 보여주는 시각적 개체는 SQL 쿼리를 판매 관계형 데이터베이스로 보냅니다. 해당 SQL 쿼리에는 제품 관리자 및 관련 제품의 이름이 포함될 수 있습니다.

Screenshot of a script showing security implications.

스프레드시트에 저장된 정보가 이제 관계형 데이터베이스로 전송되는 쿼리에 포함됩니다. 이 정보가 기밀인 경우에는 보안 의미를 고려해야 합니다. 특히 다음 사항을 고려하세요.

  • 추적 또는 감사 로그를 볼 수 있는 데이터베이스의 관리자는 원래 원본에 있는 데이터에 대한 사용 권한 없이도 이 정보를 볼 수 있습니다. 이 예제에서는 관리자가 Excel 파일에 대한 사용 권한이 필요합니다.

  • 각 원본에 대한 암호화 설정을 고려해야 합니다. 암호화된 연결을 통해 한 원본에서 정보를 검색한 다음, 암호화되지 않은 연결을 통해 다른 원본으로 전송되는 쿼리에 실수로 이 정보가 포함되는 것을 방지하려고 합니다.

보안에 미치는 영향을 고려했는지 확인할 수 있도록 복합 모델을 만들 때 Power BI Desktop에 경고 메시지가 표시됩니다.

또한, 작성자가 Model A의 Table1을 복합 모델에 추가하는 경우(이를 Model C라고 하겠습니다), Model C를 기반으로 작성된 보고서를 보는 사용자는 Model A에서 행 수준 보안 RLS로 보호되지 않는 모든 테이블을 쿼리할 수 있습니다.

비슷한 이유로 신뢰할 수 없는 원본에서 전송된 Power BI Desktop 파일을 열 때 주의하세요. 파일에 복합 모델이 포함되는 경우 파일을 여는 사용자의 자격 증명을 사용하여 한 원본에서 검색하는 정보는 쿼리의 일부로 다른 데이터 원본으로 보내집니다. 이 정보는 Power BI Desktop 파일의 악의적인 작성자가 볼 수 있습니다. 여러 원본이 포함된 Power BI Desktop 파일을 처음 열면 Power BI Desktop에 경고가 표시됩니다. 이 경고는 네이티브 SQL 쿼리가 포함된 파일을 열 때 표시되는 경고와 비슷합니다.

성능 의미

DirectQuery를 사용할 때는 주로 사용자에게 좋은 환경을 제공할 충분한 리소스가 백 엔드 원본에 있는지 확인하기 위해 항상 성능을 고려해야 합니다. 좋은 환경이란 시각적 개체가 5초 이내로 새로 고쳐진다는 것을 의미합니다. 성능에 대한 추가 조언은 Power BI의 DirectQuery를 참조하세요.

복합 모델을 사용하면 기타 성능 고려 사항이 추가됩니다. 단일 시각적 개체는 여러 원본에 쿼리를 보낼 수 있으며, 이는 한 쿼리에서 두 번째 원본으로 결과를 전달하는 경우가 많습니다. 이 상황에서는 다음과 같은 실행 형식이 발생할 수 있습니다.

  • 많은 리터럴 값을 포함하는 원본 쿼리: 예를 들어, 선택한 제품 관리자 집합의 총 판매액을 요청하는 시각적 개체는 먼저 해당 제품 관리자가 관리하는 제품을 찾아야 합니다. 이 시퀀스는 WHERE 절에 모든 제품 ID가 포함된 SQL 쿼리를 시각적 개체가 보내기 전에 수행해야 합니다.

  • 데이터가 나중에 로컬로 집계된 후 하위 수준의 세분성으로 쿼리하는 원본 쿼리: 제품 관리자의 필터 기준을 충족하는 제품의 수가 증가함에 따라 모든 제품을 WHERE 절에 포함하는 것은 비효율적이거나 불가능해질 수 있습니다. 대신 제품의 하위 수준에서 관계형 원본을 쿼리한 다음, 로컬로 결과를 집계할 수 있습니다. 제품의 카디널리티가 1백만 개 제한을 초과하면 쿼리가 실패합니다.

  • 여러 원본 쿼리, 값별로 그룹당 하나: 집계에서 DistinctCount를 사용하고 다른 원본의 열로 그룹화할 때 외부 원본이 그룹을 정의하는 많은 리터럴 값의 효율적인 전달을 지원하지 않는 경우 값별로 그룹당 하나의 SQL 쿼리를 보내야 합니다.

    스프레드시트에서 가져온 제품 관리자별 SQL Server 테이블에서 CustomerAccountNumber의 고유 개수를 요청하는 시각적 개체는 SQL Server로 전송되는 쿼리에서 Product Managers 테이블의 세부 정보를 전달해야 합니다. 예를 들어 Redshift 같은 다른 원본에서는 이 작업을 수행할 수 없습니다. 대신 쿼리가 실패하는 실제적인 제한까지 판매 관리자당 하나의 SQL 쿼리가 전송됩니다.

이러한 각각의 사례에는 성능에 대한 고유한 의미가 있으며 정확한 세부 정보는 각 데이터 원본에 따라 달라집니다. 두 원본을 조인하는 관계에 사용되는 열의 카디널리티가 수천 개로 낮게 유지되지만 성능에 영향을 미치지 않아야 합니다. 이 카디널리티가 증가함에 따라 결과 성능에 미치는 영향에 더 많은 주의를 기울여야 합니다.

또한 다 대 다 관계의 사용은 세부 값을 로컬로 집계하는 대신 각 합계 또는 소계 수준에 대한 기본 원본에 개별 쿼리를 보내야 함을 의미합니다. 합계가 있는 간단한 테이블 시각적 개체는 하나가 아닌 두 개의 원본 쿼리를 보냅니다.

원본 그룹

원본 그룹은 DirectQuery 원본 또는 데이터 모델에 관련된 모든 가져오기 원본의 항목(예: 테이블, 관계)의 컬렉션입니다. 복합 모델은 하나 이상의 원본 그룹으로 구성됩니다. 다음 예를 살펴 보십시오.

  • Sales라는 Power BI 의미 체계 모델에 연결하고 원래 의미 체계 모델에서 사용할 수 없는 Sales YTD 측정값을 추가하여 의미 체계 모델을 보강하는 복합 모델입니다. 이 모델은 하나의 원본 그룹으로 구성됩니다.
  • Targets라는 Excel 시트와 Regions라는 CSV 파일에서 테이블을 가져오고 Sales라는 Power BI 의미 체계 모델에 DirectQuery 연결을 만들어 데이터를 결합하는 복합 모델입니다. 이 경우 다음 이미지와 같이 두 개의 원본 그룹이 있습니다.
    • 첫 번째 원본 그룹에는 Targets Excel 시트의 테이블과 지역 CSV 파일이 포함됩니다.
    • 두 번째 원본 그룹에는 Sales Power BI 의미 체계 모델의 항목이 포함됩니다.

Diagram showing the Import and Sales source groups containing the tables from the respective sources.

Inventory라는 SQL Server 데이터베이스에 대한 DirectQuery 연결처럼 다른 DirectQuery 연결을 다른 원본에 추가한 경우 해당 원본의 항목이 다른 원본 그룹으로 추가됩니다.

Diagram showing the Import, Sales and Inventory source groups containing the tables from the respective sources.

참고 항목

가져온 모든 원본의 모든 항목은 하나의 원본 그룹에 있으므로 다른 원본에서 데이터를 가져와도 다른 원본 그룹이 추가되지 않습니다.

원본 그룹 및 관계

복합 모델에는 두 가지 유형의 관계가 있습니다.

  • 원본 그룹 내 관계. 이러한 관계는 원본 그룹 내에서 항목을 연결합니다. 이러한 관계는 관계가 제한되는 다대다 관계가 아닌 한, 항상 정규 관계입니다.
  • 원본 그룹 간 관계 이러한 관계는 하나의 원본 그룹에서 시작하여 다른 원본 그룹에서 끝납니다. 이러한 관계는 항상 제한된 관계입니다.

일반 관계와 제한된 관계 간의 차이점과 그 영향에 대해 자세히 알아보세요.

예를 들어 다음 이미지에는 다양한 원본 그룹의 테이블을 함께 연결하는 세 가지 원본 그룹 간 관계가 있습니다.

Diagram showing the Import, Sales and Inventory source groups containing the tables from the respective sources and relationships between the source groups as described previously.

로컬 및 원격

DirectQuery 원본 그룹인 원본 그룹에 있는 모든 항목은 원격으로 간주됩니다. 단, 항목이 DirectQuery 원본에 대한 확장 또는 보강의 일부로 로컬로 정의되고 측정값 또는 계산 테이블과 같은 원격 원본의 일부가 아닌 경우는 원격으로 간주되지 않습니다. DirectQuery 원본 그룹의 테이블을 기반으로 하는 계산 테이블은 "가져오기" 원본 그룹에 속하며 로컬로 간주됩니다. "가져오기" 원본 그룹에 있는 모든 항목은 로컬로 간주됩니다. 예를 들어 Inventory 원본에 대한 DirectQuery 연결을 사용하는 복합 모델에서 다음 측정값을 정의하는 경우 측정값은 로컬로 간주됩니다.

[Average Inventory Count] = Average(Inventory[Inventory Count])

계산 그룹, 쿼리 및 측정값 평가

계산 그룹은 공통 측정값 식을 함께 그룹화하고 중복 측정값 수를 줄이는 방법을 제공합니다. 일반적인 사용 사례는 실제 값에서 월간 누계, 분기별 누계 또는 연도별 누계로 전환할 수 있는 시간 인텔리전스 계산입니다. 복합 모델을 사용하는 경우 계산 그룹 간의 상호 작용을 인식하고 측정값이 단일 원격 원본 그룹의 항목만 참조하는지를 아는 것이 중요합니다. 측정값이 단일 원격 원본 그룹의 항목만 참조하고 해당 원격 모델에서 측정값에 영향을 주는 계산 그룹을 정의하는 경우, 측정값이 정의된 것이 원격 모델인지 로컬 모델인지에 관계없이 해당 계산 그룹이 적용됩니다. 그러나 측정값이 단일 원격 원본 그룹의 항목만을 단독으로 참조하지 않고 원격 계산 그룹이 적용되는 원격 원본 그룹의 항목을 참조하는 경우 측정값의 결과는 원격 계산 그룹의 영향도 받을 수 있습니다. 다음 예제를 참조하세요.

  • Reseller Sales는 원격 모델에서 정의된 측정값입니다.
  • 원격 모델에는 Reseller Sales 결과를 변경하는 계산 그룹이 포함되어 있습니다.
  • Internet Sales는 로컬 모델에서 정의된 측정값입니다.
  • Total Sales는 로컬 모델에서 정의된 측정값이며 정의는 다음과 같습니다.
[Total Sales] = [Internet Sales] + [Reseller Sales]

이 시나리오에서 Internet Sales 측정값은 동일한 모델에 속하지 않으므로 원격 모델에 정의된 계산 그룹의 영향을 받지 않습니다. 그러나 계산 그룹은 동일한 모델에 있는 Reseller Sales 측정값의 결과를 변경할 수 있습니다. 즉, Total Sales 측정값에서 반환된 결과를 신중하게 평가해야 한다는 의미입니다. 원격 모델의 계산 그룹을 사용하여 연도별 누계를 반환하는 경우를 생각해보겠습니다. Reseller Sales에서 반환한 결과는 연도별 누계 값이지만 Internet Sales에서 반환된 결과는 여전히 실제 값입니다. 실제 값을 연도별 누계에 더하기 때문에 Total Sales의 결과는 예상치 못한 결과일 가능성이 큽니다.

Power BI 의미 체계 모델 및 Analysis Services의 복합 모델

Power BI 의미 체계 모델 및 Analysis Services와 복합 모델을 사용하면 DirectQuery 연결을 사용하여 Power BI 의미 체계 모델, Azure Analysis Services(AAS) 및 SQL Server 2022 Analysis Services 연결하는 복합 모델을 빌드할 수 있습니다. 복합 모델을 사용하여 이러한 원본의 데이터를 다른 DirectQuery 및 가져온 데이터와 결합할 수 있습니다. 엔터프라이즈 의미 체계 모델의 데이터를 Excel 스프레드시트와 같은 소유하고 있는 다른 데이터와 결합하거나 엔터프라이즈 의미 체계 모델의 메타데이터를 개인 설정 또는 보강하려는 보고서 작성자에게는 이 기능이 특히 유용합니다.

Power BI 의미 체계 모델에서 복합 모델 관리

Power BI 의미 체계 모델에서 복합 모델을 만들고 사용할 수 있도록 하려면 테넌트에서 다음 스위치를 사용하도록 설정해야 합니다.

또한 프리미엄 용량 및 사용자 단위 Premium의 경우 "XMLA 엔드포인트" 설정을 사용하도록 설정하고 "읽기 전용" 또는 "읽기/쓰기"로 설정해야 합니다.

테넌트 관리자는 관리 포털에서 Power BI 의미 체계 모델에 대한 DirectQuery 연결을 사용하거나 사용하지 않도록 설정할 수 있습니다. 기본적으로 사용하도록 설정되지만, 사용하지 않도록 설정하면 사용자가 Power BI 의미 체계 모델의 새 복합 모델을 서비스에 게시하지 못하게 효과적으로 차단됩니다.

Admin setting to enable or disable DirectQuery connections to Power BI semantic models.

Power BI 의미 체계 모델에서 복합 모델을 활용하는 기존 보고서는 계속 작동하며 사용자는 여전히 Desktop을 사용하여 복합 모델을 만들 수 있지만 서비스에 게시할 수는 없습니다. 대신 이 모델 변경을 선택하여 Power BI 의미 체계 모델에 대한 DirectQuery 연결을 만들 때 다음과 같은 경고 메시지가 표시됩니다.

Screenshot showing Warning message informing the user that publication of a composite model that uses a Power BI semantic model is not allowed, because DirectQuery connections are not allowed by the admin. The user can still create the model using Desktop.

이렇게 하면 로컬 Power BI Desktop 환경에서 의미 체계 모델을 탐색하고 복합 모델을 만들 수 있습니다. 그러나 서비스에 보고서를 게시할 수는 없습니다. 보고서 및 모델을 게시하면 다음과 같은 오류 메시지가 표시되고 게시가 차단됩니다.

Screenshot showing Error message that blocks publication of a composite model that uses a Power BI semantic model because DirectQuery connections are not allowed by the admin.

Power BI 의미 체계 모델에 대한 라이브 연결은 이 스위치의 영향을 받지 않으며, Analysis Services에 대한 라이브 또는 DirectQuery 연결도 영향을 받지 않습니다. 스위치가 꺼져 있는지 여부에 관계없이 계속 작동합니다. 또한 Power BI 의미 체계 모델에서 복합 모델을 활용하는 게시된 보고서는 게시 후 스위치가 꺼진 경우에도 계속 작동합니다.

의미 체계 모델 또는 모델에서 복합 모델 빌드

Power BI 의미 체계 모델 또는 Analysis Services 모델에서 복합 모델을 빌드하려면 보고서에 로컬 모델이 있어야 합니다. 라이브 연결에서 시작하여 로컬 모델에 추가하거나 로컬 모델로 업그레이드하거나 DirectQuery 연결 또는 가져온 데이터로 시작하여 보고서에 로컬 모델을 자동으로 만들 수 있습니다.

모델에 사용되는 연결을 보려면 Power BI Desktop의 오른쪽 아래에 있는 상태 표시줄을 확인합니다. Analysis Services 원본에만 연결된 경우 다음 이미지와 같은 메시지가 표시됩니다.

Screenshot showing Analysis Services only connection.

Power BI 의미 체계 모델에 연결된 경우 연결된 Power BI 의미 체계 모델을 알려주는 메시지가 표시됩니다.

Screenshot showing Power BI semantic model connection.

라이브 연결 의미 체계 모델에 있는 필드의 메타데이터를 사용자 지정하려면 상태 표시줄에서 이 모델 변경을 선택합니다. 또는 다음 이미지와 같이 리본에서 이 모델 변경 단추를 선택할 수 있습니다. 보고서 뷰에서는 이 모델 변경 단추가 모델링 탭에 있습니다. 모델 뷰에서는 이 단추가 홈 탭에 있습니다.

Screenshot showing Make changes to this model button.

단추를 선택하면 로컬 모델 추가를 확인하는 대화 상자가 표시됩니다. 새 열을 만들거나 Power BI 의미 체계 모델 또는 Analysis Services 필드의 메타데이터를 수정하려면 로컬 모델 추가를 선택합니다. 다음 이미지는 표시되는 대화 상자를 보여 줍니다.

Screenshot showing Create local model dialog.

Analysis Services 원본에 라이브 연결된 경우 로컬 모델이 없습니다. Power BI 의미 체계 모델 및 Analysis Services와 같은 라이브 연결 원본에 DirectQuery를 사용하려면 보고서에 로컬 모델을 추가해야 합니다. 로컬 모델이 포함된 보고서를 Power BI 서비스에 게시하면 해당 로컬 모델의 의미 체계 모델도 게시됩니다.

체인

의미 체계 모델 및 이를 기반으로 하는 의미 체계 모델이 체인을 형성합니다. 체이닝이라는 이 프로세스를 사용하면 이전에는 불가능했던 기능인 다른 Power BI 의미 체계 모델을 기반으로 보고서 및 의미 체계 모델 게시가 가능합니다.

예를 들어 동료가 Sales라는 Analysis Services 모델을 기반으로 하는 Sales and Budget이라는 Power BI 의미 체계 모델을 게시하고 Budget이라는 Excel 시트와 결합한다고 가정하겠습니다.

동료가 게시한 Sales and Budget Power BI 데이터세트를 기반으로 하는 Sales and Budget Europe이라는 새 보고서(및 의미 체계 모델)를 게시하면서 몇 가지 추가 수정이나 확장을 하는 경우, 사실상 Sales Analysis Services 모델로 시작해 Sales and Budget Europe Power BI 의미 체계 모델로 끝나는 길이 3인 체인에 보고서와 의미 체계 모델을 추가하는 것입니다. 다음 이미지는 이 체이닝 프로세스를 시각화합니다.

Screenshot showing The process of chaining semantic models.

이전 이미지의 체인 길이는 3이며, 최대 길이입니다. 체인 길이를 4 이상으로 확장하는 것은 지원되지 않으며 오류가 발생합니다.

사용 권한 및 라이선스

복합 모델을 사용하여 보고서에 액세스하는 사용자는 체인의 모든 의미 체계 모델 및 모델에 대한 적절한 권한이 있어야 합니다.

복합 모델의 소유자는 다른 사용자가 소유자를 대신하여 해당 모델에 액세스할 수 있도록 원본으로 사용되는 의미 체계 모델에 대한 빌드 권한이 필요합니다. 따라서 Power BI Desktop에서 복합 모델 연결을 만들거나 Power BI에서 보고서를 작성하려면 원본으로 사용되는 의미 체계 모델에 대한 빌드 권한이 필요합니다.

복합 모델을 사용하여 보고서를 보는 사용자는 일반적으로 복합 모델 자체 및 원본으로 사용되는 의미 체계 모델에 대한 읽기 권한이 필요합니다. 보고서가 Pro 작업 영역에 있는 경우 빌드 권한이 필요할 수 있습니다. 이러한 테넌트 스위치는 사용자에 대해 사용하도록 설정해야 합니다.

필요한 권한은 다음 예제와 함께 설명될 수 있습니다.

  • 복합 모델 A(소유자 A 소유)

    • 데이터 원본 A1: 의미 체계 모델 B.
      사용자가 복합 모델 A를 사용하여 보고서를 볼 수 있도록 소유자 A는 의미 체계 모델 B에 대한 빌드 권한이 있어야 합니다.

  • 복합 모델 C(소유자 C 소유)

    • 데이터 원본 C1: 의미 체계 모델 D
      사용자가 복합 모델 C를 사용하여 보고서를 볼 수 있도록 소유자 C는 의미 체계 모델 D에 대한 빌드 권한이 있어야 합니다.
    • 데이터 원본 C2: 복합 모델 A
      소유자 C는 복합 모델 A에 대한 빌드 권한과 의미 체계 모델 B에 대한 읽기 권한이 있어야 합니다.

복합 모델 A를 사용하여 보고서를 보는 사용자는 복합 모델 A와 의미 체계 모델 B 모두에 대한 읽기 권한이 있어야 하며 복합 모델 C를 사용하는 보고서를 보는 사용자는 복합 모델 C, 의미 체계 모델 D, 복합 모델 A 및 의미 체계 모델 B에 대한 읽기 권한이 있어야 합니다.

참고 항목

Power BI 의미 체계 모델 및 Analysis Services 모델의 복합 모델에 필요한 권한에 대한 자세한 내용은 이 블로그 게시물을 참조하세요.

체인의 데이터 세트가 사용자 단위 Premium 작업 영역에 있는 경우 액세스하는 사용자에게는 사용자 단위 Premium 사용자 단위 라이선스가 필요합니다. 체인의 데이터 세트가 Pro 작업 영역에 있는 경우 액세스하는 사용자에게는 Pro 사용자 단위 라이선스가 필요합니다. 체인의 모든 데이터 세트가 프리미엄 용량 또는 Fabric F64 이상 용량에 있는 경우 사용자가 무료 라이선스를 사용하여 데이터 세트에 액세스할 수 있습니다.

보안 경고

Power BI 의미 체계 모델 및 Analysis Services용 DirectQuery를 사용하면 다음 이미지와 같은 보안 경고가 표시됩니다.

Screenshot showing Security warning.

한 데이터 원본에서 다른 데이터 원본으로 데이터를 푸시할 수 있는데, 이는 데이터 모델에 DirectQuery와 가져오기 원본을 결합하는 경우와 동일한 보안 경고입니다. 이 동작에 대한 자세한 내용은 Power BI Desktop에서 복합 모델 사용을 참조하세요.

지원되는 시나리오

Power BI 의미 체계 모델 또는 Analysis Services 모델의 데이터를 사용하여 복합 모델을 빌드하여 다음 시나리오를 처리할 수 있습니다.

  • 다양한 원본에서 데이터에 연결: 가져오기(예: 파일), Power BI 의미 체계 모델, Analysis Services 모델
  • 서로 다른 데이터 원본 간 관계 만들기
  • 서로 다른 데이터 원본의 필드를 사용하는 측정값 작성
  • Power BI 의미 체계 모델 또는 Analysis Services 모델에서 테이블에 대한 새 열 만들기
  • 서로 다른 데이터 원본의 열을 사용하는 시각적 개체 만들기
  • 필드 목록을 사용하여 모델에서 테이블을 제거함으로써 모델을 가능한 한 간결하고 명료하게 유지할 수 있습니다(큐브 뷰에 연결하는 경우 모델에서 테이블을 제거할 수 없음).
  • 특정한 일부 테이블만 원하는 경우 모든 테이블을 로드할 필요 없이 로드할 테이블을 지정할 수 있습니다. 이 문서의 뒷부분에 있는 테이블의 하위 집합 로드를 참조하세요.
  • 모델에서 연결을 만든 후, 이후에 의미 체계 모델에 추가되는 테이블을 추가할지를 지정할 수 있습니다.

의미 체계 모델을 기반으로 하는 복합 모델 작업

Power BI 의미 체계 모델 및 Analysis Services DirectQuery를 사용하는 경우 다음 사항을 고려하세요.

  • 데이터 원본을 새로 고치고 필드 또는 테이블 이름 충돌 오류가 있는 경우 Power BI가 오류를 해결합니다.

  • 동일한 Power BI 의미 체계 모델 또는 Analysis Services 원본에서 새 관계를 편집하거나 삭제하거나 만들 수 없습니다. 이러한 원본에 대한 편집 액세스 권한이 있는 경우 데이터 원본에서 직접 변경할 수 있습니다.

  • Power BI 의미 체계 모델 또는 Analysis Services 원본에서 로드되는 열의 데이터 형식은 변경할 수 없습니다. 데이터 형식을 변경해야 하는 경우 원본에서 변경하거나 계산 열을 사용합니다.

  • 다른 의미 체계 모델을 기반으로 하는 복합 모델에서 Power BI 서비스 보고서를 작성하려면 모든 자격 증명을 설정해야 합니다.

  • SQL Server 2022 이상 Analysis Services 서버 온-프레미스 또는 IAAS에 연결하려면 온-프레미스 데이터 게이트웨이(표준 모드)가 필요합니다.

  • 원격 Power BI 의미 체계 모델 모델에 대한 모든 연결은 Single Sign-On을 사용하여 이루어집니다. 서비스 주체를 사용한 인증은 현재 지원되지 않습니다.

  • RLS 규칙은 RLS 규칙이 정의된 원본에 적용되지만 모델의 다른 의미 체계 모델에는 적용되지 않습니다. 보고서에서 정의된 RLS는 원격 원본에 적용되지 않으며, 원격 원본에서 설정된 RLS는 다른 데이터 원본에 적용되지 않습니다. 또한 원격 원본에서 로드된 테이블에 RLS를 정의할 수 없으며 로컬 테이블에 정의된 RLS는 원격 원본에서 로드된 테이블을 필터링하지 않습니다.

  • KPI, 행 수준 보안 및 번역은 원본에서 가져올 수 없습니다.

  • 날짜 계층 구조를 사용하는 경우 예기치 않은 동작이 발생할 수 있습니다. 이 문제를 해결하려면 날짜 열을 대신 사용하세요. 시각적 개체에 날짜 계층 구조를 추가한 후 필드 이름에서 아래쪽 화살표를 클릭한 다음 해당 필드의 이름을 클릭하면 날짜 계층 구조를 사용하는 대신 날짜 열로 전환할 수 있습니다.

    Screen shot of date hierarchy setting.

    날짜 열과 날짜 계층을 사용하는 방법에 대한 자세한 내용은 Power BI Desktop에서 자동 날짜 또는 시간 적용을 참조하세요.

  • 모델 체인의 최대 길이는 3입니다. 체인 길이를 4 이상으로 확장하는 것은 지원되지 않으며 오류가 발생합니다.

  • 모델에 ‘체이닝 금지’ 플래그를 설정하여 체인을 만들거나 확장할 수 없도록 할 수 있습니다. 자세한 내용은 게시된 의미 체계 모델에 대한 DirectQuery 연결 관리를 참조하세요.

  • Power BI 의미 체계 모델 또는 Analysis Services에 대한 연결은 파워 쿼리에 표시되지 않습니다.

Power BI 의미 체계 모델 및 Analysis Services DirectQuery를 사용하는 경우 다음 제한 사항이 적용됩니다.

  • 현재 데이터베이스 및 서버 이름에 대한 매개 변수를 사용할 수 없습니다.
  • 원격 원본에서 테이블에 RLS를 정의하는 것은 지원되지 않습니다.
  • 다음 원본은 DirectQuery 원본으로 사용할 수 없습니다.
    • 버전 2022 이전의 SSAS(SQL Server Analysis Services) 테이블 형식 모델
    • SSAS 다차원 모델
    • SAP HANA
    • SAP Business Warehouse
    • 실시간 의미 체계 모델
    • 샘플 의미 체계 모델
    • Excel Online 새로 고침
    • 서비스의 Excel 또는 CSV 파일에서 가져온 데이터
    • 사용량 메트릭
    • "내 작업 영역"에 저장된 의미 체계 모델
  • Analysis Services 모델에 대한 DirectQuery 연결이 포함된 의미 체계 모델에 Power BI Embedded를 사용하는 것은 현재 지원되지 않습니다.
  • 웹에 게시 기능을 사용하여 웹에 보고서를 게시하는 것은 지원되지 않습니다.
  • 원격 원본의 계산 그룹은 지원되지 않으며, 정의되지 않은 쿼리 결과가 반환됩니다.
  • 계산된 테이블은 이 기능을 사용하는 서비스에서 지원되지 않습니다. 계산된 테이블이 있는 의미 체계 모델 또는 DirectQuery 데이터 원본을 참조하는 계산 열에서 새로 고침을 수행하려고 하면 “SSO(Single Sign-On) 자격 증명이 제공되지 않음” 오류 메시지가 나타납니다.
  • DirectQuery 연결이 설정된 후 작업 영역의 이름을 바꾸는 경우 Power BI Desktop 데이터 원본을 업데이트해야만 보고서가 계속 작동합니다.
  • APR(자동 페이지 새로 고침)은 데이터 원본 유형에 따라 일부 시나리오에서만 지원됩니다. 자세한 내용은 Power BI에서 자동 페이지 새로 고침 문서를 참조하세요.
  • 다른 의미 체계 모델에 대한 DirectQuery 기능을 사용하는 의미 체계 모델 인수는 현재 지원되지 않습니다.
  • 모든 DirectQuery 데이터 원본과 마찬가지로 Analysis Services 모델 또는 Power BI 의미 체계 모델에 정의된 계층 구조는 Excel을 사용하여 DirectQuery 모드에서 모델 또는 의미 체계 모델에 연결하는 경우에 표시되지 않습니다.

Power BI 의미 체계 모델 및 Analysis Services DirectQuery로 작업할 때 고려해야 할 몇 가지 다른 사항이 있습니다.

  • 원본 그룹 간 관계에서 낮은 카디널리티 열 사용: 서로 다른 두 원본 그룹 간에 관계를 만들 때 관계에 참여하는 열(조인 열이라고도 함)은 카디널리티가 낮아야 하며, 이상적으로는 50,000개 이하여야 합니다. 이 고려 사항은 문자열이 아닌 키 열에 적용됩니다. 문자열 키 열의 경우 다음 고려 사항을 참조하세요.
  • 원본 그룹 간 관계에서 큰 문자열 키 열은 사용하지 않기: 원본 그룹 간 관계를 만들 때는 특히 카디널리티가 더 큰 열의 경우 큰 문자열 열을 관계 열로 사용하지 마세요. 문자열 열을 관계 열로 사용해야 하는 경우 카디널리티(C)를 문자열 열의 평균 길이(A)로 곱하여 필터의 예상 문자열 길이를 계산합니다. 예상 문자열 길이가 250,000 미만인지 확인합니다( A ∗ C < 250,000).

자세한 고려 사항 및 지침은 복합 모델 지침을 참조하세요.

테넌트 고려 사항

Power BI 의미 체계 모델 또는 Analysis Services에 대한 DirectQuery 연결이 있는 모델은 동일한 테넌트에 게시되어야 합니다. 이는 다음 다이어그램에 나와 있는 것처럼 B2B 게스트 ID를 사용하여 Power BI 의미 체계 모델 또는 Analysis Services 모델에 액세스할 때 특히 중요합니다. 게시를 위한 테넌트 URL을 찾는 방법은 콘텐츠를 편집 및 관리할 수 있는 게스트 사용자를 참조하세요.

다음 다이어그램을 살펴보세요. 다이어그램에서 번호가 매겨진 단계는 이후 단락에 설명되어 있습니다.

Diagram of numbered steps for tenant considerations.

다이어그램에서 Ash는 Contoso에서 근무하며 Fabrikam에서 제공하는 데이터에 액세스합니다. Ash는 Power BI Desktop을 사용하여 Fabrikam의 테넌트에 호스트된 Analysis Services 모델에 대한 DirectQuery 연결을 만듭니다.

인증을 위해 Ash는 B2B 게스트 사용자 ID를 사용합니다(다이어그램의 1단계).

보고서가 Contoso의 Power BI 서비스에 게시되는 경우(2단계), Contoso 테넌트에 게시된 의미 체계 모델은 Fabrikam의 Analysis Services 모델에 대해 성공적으로 인증할 수 없습니다(3단계). 따라서 보고서가 작동하지 않습니다.

이 시나리오에서는 사용되는 Analysis Services 모델이 Fabrikam의 테넌트에 호스트되므로 보고서를 Fabrikam의 테넌트에도 게시해야 합니다. Fabrikam 테넌트에 성공적으로 게시되면(4단계) 의미 체계 모델은 Analysis Services 모델에 성공적으로 액세스할 수 있습니다(5단계). 그러면 보고서가 제대로 작동합니다.

개체 수준 보안 작업

복합 모델에서 DirectQuery를 통해 Power BI 의미 체계 모델 또는 Analysis Services의 데이터를 가져오고, 해당 원본 모델이 개체 수준 보안으로 보호되는 경우 복합 모델의 소비자가 예기치 않은 결과를 확인할 수 있습니다. 다음 섹션에서는 이러한 결과를 얻을 수 있는 방법에 대해 설명합니다.

OLS(개체 수준 보안)를 사용하면 모델 작성자는 모델 소비자(예: 보고서 작성기 또는 복합 모델 작성자)로부터 모델 스키마(즉, 테이블, 열, 메타데이터 등)를 구성하는 개체를 숨길 수 있습니다. 개체에 대한 OLS 구성에서 모델 작성자는 역할을 만든 다음, 해당 역할에 할당된 사용자의 개체에 대한 액세스 권한을 제거합니다. 이러한 사용자의 관점에서 볼 때 숨겨진 개체는 존재하지 않습니다.

OLS는 원본 모델에 대해 정의되고 적용됩니다. 원본 모델을 기반으로 하는 복합 모델에 대해서는 정의할 수 없습니다.

DirectQuery 연결을 통해 OLS로 보호되는 Power BI 의미 체계 모델 또는 Analysis Services 모델을 기반으로 복합 모델을 빌드하면 원본 모델의 모델 스키마가 복합 모델로 복사됩니다. 복사되는 항목은 복합 모델 작성자가 허용하는 내용에 따라 원본 모델에서 해당 모델에 적용되는 OLS 규칙에 따라 표시됩니다. 데이터 자체는 복합 모델에 복사되지 않고, 필요할 때 원본 모델에서 DirectQuery를 통해 항상 검색됩니다. 즉, 데이터 검색은 항상 OLS 규칙이 적용되는 원본 모델로 돌아갑니다.

복합 모델은 OLS 규칙에 의해 보호되지 않으므로 복합 모델의 소비자가 보는 개체는 복합 모델 작성자가 자신이 액세스할 수 있는 것이 아니라 원본 모델에서 볼 수 있는 개체입니다. 이는 다음 상황에서 발생할 수 있습니다.

  • 복합 모델을 보는 사람은 OLS에서 원본 모델의 숨겨진 개체를 볼 수 있습니다.
  • 반대로 원본 모델에 대한 액세스를 제어하는 OLS 규칙에 의해 복합 모델 작성자의 개체가 숨겨져 있기 때문에 원본 모델에서 볼 수 있는 개체는 복합 모델에 표시되지 않을 수 있습니다.

중요한 점은, 첫 번째 글머리 기호에 설명된 사례에도 불구하고, 복합 모델의 소비자는 데이터가 실제로 복합 모델에 있지 않기 때문에 표시되지 않는 실제 데이터를 표시하지 않는다는 것입니다. DirectQuery 때문에 원본 의미 체계 모델에서 필요에 따라 이를 검색합니다. 여기서 OLS는 무단 액세스를 차단합니다.

이 배경을 고려하여 다음 시나리오를 고려합니다.

Diagram showing what happens when a composite model connects to a source model protected by object-level security.

  1. Admin_user는 Power BI 의미 체계 모델 또는 고객 테이블과 지역 테이블이 있는 Analysis Services 모델을 사용하여 엔터프라이즈 의미 체계 모델을 게시했습니다. Admin_user는 의미 체계 모델을 Power BI 서비스에 게시하고 다음과 같은 영향을 주는 OLS 규칙을 설정합니다.

    • 재무 사용자는 고객 테이블을 볼 수 없습니다.
    • 마케팅 사용자는 지역 테이블을 볼 수 없습니다.

  2. Finance_user는 "재무 의미 체계 모델"이라는 의미 체계 모델과 DirectQuery를 통해 1단계에서 게시된 엔터프라이즈 의미 체계 모델에 연결하는 "재무 보고서"라는 보고서를 게시합니다. 재무 보고서는 지역 테이블의 열을 사용하는 시각적 개체를 포함합니다.

  3. Marketing_user는 재무 보고서를 엽니다. 보고서를 열 때 DirectQuery가 엔터프라이즈 의미 체계 모델에 설정된 OLS 규칙에 따라 지역 테이블을 볼 수 없도록 차단된 Marketing_user의 자격 증명을 사용하여 원본 모델에서 데이터를 검색하려고 시도하기 때문에 지역 테이블을 사용하는 시각적 개체를 표시하지만 오류를 반환합니다.

  4. Marketing_user는 재무 의미 체계 모델을 원본으로 사용하는 "마케팅 보고서"라는 새 보고서를 만듭니다. 필드 목록에는 Finance_user가 액세스할 수 있는 테이블 및 열이 표시됩니다. 따라서 지역 테이블은 필드 목록에 표시되지만 고객 테이블은 표시되지 않습니다. 그러나 Marketing_user에서 지역 테이블의 열을 활용하는 시각적 개체를 만들려고 하면 DirectQuery가 Marketing_user의 자격 증명을 사용하여 원본 모델에서 데이터를 검색하고 OLS 규칙이 다시 시작되고 액세스를 차단하기 때문에 오류가 반환됩니다. Marketing_user는 DirectQuery 연결을 사용하여 재무 의미 체계 모델에 연결하는 새 의미 체계 모델 및 보고서를 만들 때에도 마찬가지입니다. 이는 Finance_user가 볼 수 있는 것이므로 필드 목록에 지역 테이블이 표시되지만 해당 테이블을 활용하는 시각적 개체를 만들려고 할 때 엔터프라이즈 의미 체계 모델의 OLS 규칙에 의해 차단됩니다.

  5. 이제 Admin_user는 엔터프라이즈 의미 체계 모델에서 OLS 규칙을 업데이트하여 재무에서 지역 테이블을 볼 수 없도록 하는 것을 가정해 보겠습니다.

  6. 업데이트된 OLS 규칙은 새로 고칠 때만 재무 의미 체계 모델에 반영됩니다. 따라서 Finance_user가 재무 의미 체계 모델을 새로 고치면 지역 테이블은 더 이상 필드 목록에 표시되지 않으며, 지역 테이블의 열을 사용하는 재무 보고서의 시각적 개체는 이제 지역 테이블에 액세스할 수 없기 때문에 Finance_user에 대한 오류를 반환합니다.

요약:

  • 복합 모델의 소비자는 모델을 만들 때 복합 모델 작성자에게 적용되는 OLS 규칙의 결과를 볼 수 있습니다. 따라서 복합 모델을 기반으로 새 보고서를 만들 때 필드 목록에는 원본 모델에서 현재 사용자가 액세스할 수 있는 항목에 관계 없이 복합 모델 작성자가 모델을 만들 때 액세스할 수 있는 테이블이 표시됩니다.
  • 복합 모델 자체에서는 OLS 규칙을 정의할 수 없습니다.
  • 원본 모델의 관련 OLS 규칙이 DirectQuery에서 자격 증명을 사용하여 데이터를 검색하려고 할 때 이를 차단하기 때문에 복합 모델의 소비자는 볼 수 없는 실제 데이터가 표시되지 않습니다.
  • 원본 모델이 OLS 규칙을 업데이트하는 경우 이러한 변경 내용은 새로 고쳐질 때만 복합 모델에 영향을 줍니다.

Power BI 의미 체계 모델 또는 Analysis Services 모델에서 테이블 하위 집합 로드

DirectQuery 연결을 사용하여 Power BI 의미 체계 모델 또는 Analysis Services 모델에 연결하는 경우 연결할 테이블을 결정할 수 있습니다. 모델에 연결한 후 의미 체계 모델 또는 모델에 추가될 수 있는 테이블을 자동으로 추가하도록 선택할 수도 있습니다. 큐브 뷰에 연결하면 모델에 의미 체계 모델의 모든 테이블이 포함되고 큐브 뷰에 포함되지 않은 테이블은 숨겨집니다. 또한 큐브 뷰에 추가될 수 있는 모든 테이블이 자동으로 추가됩니다. 설정 메뉴에서 처음 연결을 설정한 후 의미 체계 모델 또는 모델에 추가된 테이블에 자동으로 연결하도록 결정할 수 있습니다.

이 대화 상자는 라이브 연결에 대해 표시되지 않습니다.

참고 항목

이 대화 상자는 Power BI 의미 체계 모델 또는 Analysis Services 모델에 대한 DirectQuery 연결을 기존 모델에 추가하는 경우에만 표시됩니다. 데이터 원본 설정에서 Power BI 의미 체계 모델 또는 Analysis Services 모델로의 DirectQuery 연결을 만든 후 연결을 변경하여 이 대화 상자를 열 수도 있습니다.

Dialog that allows specifying what tables to load from a Power BI semantic model or Analysis Services model.

중복 제거 규칙 설정

이전에 표시된 대화 상자의 설정 옵션을 사용하여 복합 모델에서 측정값 및 테이블 이름을 고유하게 유지하는 중복 제거 규칙을 지정할 수 있습니다.

Dialog that allows specifying deduplication rules to apply when loading from a semantic model.

이전 예제에서는 복합 모델의 다른 원본과 충돌하는 테이블 또는 측정값 이름에 접미사로 '(marketing)'을 추가하기로 결정했습니다. 다음을 수행할 수 있습니다.

  • 충돌하는 테이블 또는 측정값의 이름에 추가할 텍스트를 입력합니다.
  • 테이블 또는 측정값 이름에 텍스트를 접두사 또는 접미사로 추가할지를 지정합니다.
  • 테이블, 측정값 또는 둘 다에 중복 제거 규칙 적용
  • 이름 충돌이 발생할 때만 중복 제거 규칙을 적용하거나 항상 적용하도록 선택합니다. 기본값은 중복이 발생할 때만 규칙을 적용하는 것입니다. 이 예제에서 영업 원본에 중복이 없는 마케팅 원본의 테이블 또는 측정값은 이름 변경을 받지 않습니다.

연결을 만들고 중복 제거 규칙을 설정한 후 필드 목록에는 예제에 설정된 중복 제거 규칙에 따라 '고객' 및 '고객(마케팅)'이 모두 표시됩니다.

Dialog that allows specifying deduplication rules to apply when loading from a Power BI semantic model or Analysis Services model.

중복 제거 규칙이나 지정한 중복 제거 규칙을 지정하지 않을 경우 이름 충돌을 해결하지 않으면 표준 중복 제거 규칙이 계속 적용됩니다. 표준 중복 제거 규칙은 충돌하는 항목의 이름에 숫자를 추가합니다. 'Customer' 테이블에서 이름이 충돌하는 경우 'Customer' 테이블 중 하나가 'Customer 2'로 바뀝니다.

고려 사항 및 제한 사항

복합 모델에는 몇 가지 고려 사항 및 제한 사항이 있습니다.

혼합 모드 연결 - 온라인 데이터(예: Power BI 의미 체계 모델) 및 온-프레미스 의미 체계 모델(예: Excel 통합 문서)이 포함된 혼합 모드 연결을 사용하는 경우 시각적 개체가 제대로 표시되려면 게이트웨이 매핑이 설정되어야 합니다.

현재 SQL, Oracle 및 Teradata 데이터 원본에 연결하는 복합 모델에 대해서만 증분 새로 고침이 지원됩니다.

다음 Live Connect 테이블 형식 원본은 복합 모델과 함께 사용할 수 없습니다.

복합 모델에서 스트리밍 의미 체계 모델 사용은 지원되지 않습니다.

복합 모델을 사용하면 DirectQuery의 기존 제한 사항이 여전히 적용됩니다. 이러한 제한 사항 중 대부분은 테이블의 스토리지 모드에 따라 테이블별로 적용됩니다. 예를 들어, 가져오기 테이블의 계산 열은 DirectQuery에 없는 다른 테이블을 참조할 수 있지만 DirectQuery 테이블의 계산 열은 여전히 동일한 테이블의 열만 참조할 수 있습니다. 다른 제한 사항은 모델 내의 테이블이 DirectQuery인 경우 모델에 전체적으로 적용됩니다. 예를 들어 QuickInsights 기능은 모델 내의 테이블에 DirectQuery의 스토리지 모드가 있는 경우 모델에서 사용할 수 없습니다.

관련 콘텐츠

복합 모델 및 DirectQuery에 대한 자세한 내용은 다음 문서를 참조하세요.