다음을 통해 공유


Power BI Desktop의 모델 관계

이 문서에서는 Power BI Desktop을 사용하는 가져오기 데이터 모델러를 대상으로 합니다. 직관적이고 정확하며 최적의 모델을 제공하는 데 필수적인 중요한 모델 설계와 관련된 항목입니다.

테이블 역할 및 관계를 포함하여 최적의 모델 설계에 대한 자세한 내용은 Power BI의 별모양 스키마 및 중요성 이해를 참조하세요.

관계 용도

모델 관계는 한 모델 테이블의 열에 적용된 필터를 다른 모델 테이블에 전파합니다. 필터는 따라야 할 관계 경로가 있는 한 전파되며, 여기에는 여러 테이블로의 전파가 포함될 수 있습니다.

관계 경로는 결정적이므로 필터는 항상 임의의 변형 없이 동일한 방식으로 전파됩니다. 그러나 특정 DAX 함수를 사용하는 모델 계산에서 관계를 사용하지 않도록 설정하거나 필터 컨텍스트를 수정할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 나오는 관련 DAX 함수 항목을 참조하세요.

Important

모델 관계는 데이터 무결성을 적용하지 않습니다. 자세한 내용은 데이터 무결성 문제가 있을 때 모델 관계가 작동하는 방식을 설명하는 이 문서의 뒷부분에 있는 관계 평가 항목을 참조하세요.

애니메이션 예제를 사용하여 관계에서 필터를 전파하는 방법을 살펴보겠습니다.

관계 필터 전파의 애니메이션 다이어그램.

이 예에서 모델은 Category, Product, YearSales의 네 가지 테이블로 구성되어 있습니다. Category 테이블은 Product 테이블과 관계되며, Product 테이블은 Sales 테이블과 관계됩니다. Year 테이블은 Sales 테이블과도 관계됩니다. 모든 관계는 일대다입니다(자세한 내용은 이 문서의 뒷부분에서 설명함).

Power BI 카드 시각적 개체에서 생성하는 쿼리는 Cat-A 단일 범주 및 CY2018 단일 연도에 이루어진 판매 주문의 총 판매량을 요청합니다. 이렇게 하면 CategoryYear 테이블에 적용된 필터를 볼 수 있습니다. Category 테이블의 필터가 Product 테이블로 전파되어 Cat-A 범주에 할당된 두 제품을 격리합니다. 그런 다음, Product 테이블 필터가 Sales 테이블로 전파되어 이러한 제품에 대한 두 개의 판매 행만 격리합니다. 이러한 두 개의 판매 행은 Cat-A 범주에 할당된 제품의 판매량을 나타냅니다. 결합된 수량은 14단위입니다. 이와 동시에 Sales 테이블을 추가로 필터링하기 위해 Year 테이블 필터가 전파되어 Cat-A 범주에 할당되고 CY2018년에 주문된 제품에 대한 하나의 판매 행이 생성됩니다. 쿼리에서 반환한 수량 값은 11단위입니다. 이 예의 Sales 테이블과 같이 여러 필터가 테이블에 적용되는 경우 항상 AND 연산이므로 모든 조건이 참이어야 합니다.

별모양 스키마 디자인 원칙 적용

차원 및 팩트 테이블로 구성된 모델을 생성하려면 별모양 스키마 디자인 원칙을 적용하는 것이 좋습니다. 일반적으로는 차원 테이블을 필터링하는 규칙을 적용하도록 Power BI 설정하여, 모델 관계에서 이러한 필터를 팩트 테이블에 효율적으로 전파할 수 있게 합니다.

다음 이미지는 Adventure Works 판매 분석 데이터 모델의 모델 다이어그램입니다. Sales라는 단일 팩트 테이블로 구성된 별모양 스키마 디자인을 보여줍니다. 나머지 4개 테이블은 날짜, 주, 지역 및 제품별 판매 측정값 분석을 지원하는 차원 테이블입니다. 모든 테이블을 연결하는 모델 관계에 주목하세요. 이러한 관계는 필터를 직접 또는 간접적으로 Sales 테이블에 전파합니다.

이전 단락에 설명한 테이블 및 관계로 구성된 Power BI Desktop 모델 다이어그램의 스크린샷

연결되지 않은 테이블

모델 테이블이 다른 모델 테이블과 관계되지 않은 것은 드문 일입니다. 유효한 모델 설계에서 이러한 테이블은 연결되지 않은 테이블이라고 설명합니다. 연결되지 않은 테이블은 필터를 다른 모델 테이블에 전파하지 않습니다. 대신 "사용자 입력"(예: 슬라이서 시각적 개체 사용)을 수신하여, 모델 계산에서 입력 값을 의미 있는 방식으로 사용할 수 있게 합니다. 예를 들어 다양한 통화 환율 값을 사용하여 로드된 연결되지 않은 테이블을 생각해 보세요. 단일 환율 값을 기준으로 필터링하는 필터가 적용되는 경우 측정값 식에서 이 값을 사용하여 판매 값을 변환할 수 있습니다.

Power BI Desktop what-if 매개 변수는 연결되지 않은 테이블을 만드는 기능입니다. 자세한 내용은 Power BI Desktop에서 변수를 시각화하기 위해 What if 매개 변수 만들기 및 사용을 참조하세요.

관계 속성

모델 관계는 테이블의 한 열을 다른 테이블의 한 열과 관계시킵니다. (이 요구 사항이 충족되지 않고 DirectQuery 모델의 다중 열 관계에만 적용되는 특수한 사례가 하나 있습니다. 자세한 내용은 COMBINEVALUES DAX 함수 문서를 참조하세요.)

참고 항목

열을 동일한 테이블 의 다른 열과 관계시킬 수 없습니다. 이 개념은 테이블 자체 참조인 관계형 데이터베이스 외부 키 제약 조건을 정의하는 기능과 혼동되기도 합니다. 이 관계형 데이터베이스 개념을 사용하여 부모-자식 관계를 저장할 수 있습니다(예: 각 직원 레코드가 "보고 대상" 직원과 관계됨). 그러나 모델 관계를 사용하여 이 유형의 관계에 따라 모델 계층 구조를 생성할 수는 없습니다. 부모-자식 계층 구조를 만드는 방법은 부모 및 자식 함수를 참조하세요.

열의 데이터 형식

관계의 "from" 열과 "to' 열 모두에 대한 데이터 형식은 동일해야 합니다. DateTime 열에 정의된 관계로 작업하는 것이 예상대로 작동하지 않을 수 있습니다. Power BI 데이터를 저장하는 엔진은 DateTime 데이터 형식만 사용합니다. 날짜, 시간날짜/시간/표준 시간대 데이터 형식은 Power BI 형식 지정 구문이 맨 위에 구현됩니다. 모델 종속 개체는 여전히 엔진에서 DateTime에 표시됩니다(예: 관계, 그룹 등). 따라서 사용자가 이러한 열에 대해 모델링 탭에서 날짜를 선택하면 데이터의 시간 부분이 엔진에서 고려되기 때문에 여전히 동일한 날짜로 등록되지 않습니다. 날짜/시간 형식이 처리되는 방법에 대해 자세히 알아봅니다. 동작을 수정하려면 가져온 데이터에서 시간 부분을 제거하기 위해 Power Query 편집기에서 열 데이터 형식을 업데이트해야 하므로 엔진에서 데이터를 처리할 때 값이 동일하게 표시됩니다.

카디널리티

각 모델 관계는 카디널리티 유형으로 정의합니다. "from"(원본) 및 "to"(대상) 관계 열의 데이터 특성을 나타내는 네 가지 카디널리티 유형 옵션이 있습니다. “일” 쪽은 열에 고유 값이 포함되어 있음을 의미하며, “다” 쪽은 열에 중복 값이 포함될 수 있음을 의미합니다.

참고

데이터 새로 고침 작업에서 중복 값을 "일" 쪽 열에 로드하려고 하면 전체 데이터 새로 고침이 실패합니다.

다음 글머리 기호 목록에서는 네 가지 옵션을 설명합니다(모두 줄임 표기법 사용).

  • 일대다(1:*)
  • 다 대 일(*:1)
  • 일대일 (1:1)
  • 다 대 다(*:*)

Power BI Desktop에서 관계를 만들면 디자이너에서 카디널리티 유형을 자동으로 검색하고 설정합니다. Power BI Desktop은 고유 값을 포함하는 열을 확인하기 위해 모델을 쿼리합니다. 가져오기 모델의 경우 내부 스토리지 통계를 사용하고, DirectQuery 모델의 경우 프로파일링 쿼리를 데이터 원본에 보냅니다. 그러나 Power BI Desktop에서 오류가 발생하기도 합니다. 테이블에 데이터가 아직 로드되지 않았거나 중복 값이 포함될 것으로 예상되는 열에 현재 고유 값이 포함되어 있으면 문제가 발생할 수 있습니다. 두 경우 모두 "일" 쪽 열에 고유 값이 포함되어 있거나 데이터 행이 테이블에 아직 로드되지 않았으면 카디널리티 유형을 업데이트할 수 있습니다.

일대다(및 다대일) 카디널리티

일대다다대일 카디널리티 옵션은 기본적으로 동일하며, 가장 일반적인 카디널리티 유형이기도 합니다.

일대일 또는 다대일 관계를 구성하는 경우 열과 관계된 순서와 일치하는 관계를 선택합니다. 각 테이블에 있는 ProductID 열을 사용하여 Product 테이블에서 Sales 테이블로의 관계를 구성하는 방법을 고려합니다. Product 테이블의 ProductID 열에 고유 값이 포함되어 있으므로 카디널리티 유형은 일대다입니다. 테이블의 관계를 역방향으로(Sales에서 Product으로) 구성하는 경우 카디널리티는 다대일입니다.

일대일 카디널리티

일대일 관계는 두 열에 고유 값이 포함되어 있음을 의미합니다. 이 카디널리티 유형은 일반적이지 않으며, 중복 데이터가 저장되므로 최적이 아닌 모델 설계를 나타낼 가능성이 높습니다.

이 카디널리티 유형을 사용하는 자세한 내용은 일 대 일 관계 지침을 참조하세요.

다대다 카디널리티

다대다 관계는 두 열에 중복 값이 포함될 수 있음을 의미합니다. 이 카디널리티 유형은 자주 사용되지 않습니다. 일반적으로 복잡한 모델 요구 사항을 설계할 때 유용합니다. 다대다 팩트를 관련짓거나 상위 단위 팩트를 관련짓는 데 사용할 수 있습니다. 대표적인 예는 판매 대상 팩트는 제품 범주 수준에 저장되고 제품 차원 테이블은 제품 수준에 저장되는 경우입니다.

이 카디널리티 유형을 사용하는 방법에 대한 지침은 다 대 다 관계 지침을 참조하세요.

참고 항목

2024년 1월 및 그 이후 버전의 Power BI Report Server용으로 개발된 모델에는 다대다 카디널리티 유형이 지원되지 않습니다.

Power BI Desktop 모델 보기에서 관계 선의 양쪽에 있는 표시기(1 또는 *)를 살펴보면 관계의 카디널리티 유형을 해석할 수 있습니다. 관계된 열을 확인하려면 관계 선을 선택하거나 커서로 관계 위를 가리켜서 해당 열을 강조 표시해야 합니다.

카디널리티 표시기가 강조 표시된 모델 다이어그램의 두 테이블 스크린샷.

교차 필터 방향

각 모델 관계는 교차 필터 방향으로 정의합니다. 설정에 따라 필터가 전파되는 방향이 결정됩니다. 가능한 교차 필터 옵션은 카디널리티 유형에 따라 달라집니다.

카디널리티 유형 교차 필터 옵션
일대다(또는 다대일) 단일
모두
일대일 모두
다대다 단일(Table1에서 Table2로)
단일(Table2에서 Table1로)
모두

단일 교차 필터 방향은 "단방향"을 의미하며, 모두 는 "양방향"을 의미합니다. 양방향으로 필터링하는 관계를 일반적으로 양방향이라고 합니다.

일대다 관계의 경우 교차 필터 방향은 항상 "한쪽" 방향에서 시작되며, "다수" 방향(양방향)에서의 시작을 선택할 수 있습니다. 일대일 관계의 경우 교차 필터 방향은 항상 두 테이블 모두에서 시작됩니다. 마지막으로, 다대다 관계의 경우 교차 필터 방향은 테이블 중 하나 또는 두 테이블 모두에서 시작될 수 있습니다. 카디널리티 유형에 "일" 쪽이 포함되어 있으면 해당 필터가 항상 해당 쪽에서 전파됩니다.

교차 필터 방향이 모두로 설정된 경우에는 다른 속성을 사용할 수 있습니다. Power BI에서 RLS(행 수준 보안) 규칙을 적용하는 경우 양방향 필터링을 적용할 수 있습니다. RLS에 대한 자세한 내용은 Power BI Desktop을 사용하는 RLS(행 수준 보안)를 참조하세요.

모델 계산을 사용하여 관계 교차 필터 방향을 수정할 수 있습니다(필터 전파 비활성화 포함). 이는 CROSSFILTER DAX 함수를 사용하여 달성할 수 있습니다.

양방향 관계는 성능에 부정적인 영향을 미칠 수 있다는 사실에 유의하세요. 또한 양방향 관계를 구성하려고 하면 필터 전파 경로가 모호해질 수 있습니다. 이 경우 Power BI Desktop에서 관계 변경을 커밋하지 못할 수 있으며 오류 메시지가 표시됩니다. 그러나 경우에 따라 Power BI Desktop을 사용하여 테이블 간의 모호한 관계 경로를 정의할 수 있습니다. 관계 경로 모호성 해결은 이 문서의 뒷부분에 설명되어 있습니다.

필요한 경우에만 양방향 필터링을 사용하는 것이 좋습니다. 자세한 내용은 양방향 관계 지침을 참조하세요.

Power BI Desktop 모델 보기에서 관계 선을 따라 화살촉을 확인하여 관계의 교차 필터 방향을 해석할 수 있습니다. 단일 화살촉은 화살촉 방향의 단방향 필터를 나타내며, 이중 화살촉은 양방향 관계를 나타냅니다.

모델 다이어그램에서 교차 필터 화살촉이 강조 표시된 두 테이블의 스크린샷

이 관계를 활성으로 만들기

두 모델 테이블 사이에는 하나의 활성 필터 전파 경로만 있을 수 있습니다. 추가 관계 경로를 도입할 수도 있지만, 이러한 관계는 모두 비활성으로 구성해야 합니다. 비활성 관계는 모델 계산 평가 중에만 활성화할 수 있습니다. 이는 USERELATIONSHIP DAX 함수를 사용하여 달성할 수 있습니다.

일반적으로 가능한 경우 항상 활성 관계를 정의하는 것이 좋습니다. 보고서 작성자가 모델을 더욱 다양하고 강력하게 사용할 수 있게 합니다. 활성 관계만 사용한다면 모델에서 역할 재생 차원 테이블이 중복되어야 합니다.

그러나 특정 상황에서는 롤플레잉 차원 테이블에 대해 하나 이상의 비활성 관계를 정의할 수 있습니다. 다음과 같은 경우 이 디자인을 고려할 수 있습니다.

  • 보고서 시각적 개체에서 여러 역할로 동시에 필터링할 필요는 없습니다.
  • USERELATIONSHIP DAX 함수를 사용하여 관련 모델 계산에 대한 특정 관계를 활성화합니다.

자세한 내용은 활성 및 비활성 관계 지침을 참조하세요.

Power BI Desktop 모델 보기에서 관계의 활성 상태와 비활성 상태를 해석할 수 있습니다. 활성 관계는 실선으로 표시되며, 비활성 관계는 파선으로 표시됩니다.

모델 다이어그램 및 두 개의 관계에 있는 두 테이블의 스크린샷. 활성의 경우 하나의 실선, 비활성의 경우 하나의 파선입니다.

참조 무결성 가정

참조 무결성 가정 속성은 동일한 원본 그룹에 속하는 두 DirectQuery 스토리지 모드 테이블 간의 일대다 및 일대일 관계에만 사용할 수 있습니다. 이 속성은 "다수" 측면 열에 NULL이 포함되지 않은 경우에만 사용하도록 설정할 수 있습니다.

이 속성을 사용하도록 설정하면 데이터 원본으로 보내는 네이티브 쿼리가 OUTER JOIN 대신 INNER JOIN을 사용하여 두 테이블을 조인합니다. 일반적으로 이 속성을 사용하도록 설정하면 쿼리 성능이 향상되지만 데이터 원본의 세부 정보에 따라 달라집니다.

두 테이블 간에 데이터베이스 외부 키 제약 조건이 있는 경우 항상 이 속성을 사용하도록 설정하세요. 외부 키 제약 조건이 없는 경우에도 데이터 무결성이 확실하다면 이 속성을 사용하도록 설정해도 됩니다.

중요

데이터 무결성이 손상되면 내부 조인에서 테이블 간에 일치하지 않는 행을 제거합니다. 예를 들어 관계된 Product 테이블에 없는 ProductID 열 값이 있는 Sales 테이블 모델을 생각해 보세요. Product 테이블에서 Sales 테이블로의 필터 전파는 알 수 없는 제품의 판매 행을 제거합니다. 이로 인해 판매 결과가 과소평가될 수 있습니다.

자세한 내용은 Power BI Desktop의 참조 무결성 설정 가정을 참조하세요.

관련 DAX 함수

모델 관계와 관련된 몇 가지 DAX 함수가 있습니다. 다음 글머리 기호 목록에서는 각 함수에 대해 간략히 설명합니다.

  • RELATED: 관계의 "한쪽" 방향에서 값을 검색합니다. 행 컨텍스트에서 평가하는 여러 테이블의 계산을 포함할 때 유용합니다.
  • RELATEDTABLE: 관계의 "다수" 방향에서 행의 테이블을 검색합니다.
  • USERELATIONSHIP: 계산에서 비활성 관계를 사용할 수 있습니다. (기술적으로 이 함수는 특정 비활성 모델 관계의 가중치를 수정하여 사용에 영향을 줍니다.) 모델에 롤플레잉 차원 테이블이 포함되어 있고 이 테이블에서 비활성 관계를 만들기로 한 경우에 유용합니다. 이 함수를 사용하여 필터 경로의 모호성을 해결할 수도 있습니다.
  • CROSSFILTER: 관계 교차 필터 방향을 (하나 또는 둘 다) 수정하거나 필터 전파를 사용하지 않도록 설정합니다(없음). 특정 계산을 평가하는 동안 모델 관계를 변경하거나 무시해야 하는 경우에 유용합니다.
  • COMBINEVALUES: 두 개 이상의 텍스트 문자열을 하나의 텍스트 문자열에 조인합니다. 이 함수의 목적은 테이블이 동일한 원본 그룹에 속하는 경우 DirectQuery 모델에서 다중 열 관계를 지원하는 것입니다.
  • TREATAS: 관련 없는 테이블의 열에 테이블 식의 결과를 필터로 적용합니다. 특정 계산을 평가하는 동안 가상 관계를 만들어야 하는 고급 시나리오에서 유용합니다.
  • 부모 및 자식 함수: 부모-자식 계층을 이식하기 위해 계산 열을 생성하는 데 사용할 수 있는 관계 함수의 패밀리입니다. 이러한 열을 사용하여 고정 수준 계층 구조를 만들 수 있습니다.

관계 평가

모델 관계는 평가 관점에서 일반 또는 제한으로 분류됩니다. 구성 가능한 관계 속성이 아닙니다. 이는 실제로 두 관계 테이블의 카디널리티 유형과 데이터 원본에서 유추됩니다. 데이터 무결성이 손상되면 성능에 영향을 미치거나 결과가 발생할 수 있으므로 평가 유형을 이해하는 것이 중요합니다. 이러한 의미와 무결성 결과는 이 항목에서 설명합니다.

먼저 관계 평가를 완전히 이해하려면 일부 모델링 이론이 필요합니다.

가져오기 또는 DirectQuery 모델은 Vertipaq 캐시 또는 원본 데이터베이스의 모든 데이터를 원본으로 합니다. 두 경우 모두에서 Power BI는 관계의 "일" 쪽이 있는지 확인할 수 있습니다.

그러나 복합 모델은 서로 다른 스토리지 모드(가져오기, DirectQuery 또는 이중) 또는 여러 DirectQuery 원본을 사용하는 테이블로 구성될 수 있습니다. 가져온 데이터의 Vertipaq 캐시를 포함한 각 원본은 원본 그룹으로 간주됩니다. 그러면 모델 관계를 원본 그룹 내 또는 원본 그룹 간/교차로 분류할 수 있습니다. 원본 그룹 내 관계는 원본 그룹 내에서 두 테이블을 연결하는 관계이지만, 원본 그룹 간/교차 관계는 두 원본 그룹 간에 테이블을 연결하는 관계입니다. 가져오기 또는 DirectQuery 모델의 관계는 항상 원본 그룹 내 관계입니다.

다음은 복합 모델의 예입니다.

두 개의 원본 그룹으로 구성된 복합 모델의 다이어그램.

이 예의 복합 모델은 Vertipaq 원본 그룹과 DirectQuery 원본 그룹이라는 두 개의 원본 그룹으로 구성됩니다. Vertipaq 원본 그룹에는 세 개의 테이블이 있고, DirectQuery 원본 그룹에는 두 개의 테이블이 있습니다. Vertipaq 원본 그룹의 테이블을 DirectQuery 원본 그룹의 테이블과 연결하는 하나의 교차 원본 그룹 관계가 있습니다.

일반 관계

쿼리 엔진에서 관계의 "일" 쪽을 확인할 수 있는 경우 모델 관계는 일반 입니다. "일" 쪽 열에 고유 값이 포함되어 있음을 확인했습니다. 모든 일대다 원본 그룹 내 관계는 일반 관계입니다.

다음 예에는 둘 다 R로 표시된 두 개의 일반 관계가 있습니다. 관계에는 Vertipaq 원본 그룹 내에 포함된 일대다 관계와 DirectQuery 원본에 포함된 일대다 관계가 있습니다.

일반 관계가 표시된 두 개의 원본 그룹으로 구성된 복합 모델의 다이어그램.

모든 데이터가 Vertipaq 캐시에 저장되는 가져오기 모델의 경우 데이터를 새로 고칠 때 Power BI가 각 일반 관계에 대한 데이터 구조를 만듭니다. 데이터 구조는 모든 열-열 값이 인덱싱된 매핑으로 구성되며, 이 매핑은 쿼리 시 테이블 조인을 가속화하기 위한 것입니다.

쿼리 시 일반 관계를 사용하면 테이블 확장을 수행할 수 있습니다. 테이블 확장은 기본 테이블의 네이티브 열을 포함시킨 다음, 관계 테이블로 확장하여 가상 테이블을 만듭니다. 가져오기 테이블의 경우 테이블 확장은 쿼리 엔진에서 수행하고, DirectQuery 테이블의 경우 원본 데이터베이스에 보낸 네이티브 쿼리에서 수행합니다(참조 무결성 가정 속성이 사용하지 않도록 설정된 경우). 그런 다음, 쿼리 엔진에서 확장된 테이블에 작용하여 필터를 적용하고, 확장된 테이블 열의 값을 기준으로 그룹화합니다.

참고

계산에서 관계를 사용하지 않는 경우에도 비활성 관계가 확장됩니다. 양방향 관계는 테이블 확장에 영향을 주지 않습니다.

일대다 관계의 경우 LEFT OUTER JOIN 의미 체계를 사용하여 테이블 확장이 “다” 쪽에서 “일” 쪽으로 수행됩니다. "다" 쪽에서 "일" 쪽으로 일치하는 값이 없으면 빈 가상 행이 "일" 쪽 테이블에 추가됩니다. 이 동작은 제한된 관계에는 적용되지 않고 일반 관계에만 적용됩니다.

일대일 원본 그룹 내 관계의 경우에도 테이블 확장이 수행되지만 FULL OUTER JOIN 의미 체계를 사용합니다. 이 조인 유형에서는 필요한 경우 빈 가상 행이 양쪽에 추가되도록 합니다.

빈 가상 행은 사실상 알 수 없는 멤버입니다. 알 수 없는 멤버는 "다" 쪽 값에 해당하는 "일" 쪽 값이 없는 참조 무결성 위반을 나타냅니다. 이상적으로는 이러한 빈 가상 행이 없어야 합니다. 원본 데이터를 정리 또는 복구하면 제거할 수 있습니다.

다음은 테이블 확장이 작동하는 방식의 애니메이션 예입니다.

테이블 확장의 애니메이션 다이어그램.

이 예의 모델은 Category, ProductSales의 세 개 테이블로 구성됩니다. Category 테이블은 일대다 관계가 있는 Product 테이블과 관계되고, Product 테이블은 일대다 관계가 있는 Sales 테이블과 관계됩니다. Category 테이블에는 두 개의 행이 있고, Product 테이블에는 세 개의 행이 있으며, Sales 테이블에는 다섯 개의 행이 있습니다. 모든 관계의 양쪽에 일치하는 값이 있으며, 이는 참조 무결성 위반이 없음을 의미합니다. 쿼리 시에 확장된 테이블이 표시됩니다. 이 테이블은 세 테이블의 열로 구성되어 있습니다. 이는 실질적으로 세 개의 테이블에 포함된 데이터의 비정규화된 관점입니다. 새 행이 Sales 테이블에 추가되고, Product 테이블에 일치하는 값이 없는 프로덕션 식별자 값(9)이 있습니다. 이는 참조 무결성 위반입니다. 확장된 테이블의 새 행에는 CategoryProduct 테이블 열에 대한 Blank(비어 있음) 값이 있습니다.

제한된 관계

"일" 쪽이 보장되지 않는 경우 모델 관계는 제한입니다. 제한된 관계는 다음 두 가지 이유로 발생할 수 있습니다.

  • 관계에서 다대다 카디널리티 유형을 사용합니다(하나 또는 두 열에 고유 값이 포함되어 있는 경우에도).
  • 관계가 교차 원본 그룹입니다(복합 모델의 경우만 해당될 수 있음).

다음 예에는 둘 다 L로 표시된 두 개의 제한된 관계가 있습니다. 두 관계에는 Vertipaq 원본 그룹 내에 포함된 다대다 관계와 일대다 교차 원본 그룹 관계가 있습니다.

제한된 관계가 표시된 두 개의 원본 그룹으로 구성된 복합 모델의 다이어그램.

가져오기 모델의 경우 제한된 관계에 대한 데이터 구조가 만들어지지 않습니다. 이 경우 Power BI가 쿼리 시 테이블 조인을 확인합니다.

제한된 관계에서는 테이블 확장이 수행되지 않습니다. 테이블 조인은 INNER JOIN 의미 체계를 사용하여 수행되며, 이로 인해 참조 무결성 위반을 보정하기 위한 빈 가상 행이 추가되지 않습니다.

제한된 관계와 관련된 다른 제한 사항이 있습니다.

  • RELATED DAX 함수를 사용하여 "일" 쪽 열 값을 검색할 수 없습니다.
  • RLS 적용에는 토폴로지 제한이 있습니다.

Power BI Desktop 모델 보기에서 관계를 제한되는 것으로 해석할 수 있습니다. 제한된 관계는 카디널리티 표시기 다음에 괄호와 같은 표시 ()로 표시됩니다.

모델 다이어그램에서 제한된 관계가 강조 표시된 두 테이블의 스크린샷.

관계 경로 모호성 해결

양방향 관계는 모델 테이블 간에 여러 개의 필터 전파 경로를 도입할 수 있으며, 이로 인해 모호해질 수 있습니다. 모호성을 평가할 때 Power BI는 우선 순위가중치에 따라 필터 전파 경로를 선택합니다.

우선 순위

우선 순위 계층은 Power BI가 관계 경로 모호성을 해결하는 데 사용하는 규칙의 시퀀스를 정의합니다. 첫 번째 규칙 일치는 따라야 할 경로를 결정합니다. 아래 각 규칙은 필터가 원본 테이블에서 대상 테이블로 흐르는 방법을 설명합니다.

  1. 일대다 관계로 구성된 경로.
  2. 일대다 또는 다대다 관계로 구성된 경로.
  3. 다대일 관계로 구성된 경로.
  4. 원본 테이블에서 중간 테이블로의 일대다 관계에 이은 중간 테이블에서 대상 테이블로의 다대일 관계로 구성된 경로.
  5. 원본 테이블에서 중간 테이블로의 일대다 또는 다대다 관계에 이은 중간 테이블에서 대상 테이블로의 다대일 또는 다대다 관계로 구성된 경로.
  6. 모든 기타 경로.

사용 가능한 모든 경로에 관계가 포함되어 있으면 모든 경로의 고려 사항에서 관계가 제거됩니다.

가중치

경로의 각 관계에는 가중치가 있습니다. 기본적으로 USERELATIONSHIP 함수를 사용하지 않는 한, 각 관계 가중치는 동일합니다. 경로 가중치는 경로를 따르는 모든 관계 가중치의 최댓값입니다. Power BI는 경로 가중치를 사용하여 동일한 우선 순위 계층에서 여러 경로 간의 모호성을 해결합니다. 우선 순위가 낮은 경로를 선택하지는 않지만 가중치가 더 높은 경로를 선택합니다. 경로에서 관계의 수는 가중치에 영향을 주지 않습니다.

USERELATIONSHIP 함수를 사용하여 관계의 가중치에 영향을 줄 수 있습니다. 가중치는 가장 안쪽 호출이 가장 높은 가중치를 수신하는 이 함수에 대한 호출의 중첩 수준에 따라 결정됩니다.

아래 예제를 고려해 보세요. Product Sales 측정값은 Sales[ProductID]Product[ProductID] 간의 관계에 더 높은 가중치를 할당하며 그 다음으로 Inventory[ProductID]Product[ProductID] 간의 관계가 옵니다.

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

참고 항목

Power BI에서 우선 순위가 동일하고 가중치가 같은 여러 경로를 검색하면 모호한 경로 오류가 반환됩니다. 이 경우 USERELATIONSHIP 함수를 사용하거나 모델 관계를 제거 또는 수정하여 관계 가중치에 영향을 줌으로써 모호성을 해결해야 합니다.

성능 기본 설정

다음 목록의 순서는 전파 성능을 가장 빠른 성능에서 가장 느린 성능까지 필터링합니다.

  1. 일대다 원본 그룹 내 관계
  2. 다대다 모델 관계(중간 테이블을 사용하고, 하나 이상의 양방향 관계를 포함)
  3. 다대다 카디널리티 관계
  4. 교차 원본 그룹 관계

이 문서에 대한 자세한 내용은 다음 리소스를 참조하세요.