다 대 다 관계 지침

이 문서는 Power BI Desktop을 사용하는 데이터 모델러인 당신을 대상으로 하고 있습니다. 세 가지 다대다 모델링 시나리오에 대해 설명합니다. 또한 모델에서 그것들을 성공적으로 설계하는 방법에 대한 가이드를 제공합니다.

세 가지 다대다 시나리오가 있습니다. 다음을 수행해야 할 때 발생할 수 있습니다.

• 두 차원 테이블을 관련시키기
• 두 개의 팩트 테이블 관련
• 차원 테이블의 행보다 더 높은 세분성으로 팩트 테이블 행이 저장되는 경우,더 높은 세분성을 가진 팩트 테이블을 연계합니다.

다대다 차원 연결

고전적인 다대다 시나리오는 은행 고객과 은행 계좌 같은 두 엔터티의 관계를 설명합니다. 고객은 여러 계정을 가질 수 있고 계정에는 여러 고객이 있을 수 있습니다. 계정에 여러 고객이 있는 경우, 이들은 일반적으로 공동 계정 소유자 로 불립니다.

이러한 엔터티를 모델링하는 것은 간단합니다. 한 차원 테이블 계정을 저장하고 다른 차원 테이블은 고객을 저장합니다. 차원 테이블의 특성과 마찬가지로 각 테이블에는 고유 식별자(ID) 열이 있습니다. 두 테이블 간의 관계를 모델링하려면 세 번째 테이블이 필요합니다. 이 테이블은 일반적으로 브리징 테이블이라고 합니다. 이 예제에서는 각 고객 계정 연결에 대해 하나의 행을 저장하는 것이 목적입니다. 흥미롭게도 이 테이블에 식별자 열만 포함된 경우팩트 없는 팩트 테이블이라고 합니다.

다음은 세 가지 모델 테이블의 간단한 다이어그램입니다.

세 개의 모델 테이블을 보여 주는

첫 번째 테이블은 Account이름이 지정되며 AccountID 및 Account두 개의 열을 포함합니다. 두 번째 테이블은 AccountCustomer이름이 지정되며 AccountID 및 CustomerID두 개의 열을 포함합니다. 세 번째 테이블은 Customer이름이 지정되며 CustomerID 열과 Customer두 개의 열을 포함합니다. 테이블 사이에는 관계가 없습니다.

테이블을 연결하기 위해 두 개의 일대다 관계가 추가됩니다. 다음은 관련 테이블의 업데이트된 모델 다이어그램입니다. Transaction 명명된 팩트 테이블이 추가되었습니다. 계정 트랜잭션을 기록합니다. 브리징 테이블 및 모든 식별자 열이 숨겨져 있습니다.

관계 필터 전파의 작동 방식을 설명하기 위해 모델 다이어그램이 테이블 행을 표시하도록 수정되었습니다.

모델 테이블과 해당 행을 보여 주는

4개의 테이블에 대한 행 세부 정보는 다음 목록 형태로 제시됩니다.

• Account 테이블에는 두 개의 행이 있습니다.
  • AccountID 1 는 Account-01 에 해당합니다
  • AccountID 2는 Account-02용입니다.
• Customer 테이블에는 두 개의 행이 있습니다.
  • CustomerID 91는 Customer-91을 위한 것입니다
  • CustomerID 92는 Customer-92을/를 위한 것입니다.
• AccountCustomer 테이블에는 세 개의 행이 있습니다.
  • AccountID 1는 CustomerID91와 연관이 있습니다.
  • AccountID 1 는 CustomerID92 와 관련이 있다.
  • AccountID 2은 CustomerID92와 관련이 있습니다.
• Transaction 테이블에는 세 개의 행이 있습니다.
  • Date 2019년 1월 1일, AccountID1, Amount100
  • Date 2019년 2월 2일, AccountID2, Amount200
  • Date 2019년 3월 3일, AccountID1, Amount-25

모델을 쿼리할 때 어떤 일이 발생하는지 살펴보겠습니다.

다음 이미지에는 Transaction 테이블의 Amount 열을 요약하는 두 개의 테이블 시각화가 있습니다. 첫 번째 시각적 개체는 계정별로 그룹화되므로 Amount 열의 합계는 계정 잔액나타냅니다. 두 번째 비주얼은 고객별로 그룹화되므로 Amount 열의 합계는 고객 잔고나타냅니다.

첫 번째 테이블 시각적 개체(계정 잔액)에는 Account 및 Amount두 개의 열이 있습니다. 다음과 같은 결과가 표시됩니다.

• Account-01 잔액은 75.
• Account-02 잔액은 200.
• 총 275.

두 번째 테이블 시각적 개체(Customer Balance)에는 Customer 및 Amount두 개의 열이 있습니다. 다음과 같은 결과가 표시됩니다.

• Customer-91 잔액은 275.
• Customer-92 잔액 금액은 275입니다.
• 총 275.

테이블 행과 계정 잔액 시각화를 간단히 살펴보면, 각 계정 및 총 금액의 결과가 정확하다는 것을 확인할 수 있습니다. 각 계정 그룹화로 인해 해당 계정의 Transaction 테이블에 필터 전파가 발생하기 때문입니다.

그러나 Customer Balance 시각화에 무언가 잘못된 것 같습니다. 이 시각 자료 안의 각 고객은 총 잔액과 같은 잔액을 가지고 있습니다. 이 결과는 모든 고객이 모든 계정의 공동 계정 소유자인 경우에만 정확할 수 있습니다. 이 예제에서는 그렇지 않습니다. 문제가 있으며 필터 전파와 관련이 있습니다. 필터가 Transaction 테이블까지 완전히 전달되지 않고 있습니다.

Customer 테이블에서 Transaction 테이블로의 관계 필터 방향을 따르는 경우 Account 테이블과 AccountCustomer 테이블 간의 관계가 잘못된 방향으로 전파되고 있는지 확인할 수 있습니다. 이 관계의 필터 방향은 Both설정해야 합니다.

모델이 업데이트되었음을 보여 주는

두 개의 동일한 보고서 시각적 요소가 나란히 있는 다이어그램입니다. 첫 번째 시각적 요소는 변경되지 않았지만, 두 번째 시각적 요소는 변경되었습니다.

예상대로 계정 잔액의 시각화에는 변경이 없었습니다.

하지만 이제 고객 잔액 시각화에 다음 결과가 표시됩니다.

• Customer-91 잔액은 75.
• Customer-92 잔액 금액은275 .
• 총 275.

이제 고객 잔액 시각화에 올바른 결과가 표시됩니다. 직접 필터 지침을 따르고 고객 잔액을 계산하는 방법을 확인합니다. 또한, 시각적 합계는 모든 고객을 의미합니다.

모델 관계에 익숙하지 않은 사용자는 결과가 잘못되었다는 결론을 내릴 수 있습니다. 왜 Customer-91 및 Customer-92의 총 잔액이 350(75 + 275)과 같지 않은가요?

그들의 질문에 대한 답은 다대다 관계를 이해하는 데 있습니다. 각 고객 잔액은 여러 계정 잔액의 추가를 나타낼 수 있으므로 고객 잔액은 비가산적.

다대다 차원 관련 지침

차원 테이블 간에 다대다 관계가 있는 경우 다음 지침을 따르세요.

• 각 다대다 관련 엔터티를 모델 테이블로 추가한 후, ID 열이 있는지 확인하십시오.
• 연결된 엔터티를 저장할 브리징 테이블을 추가합니다.
• 세 테이블 간에 일대다 관계를 만듭니다.
• 하나의 양방향 관계를 설정하여 필터 전파가 팩트 테이블로 계속 진행되도록 합니다.
• 누락된 ID 값을 갖는 것이 적절하지 않은 경우 Is Nullable 속성을 사용하지 않도록 설정합니다. 누락된 값이 소스화되면 데이터 새로 고침이 실패합니다.
• 보고에 필요한 다른 열이나 측정값이 포함되지 않은 경우 브리징 테이블을 숨깁니다.
• 보고용으로 적합하지 않은 ID 열을 숨깁니다(예: 열이 대체 키 값을 저장하는 경우).
• ID 열을 표시 상태로 두어야 한다면, 그것이 관계의 "하나" 쪽에 있는지 확인하십시오. "다수" 쪽 열은 항상 숨기십시오. "one" 슬라이드에 적용된 필터로 인해 필터 성능이 향상되었기 때문입니다.
• 혼동이나 오해를 방지하기 위해 보고서 사용자에게 설명을 전달하십시오. 텍스트 상자를 사용하여 설명을 추가하거나 시각적 머리글의 도구 설명 또는을 추가할 수 있습니다.

다대다 차원 테이블을 직접 연결하지 않기를 권장합니다. 이 디자인 접근 방식을 사용하려면 다대다 카디널리티와의 관계를 설정해야 합니다. 개념적으로 달성할 수 있지만 관련 열에 중복 값이 포함될 수 있음을 의미합니다. 차원 테이블에는 ID 열이 있는 것이 잘 정립된 설계 관행입니다. 차원 테이블은 항상 ID 열을 관계의 "하나" 측면으로 사용해야 합니다.

다 대 다로 사실을 연결하기

서로 다른 유형의 다대다 시나리오에는 두 개의 팩트 테이블을 연결하는 것이 포함됩니다. 두 개의 팩트 테이블은 직접 관련될 수 있습니다. 이 디자인 기술은 빠르고 간단한 데이터 탐색에 유용할 수 있습니다. 그러나 명확히 하기 위해 일반적으로 이 디자인 접근 방식은 권장하지 않습니다. 이 섹션의 뒷부분에서 이유를 설명합니다.

Order 및 Fulfillment두 개의 팩트 테이블이 포함된 예제를 살펴보겠습니다. Order 테이블에는 주문 줄당 하나의 행이 포함되며 Fulfillment 테이블에는 주문 줄당 0개 이상의 행이 포함될 수 있습니다. Order 테이블의 행은 판매 주문을 나타냅니다. Fulfillment 테이블의 행은 배송된 주문 항목을 나타냅니다. 다 대 다 관계는 각 테이블의 OrderID 열과 관련이 있으며, Order 테이블에서만 필터 전파가 수행됩니다(Order 테이블이 Fulfillment 테이블을 필터링하는 것을 의미).

두 개의 테이블(주문 및 처리)을 포함하는 모델을 보여주는

관계 카디널리티는 두 테이블 모두에서 중복된 OrderID 열 값을 저장할 수 있도록 Many-to-many 으로 설정됩니다. Order 테이블에서는 순서에 여러 줄이 있을 수 있으므로 중복 ID 값이 있을 수 있습니다. Fulfillment 테이블에서는 주문에 여러 줄이 있을 수 있고 많은 배송에서 주문 줄을 처리할 수 있으므로 중복 ID 값이 존재할 수 있습니다.

이제 테이블의 행들을 살펴보겠습니다. Fulfillment 테이블에서는 여러 배송으로 주문 라인을 처리할 수 있습니다. (주문 라인이 없으면 주문이 아직 이행되지 않았습니다.)

모델 테이블 행을 보여 주는

두 테이블에 대한 행 세부 정보는 다음 글머리 기호 목록에 설명되어 있습니다.

• Order 테이블에는 5개의 행이 있습니다.
  • OrderDate 2019년 1월 1일, OrderID1, OrderLine1, ProductIDProd-A, OrderQuantity5, Sales50
  • OrderDate 2019년 1월 1일, OrderID1, OrderLine2, ProductIDProd-B, OrderQuantity10, Sales80
  • OrderDate 2019년 2월 2일, OrderID2, OrderLine1, ProductIDProd-B, OrderQuantity5, Sales40
  • OrderDate 2019년 2월 2일, OrderID2, OrderLine2, ProductIDProd-C, OrderQuantity1, Sales20
  • OrderDate 2019년 3월 3일, OrderID3, OrderLine1, ProductIDProd-C, OrderQuantity5, Sales100
• Fulfillment 테이블에는 4개의 행이 있습니다.
  • FulfillmentDate 2019년 1월 1일, FulfillmentID50, OrderID1, OrderLine1, FulfillmentQuantity2
  • FulfillmentDate 2019년 2월 2일, FulfillmentID51, OrderID2, OrderLine1, FulfillmentQuantity5
  • FulfillmentDate 2019년 2월 2일, FulfillmentID52, OrderID1, OrderLine1, FulfillmentQuantity3
  • FulfillmentDate 2019년 1월 1일, FulfillmentID53, OrderID1, OrderLine2, FulfillmentQuantity10

모델을 쿼리할 때 어떤 일이 발생하는지 살펴보겠습니다. 다음은 Order 테이블 OrderID 열을 사용하여 주문 및 처리 수량을 비교하는 표의 시각적 비교입니다.

테이블 시각적 개체를 보여 주는

시각 자료는 정확한 결과를 보여줍니다. 그러나 Order 테이블 OrderID 열로만 필터링하거나 그룹화할 수 있으므로 모델의 유용성은 제한적입니다.

다대다 관계에 대한 지침

일반적으로 다 대 다 카디널리티를 사용하여 두 팩트 테이블을 직접 연결하지 않는 것이 좋습니다. 주된 이유는 모델이 보고서 시각적 개체가 필터링 또는 그룹화되는 방식에서 유연성을 제공하지 않기 때문입니다. 이 예제에서는 Order 테이블 OrderID 열별로만 시각적 개체가 필터링하거나 그룹화할 수 있습니다. 또 다른 이유는 데이터의 품질과 관련이 있습니다. 데이터에 무결성 문제가 있는 경우, 다대일 카디널리티 및 로 제한된 관계때문에 쿼리 중 일부 행이 누락될 수 있습니다.

팩트 테이블을 직접 관련시키는 대신 별표 스키마 디자인을 구현하는 것이 좋습니다. 즉, 차원 테이블을 추가합니다. 그런 다음, 이러한 차원 테이블은 일대다 관계를 사용하여 팩트 테이블과 연관됩니다. 이 디자인 접근 방식은 유연한 보고 옵션을 효율적으로 제공하기 때문에 강력합니다. 차원 테이블 열을 사용하여 필터링하거나 그룹화하고 관련 팩트 테이블의 열을 요약할 수 있습니다.

더 나은 솔루션을 고려해 보겠습니다.

다이어그램

다음과 같은 디자인이 변경됩니다.

• 이제 모델에는 OrderLine, OrderDate, Product및 FulfillmentDate네 개의 추가 테이블이 있습니다.
• 추가된 4개의 테이블은 모두 일대다 관계를 통해 팩트 테이블과 관련된 차원 테이블들입니다.
• OrderLine 테이블에는 100을 곱한 OrderID 값을 저장하는 OrderLineID 열과 각 주문 줄의 ID인 OrderLine 열 값이 포함되어 있습니다.
• 이제 Order 및 Fulfillment 테이블에는 각각 OrderLineID 열이 포함되며 더 이상 OrderID 및 OrderLine 열이 포함되지 않습니다.
• 이제 Fulfillment 테이블에 OrderDate 및 ProductID 열이 포함됩니다.
• FulfillmentDate 테이블에는 Fulfillment 테이블에만 관계가 있습니다.
• 모든 ID 열이 숨겨져 있습니다.

스타 스키마 디자인을 채택하는 데 시간이 걸리면 다음과 같은 이점이 제공됩니다.

• 보고서 시각적 개체는 차원 테이블의 표시 열별로 필터링하거나 그룹화할 수 있습니다.
• 보고서 시각적 개체는 팩트 테이블에서 표시되는 열을 요약할 있습니다.
• OrderLine, OrderDate또는 Product 테이블에 적용된 필터가 두 팩트 테이블에 전파됩니다.
• 모든 관계는 다대일이며, 각 관계는 일반적인 관계입니다. 데이터 무결성 문제는 마스킹되지 않습니다. 관계 평가에 대한 자세한 내용은 Power BI Desktop모델 관계를 참조하세요.

더 많은 곡물 관련 정보

이 다대다 시나리오는 이 문서에 이미 설명된 다른 두 시나리오와 매우 다릅니다.

Date, Sales, Product및 Target네 개의 테이블을 포함하는 예제를 살펴보겠습니다. Date 및 Product 테이블은 차원 테이블이며 일대다 관계는 각각 Sales 팩트 테이블과 관련이 있습니다. 지금까지, 그것은 좋은 별 스키마 디자인을 나타냅니다. 그러나 Target 테이블은 아직 다른 테이블과 관련이 없습니다.

날짜, 판매, 제품 및 대상의 4개 테이블로 구성된 모델을 보여 주는

Target 테이블에는 Category, TargetQuantity및 TargetYear세 개의 열이 있습니다. 테이블 행은 연도 및 제품 범주의 세분성을 표시합니다. 즉, 판매 성과를 측정하는 데 사용되는 목표는 각 제품 범주에 대해 매년 설정됩니다.

판매 및 목표 팩트 테이블을 보여주는

Target 테이블은 차원 테이블보다 높은 수준에 데이터를 저장하므로 일대다 관계를 만들 수 없습니다. 글쎄, 그것은 관계 중 하나에 대한 사실이다. Target 테이블이 차원 테이블과 어떻게 관련될 수 있는지 살펴보겠습니다.

더 높은 곡물 기간 연결

Date 테이블과 Target 테이블 간의 관계는 일대다 관계여야 합니다. TargetYear 열 값이 날짜이기 때문입니다. 이 예제에서 각 TargetYear 열은 대상 연도의 첫 번째 날짜를 저장합니다.

그러나 월 또는 날짜 수준 필터가 의미 있는 결과를 생성하도록 주의해야 합니다. 특별한 계산 논리가 없으면 보고서의 시각적 요소에서 대상 날짜가 매년 첫날로 나타날 수 있습니다. 1월을 제외한 모든 다른 날과 월은 대상 수량을 BLANK로 요약합니다.

다음 행렬 시각화는 보고서 사용자가 연도에서 해당 월로 세부 항목으로 확대할 때 어떤 변화가 있는지를 보여 줍니다. 시각화 자료는 TargetQuantity 열을 요약합니다. (행렬 행에 대해 데이터 옵션이 없는 항목 표시를 사용하도록 설정했습니다.)

이 동작을 방지하려면 측정값을 사용하여 팩트 데이터의 요약을 제어하는 것이 좋습니다. 요약을 제어하는 한 가지 방법은 하위 수준 기간을 쿼리할 때 BLANK를 반환하는 것입니다. 일부 정교한 DAX로 정의된 다른 방식은 하위 수준의 시간 단위에 값을 분배하는 것입니다.

ISFILTERED DAX 함수를 사용하는 다음 측정값 정의를 고려합니다. Date 및 Month 열이 필터링되지 않은 경우에만 값을 반환합니다.

Target Quantity =
IF(
    NOT ISFILTERED('Date'[Date])
        && NOT ISFILTERED('Date'[Month]),
    SUM(Target[TargetQuantity])
)

다음은 Target Quantity 측정값을 사용하는 행렬 시각적 개체입니다. 모든 월별 목표 수량이 BLANK임을 보여 줍니다.

두 개의 행렬 시각화를 보여 주는

더 높은 곡물 관련(날짜가 아닌 경우)

차원 테이블의 날짜가 아닌 열을 팩트 테이블로 연결할 때(그리고 그 열이 차원 테이블보다 더 높은 세분성을 가질 경우) 다른 설계 접근 방식이 필요합니다.

Product 테이블과 Target 테이블 모두에서 Category 열에는 중복 값이 포함됩니다. 따라서 일대다 관계에 대한 "일" 측면은 없습니다. 이 경우 다대다 관계를 만들어야 합니다. 관계는 필터가 차원 테이블에서 팩트 테이블로 한 방향으로 전파되도록 해야 합니다.

대상 및 제품 테이블의 모델을 보여 주는

이제 테이블 행을 살펴보겠습니다.

대상과 제품이라는 두 개의 테이블이 포함된 모델을 보여주는

Target 표에는 각 목표 연도(2019년 및 2020년)의 행 2개와 범주 2개(의류 및 액세서리)의 4개 행이 있습니다. Product 표에는 세 가지 제품이 있습니다. 두 가지는 의류 범주에 속하며, 하나는 액세서리 범주에 속합니다. 의류 색 중 하나는 녹색이고 나머지 두 가지는 파란색입니다.

Product 테이블의 Category 열에서 테이블 시각적 그룹화를 수행하면 다음 결과가 생성됩니다. 그러나 이 시각 자료는 올바른 결과를 제공합니다. 이제 Product 테이블의 Color 열을 사용하여 대상 수량을 그룹화하면 어떻게 되는지 살펴보겠습니다.

두 가지 테이블 시각적 도표를 보여주는 다이어그램입니다. 첫 번째는 범주별로, 두 번째는 색상별로 그룹화됩니다. 두 번째 시각적 도표는 잘못된 결과를 생성합니다.

시각 자료는 데이터의 왜곡된 표현을 생성합니다. 여기서 무슨 일이 일어나고 있는가?

Product 테이블의 Color 열에 대한 필터는 두 개의 행을 생성합니다. 행 중 하나는 의류 범주이고 다른 하나는 액세서리 범주용입니다. 이러한 두 범주 값은 Target 테이블에 필터로 전파됩니다. 즉, 파란색은 두 범주의 제품에서 사용되기 때문에, 해당 범주가 대상을 필터링하는 데 사용됩니다.

앞에서 설명한 대로 이 동작을 방지하려면 측정값을 사용하여 팩트 데이터의 요약을 제어하는 것이 좋습니다.

다음 측정값 정의를 고려합니다. 범주 수준 아래에 있는 모든 Product 테이블 열이 필터에 대해 테스트됩니다.

Target Quantity =
IF(
    NOT ISFILTERED('Product'[ProductID])
        && NOT ISFILTERED('Product'[Product])
        && NOT ISFILTERED('Product'[Color]),
    SUM(Target[TargetQuantity])
)

다음 표 비주얼은 Target Quantity 측정값을 사용합니다. 모든 색 대상 수량이 BLANK임을 보여줍니다.

최종 모델 디자인은 다음과 같습니다.

고급 곡물 정보 지침 관련

차원 테이블과 팩트 테이블을 연결해야 할 때, 팩트 테이블이 차원 테이블 행보다 높은 세분성으로 데이터를 저장하는 경우에는 다음 지침을 따르세요.

• 더 높은 곡물 관련 날짜
  • 팩트 테이블에서 기간의 첫 번째 날짜를 저장합니다.
  • 날짜 테이블과 팩트 테이블 간에 일대다 관계를 만듭니다.
• 다른 고급 곡물 정보
  • 차원 테이블과 팩트 테이블 간에 다대다 관계를 만듭니다.
• 두 형식 모두
  • '측정 논리'로 요약을 제어하고, 하위 수준 차원 열을 필터링하거나 그룹화할 때에는 BLANK를 반환합니다.
  • 팩트 테이블을 요약하는 데 측정값만 사용할 수 있도록 요약 가능한 팩트 테이블 열을 숨깁니다.

관련 콘텐츠

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

• Power BI Desktop에서 모델 관계
• 별표 스키마와 Power BI의 중요성 이해
• 관계 문제 해결 지침
• 질문? 패브릭 커뮤니티에 질문해 보세요.
• 제안? 패브릭 개선하기 위한 아이디어 제안하기