활성 및 비활성 관계 지침Active vs inactive relationship guidance

이 문서는 Power BI Desktop을 개발하는 데이터 모델러를 대상으로 합니다.This article targets you as a data modeler working with Power BI Desktop. 언제 활성 또는 비활성 모델 관계를 만들지에 대한 지침을 제공합니다.It provides you with guidance on when to create active or inactive model relationships. 기본적으로 활성 관계는 필터를 다른 테이블에 전파합니다.By default, active relationships propagate filters to other tables. 그러나 비활성 관계는 DAX 식이 관계를 활성화(사용)하는 경우에만 필터를 전파합니다.Inactive relationship, however, only propagate filters when a DAX expression activates (uses) the relationship.

참고

이 문서에서 모델 관계를 소개하지는 않습니다.An introduction to model relationships is not covered in this article. 관계, 해당 속성 또는 관계를 구성하는 방법을 잘 모르겠으면 먼저 Power BI Desktop의 모델 관계 문서를 읽어보시는 것이 좋습니다.If you're not completely familiar with relationships, their properties or how to configure them, we recommend that you first read the Model relationships in Power BI Desktop article.

별모양 스키마 디자인을 살펴보는 것도 중요합니다.It's also important that you have an understanding of star schema design. 자세한 내용은 별모양 스키마 및 Power BI에서의 중요도 이해를 참조하세요.For more information, see Understand star schema and the importance for Power BI.

활성 관계Active relationships

일반적으로 가능한 경우 항상 활성 관계를 정의하는 것이 좋습니다.Generally, we recommend defining active relationships whenever possible. 이들은 보고서 작성자가 모델을 사용하고 사용자가 질문 및 답변을 사용하는 범위와 가능성을 확장합니다.They widen the scope and potential of how your model can be used by report authors, and users working with Q&A.

항공사 비행 정시성(OTP)을 분석하도록 디자인된 가져오기 모델의 예를 살펴보겠습니다.Consider an example of an Import model designed to analyze airline flight on-time performance (OTP). 이 모델에는 비행편당 하나의 행을 저장하는 팩트 유형 테이블인 Flight 테이블이 있습니다.The model has a Flight table, which is a fact-type table storing one row per flight. 각 행은 비행 날짜, 비행 번호, 출발 및 도착 공항, 지연 시간(분)을 기록합니다.Each row records the flight date, flight number, departure and arrival airports, and any delay time (in minutes). 공항마다 하나의 행을 저장하는 차원 유형 테이블인 Airport 테이블도 있습니다.There's also an Airport table, which is a dimension-type table storing one row per airport. 각 행은 공항 코드, 공항 이름 및 국가를 설명합니다.Each row describes the airport code, airport name, and the country.

다음은 두 테이블의 부분 모델 다이어그램입니다.Here's a partial model diagram of the two tables.

테이블 두 개가 포함된 모델을 보여 주는 다이어그램: Flight와 Airport라는 2개의 테이블이 포함되어 있습니다.

Flight 테이블과 Airport 테이블 사이에는 두 가지 모델 관계가 있습니다.There are two model relationships between the Flight and Airport tables. Flight 테이블에서 DepartureAirportArrivalAirport 열은 Airport 테이블의 Airport 열과 연결되어 있습니다.In the Flight table, the DepartureAirport and ArrivalAirport columns relate to the Airport column of the Airport table. 별모양 스키마 디자인에서 Airport 테이블은 롤플레잉 차원으로 설명됩니다.In star schema design, the Airport table is described as a role-playing dimension. 이 모델에서 두 역할은 출발 공항 및 _도착 공항_입니다.In this model, the two roles are departure airport and arrival airport.

이 디자인은 관계형 별모양 스키마 디자인에 적합하지만 Power BI 모델에는 적합하지 않습니다.While this design works well for relational star schema designs, it doesn't for Power BI models. 모델 관계는 필터 전파를 위한 경로이고 이러한 경로는 결정적이어야 하기 때문입니다.It's because model relationships are paths for filter propagation, and these paths must be deterministic. 그래서 한 모델이 두 테이블 간에 여러 활성 관계를 가질 수 없는 것입니다.For this reason, a model cannot have multiple active relationships between two tables. 따라서 이 예제에서 설명한 것처럼 한 관계는 활성 상태이고 다른 관계는 비활성 상태(파선으로 표시)입니다.Therefore—as described in this example—one relationship is active while the other is inactive (represented by the dashed line). 구체적으로 ArrivalAirport 열과의 관계가 활성 상태입니다.Specifically, it's the relationship to the ArrivalAirport column that's active. Airport 테이블에 적용된 필터가 Flight 테이블의 ArrivalAirport 열에 자동으로 전파됩니다.This means filters applied to the Airport table automatically propagate to the ArrivalAirport column of the Flight table.

이 모델 디자인은 데이터를 보고할 수 있는 방법에 심각한 제한을 가져옵니다.This model design imposes severe limitations on how the data can be reported. 특히 Airport 테이블을 필터링하여 출발 공항의 비행편 세부 정보를 자동으로 격리할 수 없습니다.Specifically, it's not possible to filter the Airport table to automatically isolate flight details for a departure airport. 보고 요구 사항에 따라 출발 및 도착 공항을 동시에 필터링(또는 그룹화)해야 하므로 두 개의 활성 관계가 필요합니다.As reporting requirements involve filtering (or grouping) by departure and arrival airports at the same time, two active relationships are needed. 이 요구 사항을 Power BI 모델 디자인으로 변환하는 것은 모델에 공항 테이블이 두 개 있어야 함을 의미합니다.Translating this requirement into a Power BI model design means the model must have two airport tables.

향상된 모델 디자인은 다음과 같습니다.Here's the improved model design.

테이블 네 개가 포함된 모델을 보여 주는 다이어그램: Date, Flight, Departure Airport 및 Arrival Airport가 포함되어 있습니다.

이제 모델에는 두 개의 공항 테이블 Departure AirportArrival Airport가 있습니다.The model now has two airport tables: Departure Airport and Arrival Airport. 이러한 테이블과 Flight 테이블 간의 모델 관계가 활성화됩니다.The model relationships between these tables and the Flight table are active. 또한 Departure AirportArrival Airport 테이블의 열 이름 앞에는 Departure 또는 _Arrival_이라는 접두사가 붙습니다.Notice also that the column names in the Departure Airport and Arrival Airport tables are prefixed with the word Departure or Arrival.

이 향상된 모델 디자인에서 다음과 같은 보고서 디자인을 만들 수 있습니다.The improved model design supports producing the following report design.

보고서 페이지에 두 개의 슬라이서와 하나의 테이블 시각적 개체가 있음을 보여 주는 다이어그램.

보고서 페이지는 멜버른을 출발 공항으로 필터링하고 도착 공항을 기준으로 테이블 시각적 개체 그룹을 필터링합니다.The report page filters by Melbourne as the departure airport, and the table visual groups by arrival airports.

참고

가져오기 모델의 경우 추가 테이블의 모델 크기가 증가하고 새로 고침 시간이 길어집니다.For Import models, the additional table has resulted in an increased model size, and longer refresh times. 이는 가져오기 모델링을 위한 데이터 축소 방법 문서에 설명된 권장 사항과 모순됩니다.As such, it contradicts the recommendations described in the Data reduction techniques for Import modeling article. 그러나 이 예제에서는 활성 관계만 있어야 한다는 요구 사항이 이러한 권장 사항을 재정의합니다.However, in the example, the requirement to have only active relationships overrides these recommendations.

또한 차원 유형 테이블에는 팩트 유형 테이블보다 적은 행 수가 포함되는 것이 일반적입니다.Further, it's common that dimension-type tables contain low row counts relative to fact-type table row counts. 따라서 증가된 모델 크기와 새로 고침 시간이 과도하게 커질 가능성이 없습니다.So, the increased model size and refresh times aren't likely to be excessively large.

리팩터링 방법Refactoring methodology

다음은 단일 롤플레잉 차원 유형 테이블에서 _역할당 하나의 테이블을 사용_하는 디자인으로 모델을 리팩터링하는 방법입니다.Here's a methodology to refactor a model from a single role-playing dimension-type table, to a design with one table per role.

  1. 비활성 관계를 모두 제거합니다.Remove any inactive relationships.

  2. 롤플레잉 차원 유형 테이블의 이름을 해당 역할을 보다 잘 설명하도록 변경하는 것이 좋습니다.Consider renaming the role-playing dimension-type table to better describe its role. 이 예제에서 Airport 테이블이 Flight 테이블의 ArrivalAirport 열과 연결되어 있으므로 이름이 Arrival Airport로 바뀝니다.In the example, the Airport table is related to the ArrivalAirport column of the Flight table, so it's renamed as Arrival Airport.

  3. 롤플레잉 테이블의 복사본을 만들고 해당 역할을 반영하는 이름을 지정합니다.Create a copy of the role-playing table, providing it with a name that reflects its role. 가져오기 테이블인 경우 계산된 테이블을 정의하는 것이 좋습니다.If it's an Import table, we recommend defining a calculated table. DirectQuery 테이블인 경우 파워 쿼리 쿼리를 복제할 수 있습니다.If it's a DirectQuery table, you can duplicate the Power Query query.

    이 예제에서는 다음 계산된 테이블 정의를 사용하여 Departure Airport 테이블을 만들었습니다.In the example, the Departure Airport table was created by using the following calculated table definition.

    Departure Airport = 'Arrival Airport'
    
  4. 새 테이블과 연결되는 활성 관계를 만듭니다.Create an active relationship to relate the new table.

  5. 테이블이 해당 역할을 정확하게 반영하도록 테이블의 열 이름을 변경하는 것이 좋습니다.Consider renaming the columns in the tables so they accurately reflect their role. 이 예제에서 모든 열에는 Departure 또는 _Arrival_이라는 접두사가 붙습니다.In the example, all columns are prefixed with the word Departure or Arrival. 이러한 이름을 통해 보고서 시각적 개체에 기본적으로 자체 설명적이고 모호하지 않은 레이블이 포함됩니다.These names ensure report visuals, by default, will have self-describing and non-ambiguous labels. 또한 질문 및 답변 환경을 개선하여 사용자가 질문을 쉽게 작성할 수 있습니다.It also improves the Q&A experience, allowing users to easily write their questions.

  6. 롤플레잉 테이블에 설명을 추가하는 것이 좋습니다.Consider adding descriptions to role-playing tables. (필드 창에서 보고서 작성자가 테이블 위에 커서를 올려 놓으면 도구 설명에 설명이 표시됩니다.) 이러한 방식으로 모든 추가 필터 전파 세부 정보를 보고서 작성자에게 전달할 수 있습니다.(In the Fields pane, a description appears in a tooltip when a report author hovers their cursor over the table.) This way, you can communicate any additional filter propagation details to your report authors.

비활성 관계Inactive relationships

특정 상황에서 비활성 관계는 특별한 보고 요구 사항을 해결할 수 있습니다.In specific circumstances, inactive relationships can address special reporting needs.

이제 다른 모델 및 보고 요구 사항을 살펴보겠습니다.Let's now consider different model and reporting requirements:

  • 한 판매 모델에 Sales 테이블이 포함되어 있으며, 이 테이블에는 두 개의 날짜 열 OrderDateShipDate가 있습니다.A sales model contains a Sales table that has two date columns: OrderDate and ShipDate
  • Sales 테이블의 각 행은 단일 주문을 기록합니다.Each row in the Sales table records a single order
  • 날짜 필터는 항상 유효한 날짜를 저장하는 OrderDate 열에 적용됩니다.Date filters are almost always applied to the OrderDate column, which always stores a valid date
  • 하나의 측정값에만 ShipDate 열에 대한 날짜 필터 전파가 필요합니다. 이 열에는 (주문이 배송될 때까지) BLANK를 포함할 수 있습니다.Only one measure requires date filter propagation to the ShipDate column, which can contain BLANKs (until the order is shipped)
  • 주문 배송 날짜 기간을 동시에 필터링(또는 그룹화)할 필요는 없습니다.There's no requirement to simultaneously filter (or group by) order and ship date periods

다음은 두 테이블의 부분 모델 다이어그램입니다.Here's a partial model diagram of the two tables.

테이블 두 개가 포함된 모델을 보여 주는 다이어그램: Sales와 Date라는 2개의 테이블이 포함되어 있습니다.

Sales 테이블과 Date 테이블 사이에는 두 가지 모델 관계가 있습니다.There are two model relationships between the Sales and Date tables. Sales 테이블에서 OrderDateShipDate 열은 Date 테이블의 Date 열과 관련이 있습니다.In the Sales table, the OrderDate and ShipDate columns relate to the Date column of the Date table. 이 모델에서 Date 테이블에 대한 두 역할은 주문 날짜 및 _배송 날짜_입니다.In this model, the two roles for the Date table are order date and ship date. OrderDate 열과의 관계가 활성 상태입니다.It's the relationship to the OrderDate column that's active.

여섯 개 측정값은 하나를 제외하고 모두 OrderDate 열을 기준으로 필터링해야 합니다.All of the six measures—except one—must filter by the OrderDate column. 그러나 Orders Shipped 측정값은 ShipDate 열을 기준으로 필터링해야 합니다.The Orders Shipped measure, however, must filter by the ShipDate column.

Orders 측정값의 정의는 다음과 같습니다.Here's the Orders measure definition. 필터 컨텍스트 내에서 Sales 테이블의 행 수만 계산합니다.It simply counts the rows of the Sales table within the filter context. Date 테이블에 적용된 모든 필터는 OrderDate 열로 전파됩니다.Any filters applied to the Date table will propagate to the OrderDate column.

Orders = COUNTROWS(Sales)

Orders Shipped 측정값의 정의는 다음과 같습니다.Here's the Orders Shipped measure definition. USERELATIONSHIP DAX 함수를 사용합니다. 이 함수는 식을 계산하는 동안에만 특정 관계에 대한 필터 전파를 활성화합니다.It uses the USERELATIONSHIP DAX function, which activates filter propagation for a specific relationship only during the evaluation of the expression. 이 예제에서는 ShipDate 열과의 관계가 사용됩니다.In this example, the relationship to the ShipDate column is used.

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

이 모델 디자인에서 다음과 같은 보고서 디자인을 만들 수 있습니다.This model design supports producing the following report design.

하나의 슬라이서와 테이블 시각적 개체가 있는 보고서 페이지를 보여 주는 다이어그램.

보고서 페이지는 분기 2019 Q4를 기준으로 필터링됩니다.The report page filters by quarter 2019 Q4. 테이블 시각적 개체는 월별로 그룹화되고 테이블에 다양한 판매 통계가 표시됩니다.The table visual groups by month and displays various sales statistics. Orders 측정값과 Orders Shipped 측정값은 서로 다른 결과를 생성합니다.The Orders and Orders Shipped measures produce different results. 각 측정값은 동일한 요약 논리(Sales 테이블의 행 수)를 사용하지만 Date 테이블 필터 전파는 서로 다릅니다.They each use the same summarization logic (count rows of the Sales table), but different Date table filter propagation.

분기 슬라이서에는 BLANK 항목이 포함되어 있습니다.Notice that the quarter slicer includes a BLANK item. 이 슬라이서 항목은 테이블 확장의 결과로 표시됩니다.This slicer item appears as a result of table expansion. Sales 테이블 행에는 주문 날짜가 있지만 일부 행에는 BLANK 배송 날짜가 있습니다. 이러한 주문은 아직 배송되지 않은 것입니다.While each Sales table row has an order date, some rows have a BLANK ship date—these orders are yet to be shipped. 테이블 확장은 비활성 관계도 고려하므로 BLANK가 관계의 다 쪽에 있는 BLANK 또는 데이터 무결성 문제로 인해 나타날 수 있습니다.Table expansion considers inactive relationships too, and so BLANKs can appear due to BLANKs on the many-side of the relationship, or due to data integrity issues.

권장 사항Recommendations

요약하자면 가능하면 항상 활성 관계를 정의하는 것이 좋습니다.In summary, we recommend defining active relationships whenever possible. 이들은 보고서 작성자가 모델을 사용하고 사용자가 질문 및 답변을 사용하는 범위와 가능성을 확장합니다.They widen the scope and potential of how your model can be used by report authors, and users working with Q&A. 즉, 모델에서 롤플레잉 차원 유형 테이블을 복제해야 함을 의미합니다.It means that role-playing dimension-type tables should be duplicated in your model.

그러나 특정 상황에서는 롤플레잉 차원 유형 테이블에 대해 하나 이상의 비활성 관계를 정의할 수 있습니다.In specific circumstances, however, you can define one or more inactive relationships for a role-playing dimension-type table. 다음과 같은 경우 이 디자인을 고려할 수 있습니다.You can consider this design when:

  • 보고서 시각적 개체에서 여러 역할로 동시에 필터링할 필요가 없는 경우There's no requirement for report visuals to simultaneously filter by different roles
  • USERELATIONSHIP DAX 함수를 사용하여 관련 모델 계산에 대한 특정 관계를 활성화하는 경우You use the USERELATIONSHIP DAX function to activate a specific relationship for relevant model calculations

다음 단계Next steps

이 문서와 관련된 보다 자세한 내용을 알아보려면 다음 리소스를 참조하세요.For more information related to this article, check out the following resources: