다음을 통해 공유

활성 및 비활성 관계 지침

  • 아티클

이 기사는 Power BI Desktop을 사용하는 데이터 모델러를 대상으로 합니다. 활성 또는 비활성 모델 관계를 만드는 시기에 대한 지침을 제공합니다. 기본적으로 활성 관계는 필터를 다른 테이블로 전파합니다. 활성화되지 않은 관계는 DAX 식이 그 관계를 활성화(사용)하는 경우에만 필터를 전파합니다.

메모

모델 관계에 대한 소개는 이 문서에서 다루지 않습니다. 관계, 해당 속성 또는 구성 방법에 대해 잘 모르는 경우 먼저 Power BI Desktop 문서에서 모델 관계를 읽어보는 것이 좋습니다.

스타 스키마 디자인을 이해하는 것도 중요합니다. 자세한 내용은 스타 스키마 이해 및 Power BI의 중요성을 참조하세요.

활성 관계

일반적으로 가능한 한 활성 관계를 정의하는 것이 좋습니다. 보고서 작성자와 Q&A로 작업하는 사용자가 모델을 사용하는 방법의 범위와 잠재력을 확장합니다.

OTP(정시 운항 성과)를 분석하도록 설계된 가져오기 모델의 예를 고려해 보세요. 모델에는 플라이트당 한 행을 저장하는 팩트 테이블Flight 테이블이 있습니다. 각 행에는 비행 날짜, 비행 번호, 출발 및 도착 공항, 그리고 지연 시간(분)이 기록됩니다. 공항당 한 행을 저장하는 차원 테이블인 테이블도 있습니다. 각 행은 공항 코드, 공항 이름 및 국가 또는 지역을 설명합니다.

다음은 두 테이블의 부분 모델 다이어그램입니다.

플라이트와 공항의 두 테이블을 포함하는 모델을 보여 주는 다이어그램 관계 디자인은 다음 단락에 설명되어 있습니다.

Flight 테이블과 Airport 테이블 사이에는 두 가지 모델 관계가 있습니다. Flight 테이블에서 DepartureAirport 및 ArrivalAirport 열은 Airport 테이블의 Airport 열과 관련이 있습니다. 스타 스키마 디자인에서 Airport 테이블은 롤플레잉 디멘션로 설명된다. 이 모델에서 두 역할은 출발 공항 과 도착 공항 입니다.

이 디자인은 관계형 별모양 스키마 디자인에 적합하지만 Power BI 모델에는 적합하지 않습니다. 모델 관계는 필터 전파를 위한 경로이며 이러한 경로는 결정적이어야 하기 때문입니다. 필터 전파 경로가 결정적인지 확인하는 방법에 대한 자세한 내용은 관계 경로 모호성 을 확인하세요. 따라서 예에서 보여주듯, 한 관계는 활성 상태이고 다른 관계는 비활성 상태입니다(파선으로 표시됨). 특히 활성 상태인 ArrivalAirport 열과의 관계는, Airport 테이블에 적용된 필터가 Flight 테이블의 ArrivalAirport 열로 자동으로 전파된다는 것을 의미합니다.

이 모델 디자인은 데이터를 보고하는 방법에 심각한 제한을 적용합니다. 특히 Airport 테이블을 필터링하여 출발 공항의 항공편 세부 정보를 자동으로 격리할 수 없습니다. 출발 및 도착 공항별로 보고서를 필터링(또는 그룹화)해야 하므로 두 가지 활성 관계가 필요합니다. 이 요구 사항을 Power BI 모델 디자인으로 변환하면 모델에 두 개의 공항 테이블이 있어야 합니다.

향상된 모델 디자인은 다음과 같습니다.

날짜, 항공편, 출발 공항 및 도착 공항의 네 개의 테이블을 포함하는 모델을 보여 주는 다이어그램

이제 모델에는 Departure Airport 및 Arrival Airport두 개의 공항 테이블이 있습니다. 이러한 테이블과 Flight 테이블 간의 각 모델 관계는 활성 상태입니다. 또한 Departure Airport 및 Arrival Airport 테이블의 열 이름 앞에는 출발 또는 도착라는 단어가 수록되어 있습니다.

향상된 모델 디자인은 다음 보고서 디자인을 생성할 수 있습니다.

보고서 페이지를 보여 주는 도표에는 두 개의 슬라이서와 테이블 그래픽이 있습니다. 슬라이서는 월과 출발 공항으로 되어 있습니다.

보고서 페이지는 멜버른 출발 공항으로 필터링하고, 테이블 시각적 개체는 도착 공항별로 그룹화합니다.

메모

가져오기 모델의 경우 다른 차원 테이블을 추가하면 모델 크기가 증가하고 새로 고침 시간이 길어집니다. 따라서 이는 가져오기 모델링 문서에 설명된 데이터 감소 기술의 권장 사항과 모순됩니다. 그러나 이 예제에서는 활성 관계만 있어야 한다는 요구 사항이 이러한 권장 사항보다 우선합니다.

또한 차원 테이블은 팩트 테이블 행 개수에 비해 낮은 행 수를 저장하는 것이 일반적입니다. 따라서 모델 크기와 새로 고침 시간이 커질 가능성은 많지 않을 것입니다.

리팩터링 방법론

다음은 단일 역할 재생 차원 테이블에서 역할하나의 테이블이 있는 디자인으로 모델을 리팩터링하는 방법입니다.

  1. 비활성 관계를 제거합니다.

  2. 역할 수행 차원 테이블의 이름을 바꾸어 그 역할을 더 잘 설명하는 것이 좋습니다. 이 문서의 예제에서 Airport 테이블은 Flight 테이블의 ArrivalAirport 열과 관련이 있으므로, Arrival Airport으로 이름이 변경되었습니다.

  3. 롤플레잉 테이블의 복사본을 만들어 해당 역할을 반영하는 이름을 지정합니다. 가져오기 테이블인 경우 계산 테이블을 만드는 것이 좋습니다. DirectQuery 테이블인 경우 파워 쿼리 쿼리를 복제할 수 있습니다.

    이 예제에서는 다음 계산 테이블 정의를 사용하여 Departure Airport 테이블을 만들었습니다.

    Departure Airport = 'Arrival Airport'

  4. 새 테이블을 연결할 활성 관계를 만듭니다.

  5. 해당 역할을 정확하게 반영할 수 있도록 테이블의 열 이름을 바꾸는 것이 좋습니다. 이 문서의 예제에서 모든 열에는 출발 또는 도착이라는 단어가 접두사로 지정됩니다. 이러한 이름은 기본적으로 보고서 시각적 개체가 스스로 설명하고 모호하지 않은 레이블을 갖도록 합니다. 또한 Q&A 환경을 개선하여 사용자가 정확한 질문을 쉽게 작성할 수 있도록 합니다.

  6. 역할극 표에 설명을 추가하는 것을 고려하세요. (데이터 창에서 보고서 작성자가 테이블 위에 커서를 놓으면 설명이 도구 설명에 나타납니다. 이렇게 하면 다른 필터 전파 세부 정보를 보고서 작성자에게 전달할 수 있습니다.

비활성 관계

특정 상황에서 비활성 관계는 특정 보고 요구 사항을 해결할 수 있습니다.

다른 모델 및 보고 요구 사항을 고려합니다.

  • 판매 모델에는 OrderDate 및 ShipDate두 개의 날짜 열이 있는 Sales 테이블이 포함되어 있습니다.
  • Sales 테이블의 각 행은 단일 순서를 기록합니다.
  • 날짜 필터는 항상 유효한 날짜를 저장하는 OrderDate 열에 거의 항상 적용됩니다.
  • 단 하나의 측정값만 ShipDate 열로 날짜 필터 전파가 필요하며, 이 열에는 주문이 배송될 때까지 BLANK가 포함될 수 있습니다.
  • 주문 번호 및의 배송 날짜 기간을 동시에 필터링하거나 그룹화할 필요가 없습니다.

다음은 두 테이블의 부분 모델 다이어그램입니다.

두 개의 테이블, Sales 및 Date를 포함하는 모델을 나타내는 도표입니다. Sales 테이블에는 6개의 측정값이 포함되어 있습니다.

Sales 테이블과 Date 테이블 사이에는 두 가지 모델 관계가 있습니다. Sales 테이블에서 OrderDate 및 ShipDate 열은 Date 테이블의 Date 열과 관련이 있습니다. 이 모델에서 Date 테이블의 두 역할은 주문 날짜 및 배송 날짜 입니다. 활성 상태인 OrderDate 열과의 관계입니다.

6개의 측정값 중 하나를 제외한 모든 측정값은 OrderDate 열로 필터링해야 합니다. 그러나 Orders Shipped 측정값은 ShipDate 열을 통해 필터링해야 합니다.

다음은 Orders 측정값 정의입니다. 필터 컨텍스트 내에서 Sales 테이블의 행을 계산하기만 하면 됩니다. Date 테이블에 적용된 모든 필터가 OrderDate 열로 전파됩니다.

Orders = COUNTROWS(Sales)

다음은 Orders Shipped 측정값 정의입니다. 이 함수는 USERELATIONSHIP DAX 함수를 사용합니다. 이 함수는 특정 관계에 대한 필터 전파를 활성화하지만 식을 평가하는 동안에만 활성화됩니다. 이 예제에서는 ShipDate 열에 대한 관계가 사용됩니다.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

이 모델 디자인은 다음 보고서 디자인 생성을 지원합니다.

하나의 슬라이서와 테이블 시각적 개체가 있는 보고서 페이지를 보여 주는 다이어그램 슬라이서가 Quarter이고 테이블 시각적 개체에 월별 판매 통계가 나열됩니다.

보고서 페이지는 2019년 4분기으로 필터링합니다. 테이블은 월별로 그룹화하며 다양한 판매 통계를 보여줍니다. Orders 및 Orders Shipped 측정값은 서로 다른 결과를 생성합니다. 각각 동일한 요약 논리(Sales 테이블의 행 개수)를 사용하지만 Date 테이블 필터 전파가 다릅니다.

분기 슬라이서에는 BLANK 옵션이 포함되어 있습니다. 이 슬라이서 옵션은 테이블 확장결과로 나타납니다. 각 Sales 테이블 행에는 유효한 주문 날짜가 있지만 일부 행에는 BLANK 배송 날짜가 있습니다. 이러한 주문은 아직 배송되지 않았습니다. 테이블 확장은 비활성 관계도 고려하므로 관계의 다방면에 있는 BLANK(또는 데이터 무결성 문제)로 인해 BLANK가 나타날 수 있습니다.

메모

RLS(행 수준 보안) 필터는 활성 관계를 통해서만 전파됩니다. RLS 필터는 측정값 정의에서 USERELATIONSHIP DAX 함수를 사용하는 경우에도 비활성 관계에 전파되지 않습니다.

권장 사항

특히 데이터 모델에 대해 RLS 역할이 정의된 경우 가능하면 언제든지 활성 관계를 정의하는 것이 좋습니다. 보고서 작성자와 Q&A로 작업하는 사용자가 모델을 사용하는 방법의 범위와 잠재력을 확장합니다. 즉, 모델에서 롤플레잉 차원 테이블이 중복되어야 합니다.

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

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

관련 콘텐츠

이 문서와 관련된 자세한 내용은 다음 리소스를 확인하세요.