Power BI Desktop에서 관계 만들기 및 관리
테이블이 여러 개 있을 때 이러한 모든 테이블의 데이터를 사용하여 분석을 수행하려는 경우가 있습니다. 결과를 정확하게 계산하고 보고서에 올바른 정보를 표시하려면 이 테이블 간의 관계가 필요합니다. 대부분의 경우 어떠한 작업도 수행할 필요가 없습니다. 자동 검색 기능은 자동으로 수행됩니다. 그러나 관계를 직접 만들거나 관계를 변경해야 하는 경우도 있습니다. 어떤 경우든지 Power BI Desktop에서의 관계 및 관계를 만들고 편집하는 방법을 이해하는 것이 중요합니다.
로드하는 동안 자동 검색
둘 이상의 테이블을 동시에 쿼리하는 경우 데이터가 로드될 때 Power BI Desktop에서 자동으로 관계를 찾고 만들려고 합니다. 관계 옵션 카디널리티, 교차 필터 방향 및 이 관계를 활성으로 만들기가 자동으로 설정됩니다. Power BI Desktop은 쿼리하는 테이블의 열 이름을 보고 잠재적 관계가 있는지를 확인합니다. 관계가 있는 경우 자동으로 생성됩니다. Power BI Desktop이 높은 수준의 신뢰도로 일치하는 항목을 확인할 수 없을 경우 관계를 만들지 않습니다. 그러나 여전히 관계 관리 대화 상자를 사용하여 직접 관계를 만들거나 편집할 수 있습니다.
자동 검색으로 관계 만들기
모델링 탭에서 관계 관리>자동 검색을 선택합니다.
수동으로 관계 만들기
모델링 탭에서 관계 관리>새로 만들기를 선택합니다.
관계 만들기 대화 상자의 첫 번째 테이블 드롭다운 목록에서 테이블을 선택합니다. 관계에서 사용할 열을 선택합니다.
두 번째 테이블 드롭다운 목록에서 관계에 사용할 다른 테이블을 선택합니다. 사용할 다른 열을 선택한 다음, 확인을 선택합니다.
기본적으로 Power BI Desktop이 새 관계에 대한 카디널리티(방향), 교차 필터 방향 및 이 관계를 활성으로 만들기 옵션을 자동으로 구성합니다. 그러나 필요한 경우 해당 설정을 변경할 수 있습니다. 자세한 내용은 추가 옵션 이해를 확인하세요.
관계에 대해 선택된 테이블에 고유한 값이 없는 경우 열 중 하나가 고유한 값을 가져야 합니다라는 오류가 표시됩니다. 관계에 있는 테이블 중 적어도 하나에는 모든 관계형 데이터베이스 기술에 대한 공통 요구 사항인 고유한 키 값 목록이 있어야 합니다.
해당 오류가 발생하면 이를 해결할 수 있는 몇 가지 방법이 있습니다.
- 중복 제거를 사용하여 고유한 값을 가진 열을 만듭니다. 이 방법의 단점은 중복 행이 제거될 때 정보도 손실될 수 있다는 것이며, 이 때문에 키(행)가 복제되기도 합니다.
- 별개의 키 값 목록으로 만들어진 중간 테이블을 모델에 추가하면 관계의 원래 두 열 모두에 연결됩니다.
자세한 내용은 이 블로그 게시물 보기를 참조하십시오.
또는 모델 보기 다이어그램 레이아웃에서 한 테이블의 열을 다른 테이블의 열로 끌어서 놓아 관계를 생성할 수 있습니다.
관계 편집
Power BI에서 관계를 편집하는 방법은 두 가지가 있습니다.
관계를 편집하는 첫 번째 방법은 모델 보기의 속성에서 관계 편집 창을 사용하는 것입니다. 여기서 두 테이블 사이의 선을 선택하여 속성 창에서 관계 옵션을 볼 수 있습니다. 관계 옵션을 보려면 속성 창을 확장해야 합니다.
속성 창에서는 관계 편집에 대한 비디오 데모도 볼 수 있습니다.
관계를 편집하는 다른 방법은 관계 편집기 대화 상자를 사용하는 것입니다. 이 대화 상자는 Power BI Desktop 내에서 여러 방법으로 열 수 있습니다. 다음 목록은 관계 편집기 대화 상자를 여는 여러 방법을 보여 줍니다.
보고서 보기에서 다음 중 하나를 수행합니다.
- 모델링 리본 >관계 관리를 선택한 다음, 관계, 수정을 차례로 선택합니다.
- 필드 목록에서 테이블을 선택한 후 테이블 도구 리본 >관계 관리를 선택하고 관계를 선택한 다음, 편집을 선택합니다.
데이터 보기에서 테이블 도구 리본 >관계 관리를 선택한 다음, 관계, 편집을 선택합니다.
모델 보기에서 다음 중 하나를 수행합니다.
- 홈 리본 >관계 관리를 선택한 후 관계를 선택한 다음, 편집을 선택합니다.
- 두 테이블 사이의 선을 두 번 클릭합니다.
- 두 테이블 사이의 선을 마우스 오른쪽 단추로 클릭한 다음, 속성을 선택합니다.
- 두 테이블 사이의 선을 선택한 다음 속성 창에서 관계 편집기 열기를 선택합니다.
마지막으로 보기에서 관계를 편집할 수도 있습니다. 마우스 오른쪽 단추를 클릭하거나 줄임표를 선택하여 테이블의 상황에 맞는 메뉴로 이동한 후 관계 관리를 선택하고 관계, 편집을 차례로 선택합니다.
다음 이미지는 관계 편집 창의 스크린샷을 보여 줍니다.
다른 방법을 사용하여 관계 편집
관계 편집 대화 상자를 사용하면 Power BI에서 관계를 편집할 수 있으며 현재 미리 보기로 제공됩니다. 각 테이블에서 데이터의 미리 보기를 볼 수 있습니다. 다른 열을 선택하면 창에서 자동으로 관계의 유효성을 검사하고 적절한 카디널리티 및 교차 필터 선택 항목을 제공합니다.
속성 창에서 관계를 편집하는 것은 Power BI에서 관계를 편집하는 간소화된 접근 방식입니다. 선택할 수 있는 테이블 이름과 열만 표시됩니다. 데이터 미리 보기는 표시되지 않으며 선택한 관계는 변경 내용 적용을 선택한 유효성이 검사됩니다. 속성 창과 간소화된 접근 방식을 사용하면 관계를 편집할 때 생성되는 쿼리 수가 줄어듭니다. 이는 특히 DirectQuery 연결을 사용할 때 빅 데이터 시나리오에 중요할 수 있습니다. 속성 창을 사용하여 만든 관계는 관계 편집 대화 상자에서 만들 수 있는 관계보다 더 지능형일 수도 있습니다.
Ctrl 키를 누르고 둘 이상의 선을 선택하여 여러 관계를 선택하면 모델 보기 다이어그램 레이아웃에서 관계를 다중 선택할 수도 있습니다. 공통 속성은 속성 창에서 편집할 수 있으며 변경 내용 적용을 수행하면 하나의 트랜잭션에서 변경 내용이 처리됩니다.
키보드에서 삭제를 눌러 단일 또는 다중 선택 관계를 삭제할 수도 있습니다. 삭제 작업은 실행 취소할 수 없으므로 대화 상자에 관계 삭제를 확인하는 메시지가 표시됩니다.
Important
속성 창 기능의 관계 편집은 현재 미리 보기로 제공됩니다. 미리 보기 단계에서는 기능 및 설명서가 변경될 수 있습니다. 파일 > 옵션 및 설정 > 옵션 > 미리 보기 기능으로 이동한 후 GLOBAL 섹션에서 관계 창 옆의 확인란을 선택하여 Power BI Desktop에서 이 기능을 사용하도록 설정해야 합니다.
추가 옵션 구성
관계를 만들거나 편집할 때 추가 옵션을 구성할 수 있습니다. 기본적으로 Power BI Desktop은 가장 적합한 추측을 기반으로 자동으로 추가 옵션을 구성합니다. 이러한 옵션은 열의 데이터를 기반으로 하는 각 관계마다 다를 수 있습니다.
카디널리티
카디널리티 옵션은 다음 설정 중 하나를 사용할 수 있습니다.
다대일(*:1): 다대일 관계는 관계의 가장 일반적인 기본 형식입니다. 이는 특정 테이블의 열은 둘 이상의 값 인스턴스를 가질 수 있고, 다른 관련 테이블(조회 테이블이라고도 함)은 하나의 값 인스턴스만 가질 수 있음을 의미합니다.
일 대 일(1:1): 일 대 일 관계에서는 한 테이블의 열과 다른 관련 테이블이 하나의 특정 값 인스턴스만 가질 수 있음을 의미합니다.
일 대 다(1:*): 일 대 다 관계에서 한 테이블의 열은 특정 값의 인스턴스를 하나만 가질 수 있고, 다른 관련 테이블은 값의 인스턴스를 하나 이상 가질 수 있음을 의미합니다.
다대다(*:*): 복합 모델을 사용하여 테이블 간에 다 대 다 관계를 설정할 수 있습니다. 그러면 테이블의 고유한 값에 대한 요구 사항이 제거됩니다. 또한 관계 설정 목적으로만 새 테이블을 도입하는 것과 같은 이전 해결 방법도 제거됩니다. 자세한 내용은 다 대 다 카디널리티와의 관계를 참조하세요.
카디널리티를 변경하는 시점에 대한 자세한 내용은 추가 옵션 이해를 참조하세요.
교차 필터 방향
교차 필터 방향 옵션은 다음 설정 중 하나를 가질 수 있습니다.
양쪽: 필터링 용도로 두 테이블이 모두 단일 테이블인 것처럼 처리됨을 의미합니다. 모두 설정은 주위에 조회 테이블이 많은 단일 테이블에서 잘 작동합니다. 부서에 대한 조회 테이블이 있는 판매 실적 테이블을 예로 들 수 있습니다. 이 구성을 종종 별모양 스키마 구성(여러 조회 테이블이 있는 중앙 테이블)이라고 합니다. 그러나 조회 테이블이 있는(일부 공통) 테이블이 여럿인 경우 양쪽 설정을 사용하지 않는 게 나을 것입니다. 앞의 예에서 각 부서에 대한 목표 예산을 기록하는 판매 예산 테이블도 있다고 가정해 보겠습니다. 또한 부서 테이블은 판매와 예산에 모두 연결되어 있습니다. 이러한 유형의 구성에서는 양쪽 설정을 사용하지 않습니다.
단일: 가장 일반적인 기본 방향으로, 값이 집계되는 테이블에 연결된 테이블의 필터링 선택 항목이 적용됨을 의미합니다. Excel 2013 이전 버전의 데이터 모델에서 파워 피벗을 가져오는 경우 모든 관계가 단일 방향을 갖습니다.
교차 필터 방향 변경 시점에 대한 자세한 내용은 추가 옵션 이해를 참조하세요.
이 관계를 활성으로 만들기
이 옵션을 선택하면 관계가 활성 기본 관계로 사용됩니다. 두 테이블 간에 두 개 이상의 관계가 있는 경우 활성 관계를 통해 Power BI Desktop이 두 테이블을 포함하는 시각화 요소를 자동으로 만들 수 있습니다.
특정 관계 활성화 시점에 대한 자세한 내용은 추가 옵션 이해를 참조하세요.
관계 이해
두 테이블을 관계로 연결하면 두 테이블이 단일 테이블인 것처럼 두 테이블의 데이터로 작업할 수 있습니다. 그러면 관계 세부 정보에 대해 걱정하지 않아도 되며 테이블을 가져오기 전에 해당 테이블을 단일 테이블로 평면화할 필요가 없습니다. 대부분의 경우 Power BI Desktop은 자동으로 관계를 만들 수 있습니다. 그러나 Power BI Desktop은 두 테이블 간의 관계가 존재해야 하는 상황에서 불확실성이 높아 관계를 결정하지 못할 경우 자동으로 관계를 만듭니다. 이 경우에는 그렇게 해야 합니다.
Power BI Desktop에서 관계가 작동하는 방식을 이해하는 데 도움이 되도록 간단한 자습서를 살펴보겠습니다.
팁
이 단원은 직접 완료할 수 있습니다.
- 다음 ProjectHours 테이블을 Excel 워크시트(제목 제외)에 복사하고 모든 셀을 선택한 다음, 삽입>테이블을 선택합니다.
- 테이블 만들기 대화 상자에서 확인을 선택합니다.
- 테이블 셀을 선택하고 테이블 디자인>테이블 이름을 선택한 다음, ProjectHours를 입력합니다.
- CompanyProject 테이블에 대해 동일한 작업을 수행합니다.
- 그런 다음 Power BI Desktop에서 데이터 가져오기를 사용하여 데이터를 가져옵니다. 두 테이블을 데이터 원본으로 선택한 다음 로드를 선택합니다.
첫 번째 테이블인 ProjectHours는 개인이 특정 프로젝트에서 작업한 시간 수를 기록하는 작업 티켓 레코드입니다.
ProjectHours
| Ticket | SubmittedBy | Hours | 프로젝트 | DateSubmit |
|---|---|---|---|---|
| 1001 | Brewer, Alan | 22 | 파랑 | 1/1/2013 |
| 1002 | Brewer, Alan | 26 | 빨강 | 2/1/2013 |
| 1003 | Ito, Shu | 34 | 노란색 | 12/4/2012 |
| 1004 | Brewer, Alan | 13 | Orange | 2012/1/2 |
| 1005 | Bowen, Eli | 29 | 자주색 | 2013/10/1 |
| 1006 | Bento, Nuno | 35 | 녹색 | 2/1/2013 |
| 1007 | Hamilton, David | 10 | 노란색 | 2013/10/1 |
| 1008 | Han, Mu | 28 | Orange | 2012/1/2 |
| 1009 | Ito, Shu | 22 | 자주색 | 2/1/2013 |
| 1010 | Bowen, Eli | 28 | 녹색 | 2013/10/1 |
| 1011 | Bowen, Eli | 9 | 파랑 | 10/15/2013 |
두 번째 테이블인 CompanyProject는 A, B 또는 C 우선 순위가 할당된 프로젝트 목록입니다.
CompanyProject
| ProjName | 우선 순위 |
|---|---|
| 파랑 | A |
| 빨간색 | b |
| 녹색 | C |
| 노란색 | C |
| 자주색 | b |
| Orange | C |
각 테이블에는 프로젝트 열이 있습니다. 각각의 이름은 약간씩 다르게 지정되나 값은 동일하게 보입니다. 이는 중요한 사항이므로 잠시 후 다시 살펴보겠습니다.
이제 두 테이블을 모델로 가져왔으므로 보고서를 만들어 보겠습니다. 먼저 프로젝트 우선 순위별로 제출된 시간 수를 확인하려고 하므로 필드 창에서 우선 순위 및 시간을 선택합니다.
보고서 캔버스에서 테이블을 보면 각 프로젝트에 대한 시간이 총 256시간으로 표시되는 것을 알 수 있습니다. 분명히 이 숫자는 잘못되었습니다. 그 이유는 이는 두 테이블 간의 관계가 없으면 다른 테이블의 값(CompanyProject 테이블의 Priority)으로 분리된 한 테이블의 값(Project 테이블의 Hours)에 대한 합계를 계산할 수 없기 때문입니다.
따라서 이러한 두 테이블 간에 관계를 만들겠습니다.
열에서 두 테이블에 모두 프로젝트 이름이 있지만 값은 비슷해 보였습니다. 이러한 두 열을 사용하여 테이블 간의 관계를 만들겠습니다.
이러한 열을 사용하는 이유는 무엇일까요? ProjectHours 테이블의 Project 열을 보면 Blue, Red, Yellow, Orange 등의 값이 표시됩니다. 실제로 동일한 값을 가진 여러 행이 표시됩니다. 프로젝트에 대한 많은 색상 값이 있습니다.
CompanyProject 테이블의 ProjName 열에는 프로젝트 이름의 각 색상 값이 하나밖에 없습니다. 이 테이블의 각 색상 값은 고유하며, 이러한 두 테이블 간에 관계를 만들 수 있기 때문에 이는 중요합니다. 이 경우 다대일 관계입니다. 다대일 관계에서는 테이블 중 하나에 고유한 값을 가진 열이 하나 이상 있어야 합니다. 일부 관계에 대한 몇 가지 추가 옵션이 있습니다. 이에 대해서는 나중에 살펴보겠습니다. 지금은 두 테이블 각각의 프로젝트 열 사이에 관계를 만들어보겠습니다.
새 관계를 만들려면
모델링 탭에서 관계 관리를 선택합니다.
관계 관리에서 새로 만들기를 선택하여 관계 만들기 대화 상자를 엽니다. 이 대화 상자에서 관계에 사용할 테이블, 열 및 기타 설정을 선택할 수 있습니다.
첫 번째 드롭다운 목록에서 첫 번째 테이블로 ProjectHours를 선택한 다음 프로젝트 열을 선택합니다. 이 측면은 관계의 다 측면입니다.
두 번째 드롭다운 목록에서 CompanyProject가 두 번째 테이블로 미리 선택됩니다. ProjName 열을 선택합니다. 이 측면은 관계의 일 측면입니다.
관계 옵션의 기본값을 그대로 승인한 다음 확인을 선택합니다.
관계 관리 대화 상자에서 닫기를 선택합니다.
자세한 설명을 위해 지금은 이 관계를 어려운 방법으로 만들었습니다. 관계 관리 대화 상자에서 자동 검색을 선택할 수 있습니다. 사실 두 열의 이름이 같은 경우 데이터를 로드할 때 자동 검색은 자동으로 관계를 만들었습니다.
이제 보고서 캔버스에서 다시 테이블을 살펴보겠습니다.
이제 훨씬 좋아 보이지 않나요?
Priority를 기준으로 시간 합계를 계산하는 경우, Power BI Desktop은 CompanyProject 조회 테이블에서 고유한 색상 값의 모든 인스턴스를 찾고 ProjectHours 테이블에서 각 값의 모든 인스턴스를 찾은 다음 각 고유한 값의 합계를 계산합니다.
자동 검색을 사용하면 이러한 작업조차 필요하지 않을 수 있습니다.
추가 옵션 이해
자동 검색을 통해 관계가 생성되거나 수동으로 관계를 만들면 Power BI Desktop이 테이블의 데이터를 기반으로 하여 추가 옵션을 자동으로 구성합니다. 해당 추가 관계 옵션은 관계 만들기 및 관계 편집 대화 상자의 아래쪽 부분에 있습니다.
Power BI는 일반적으로 이러한 옵션을 자동으로 설정하므로 조정할 필요가 없습니다. 그러나 해당 옵션을 직접 구성해야 하는 몇 가지 경우가 있습니다.
자동 관계 업데이트
Power BI에서 보고서와 모델의 관계를 처리하고 자동으로 조정하는 방법을 관리할 수 있습니다. Power BI에서 관계 옵션을 처리하는 방법을 지정하려면 Power BI Desktop에서 파일>옵션 및 설정>옵션을 선택한 다음 왼쪽 창에서 데이터 로드를 선택합니다. 관계에 대한 옵션이 표시됩니다.
세 가지 옵션을 선택하고 사용할 수 있습니다.
처음 로드 시 데이터 원본에서 관계 가져오기: 이 옵션은 기본적으로 선택됩니다. 이를 선택하면 Power BI에서 데이터 웨어하우스의 외래 키/기본 키 관계와 같이 데이터 원본에 정의된 관계를 확인합니다. 이러한 관계가 있는 경우 처음에 데이터를 로드할 때 Power BI 데이터 모델로 미러됩니다. 이 옵션을 사용하면 사용자가 직접 관계를 찾거나 정의하지 않아도 모델 작업을 신속하게 시작할 수 있습니다.
데이터를 새로 고칠 때 관계 업데이트 또는 삭제: 이 옵션은 기본적으로 선택되어 있지 않습니다. 이 옵션을 선택하면 Power BI가 의미 체계 모델을 새로 고칠 때 데이터 원본 관계의 변경 내용을 확인합니다. 이러한 관계가 변경되거나 제거되는 경우 Power BI는 자체 데이터 모델에서 변경 내용을 미러링하거나, 해당 변경 내용을 업데이트 또는 삭제하여 일치시킵니다.
Warning
정의된 관계에 의존하는 행 수준 보안을 사용하는 경우 이 옵션을 선택하지 않는 것이 좋습니다. RLS 설정이 의존하는 관계를 제거하면 모델의 보안이 저하될 수 있습니다.
데이터가 로드된 후 새 관계 자동 검색: 이 옵션은 로드하는 동안 자동 검색에 설명되어 있습니다.
이후에 데이터를 업데이트하려면 다른 카디널리티가 필요합니다.
일반적으로 Power BI Desktop은 관계에 대한 최상의 카디널리티를 자동으로 결정할 수 있습니다. 데이터가 나중에 변경될 것을 알고 있으므로 자동 설정을 재정의해야 하는 경우 카디널리티 컨트롤에서 변경할 수 있습니다. 다른 카디널리티를 선택해야 하는 예를 살펴보겠습니다.
CompanyProjectPriority 테이블은 모든 회사 프로젝트 목록과 해당 우선 순위입니다. ProjectBudget 테이블은 예산이 승인된 프로젝트 집합입니다.
CompanyProjectPriority
| ProjName | 우선 순위 |
|---|---|
| 파랑 | A |
| 빨간색 | b |
| 녹색 | C |
| 노란색 | C |
| 자주색 | b |
| Orange | C |
ProjectBudget
| Approved Projects | BudgetAllocation | AllocationDate |
|---|---|---|
| 파랑 | 40,000 | 12/1/2012 |
| 빨강 | 100,000 | 12/1/2012 |
| 녹색 | 50,000 | 12/1/2012 |
ProjectBudget 테이블의 승인된 프로젝트 열과 CompanyProjectPriority 테이블의 ProjectName 열 사이에 관계를 만드는 경우, Power BI가 자동으로 카디널리티를 일 대 다(1:1) 및 교차 필터 방향양쪽으로 설정합니다.
Power BI가 해당 설정을 만드는 이유는 Power BI Desktop에서 두 테이블의 최적 조합이 다음과 같기 때문입니다.
| ProjName | 우선 순위 | BudgetAllocation | AllocationDate |
|---|---|---|---|
| 파랑 | A | 40,000 | 12/1/2012 |
| 빨간색 | b | 100,000 | 12/1/2012 |
| 녹색 | C | 50,000 | 12/1/2012 |
| 노란색 | C | ||
| 자주색 | b | ||
| Orange | C |
결합된 테이블의 ProjName 열에 반복 값이 없기 때문에 두 테이블 간에 일대일 관계가 있습니다. ProjName 열은 각 값이 한 번씩만 나타나므로 고유하며, 따라서 두 테이블의 행을 중복 없이 직접 결합할 수 있습니다.
그러나 다음에 새로 고칠 때 데이터가 변경되는 것을 알고 있다고 가정해 보세요. 이제 새로 고친 버전의 ProjectBudget 테이블에 Blue와 Red 프로젝트에 대한 추가 행이 있습니다.
ProjectBudget
| Approved Projects | BudgetAllocation | AllocationDate |
|---|---|---|
| 파랑 | 40,000 | 12/1/2012 |
| 빨강 | 100,000 | 12/1/2012 |
| 녹색 | 50,000 | 12/1/2012 |
| 파랑 | 80,000 | 2013/6/1 |
| 빨강 | 90,000 | 2013/6/1 |
이러한 추가 행은 두 테이블의 최적 조합이 이제 다음과 같이 표시됨을 의미합니다.
| ProjName | 우선 순위 | BudgetAllocation | AllocationDate |
|---|---|---|---|
| 파랑 | A | 40,000 | 12/1/2012 |
| 빨간색 | b | 100,000 | 12/1/2012 |
| 녹색 | C | 50,000 | 12/1/2012 |
| 노란색 | C | ||
| 자주색 | b | ||
| Orange | C | ||
| 파랑 | A | 80000 | 2013/6/1 |
| 빨간색 | b | 90000 | 2013/6/1 |
새로 결합된 테이블의 ProjName 열에는 반복 값이 있습니다. 테이블을 새로 고치고 나면 원래의 두 테이블 간에 일대일 관계가 없습니다. 이 경우 이후의 업데이트로 인해 ProjName 열에 중복 항목이 포함될 것을 알고 있으므로 ProjectBudget 쪽을 다로 지정하고 CompanyProjectPriority 쪽을 일로 지정하여 카디널리티를 다대일(*:1)로 설정하려고 합니다.
복잡한 테이블 및 관계 집합에 대해 교차 필터 방향 조정
대부분의 관계에 대해 교차 필터 방향은 양쪽으로 설정됩니다. 그러나 이 옵션을 기본값과 다르게 설정해야 하는 좀 더 일반적이지 않은 경우가 있습니다. 한 가지 예는 모든 관계가 단일 방향으로 설정되는 이전 버전의 Power Pivot에서 모델을 가져오는 경우입니다.
양쪽 설정을 사용하면 Power BI Desktop이 연결된 테이블의 모든 측면을 단일 테이블처럼 처리할 수 있습니다. 그러나 Power BI Desktop이 관계의 교차 필터 방향을 양쪽으로 설정할 수 없고 보고 용도로 명확한 기본값 집합도 사용할 수 있도록 유지해야 하는 경우가 있습니다. 관계 교차 필터 방향을 양쪽으로 설정하지 않는 경우는 보통 모호해지기 때문입니다. 기본 교차 필터 설정이 적합하지 않은 경우 특정 테이블 방향이나 양쪽으로 설정할 수 있습니다.
단일 방향 교차 필터링은 대부분의 상황에서 작동합니다. 실제로 Excel 2013 또는 그 이전 버전의 파워 피벗에서 모델을 가져온 경우 모든 관계가 단일 방향으로 설정됩니다. 단일 방향은 집계 작업이 발생하는 테이블에 연결된 테이블의 필터링 선택 항목이 적용됨을 의미합니다. 때로는 교차 필터링 이해가 약간 어려울 수 있으므로 예를 살펴보겠습니다.
단일 방향 교차 필터링을 사용하여 프로젝트 시간을 요약하는 보고서를 만드는 경우 CompanyProject 테이블과 해당 우선 순위 열 또는 CompanyEmployee 테이블과 해당 City 열을 요약(또는 필터링)하도록 선택할 수 있습니다. 그러나 (덜 일반적인 질문이기는 하지만) 프로젝트당 직원 수를 계산하려는 경우에는 작동하지 않습니다. 모두 동일한 값을 가진 열이 생성됩니다. 다음 예제에서는 관계 교차 필터링 방향이 둘 다 단일 방향(ProjectHours 테이블 방향)으로 설정됩니다. 값 웰에서 프로젝트 필드는 개수로 설정됩니다.
필터 지정은 CompanyProject에서 ProjectHours로 진행되지만(다음 이미지 참조) CompanyEmployee까지 진행되지는 않습니다.
그러나 교차 필터링 방향을 양쪽으로 설정하면 작동합니다. 양쪽으로 설정하면 필터 지정이 CompanyEmployee까지 진행될 수 있습니다.
교차 필터링 방향을 양쪽으로 설정하면 이제 보고서가 올바르게 표시됩니다.
양방향 교차 필터링은 이전에 표시된 패턴과 같은 테이블 관계 패턴에 적합합니다. 이 스키마는 일반적으로 다음과 같이 별모양 스키마라고 합니다.
교차 필터링 방향은 다음 다이어그램과 같이 데이터베이스에서 자주 발견되는 보다 일반적인 패턴에서는 제대로 작동하지 않습니다.
루프와 함께 이러한 테이블 패턴이 있는 경우 교차 필터링에서 모호한 관계 집합을 만들 수 있습니다. 예를 들어 테이블 X에서 필드 합계를 계산한 다음 테이블 Y의 필드를 기준으로 필터링하도록 선택하는 경우 필터가 상단 테이블을 통해 진행되어야 하는지 또는 하단 테이블을 통해 진행되어야 하는지 명확하지 않습니다. 이러한 패턴의 일반적인 예로 판매 실적 데이터가 있는 판매 테이블인 테이블 X와 예산 데이터가 될 테이블 Y를 들 수 있습니다. 그러면 가운데 테이블이 부서, 지역 등 두 테이블이 사용할 조회 테이블이 됩니다.
활성/비활성 관계와 마찬가지로 Power BI Desktop은 보고서에 모호성을 유발하는 경우 관계를 양쪽으로 설정할 수 없습니다. 이 상황을 처리할 수 있는 몇 가지 방법이 있습니다. 가장 일반적인 두 가지는 다음과 같습니다.
- 모호성을 줄이기 위해 관계를 삭제하거나 비활성으로 표시합니다. 그런 다음 관계 교차 필터링을 양쪽으로 설정할 수 있습니다.
- 테이블을 두 번 가져와(두 번째는 다른 이름으로) 루프를 제거합니다. 이렇게 하면 관계 패턴이 별모양 스키마와 비슷해집니다. 별모양 스키마를 사용할 경우 모든 관계를 양쪽으로 설정할 수 있습니다.
잘못된 활성 관계
Power BI Desktop이 자동으로 관계를 만들 때 두 테이블 간에 둘 이상의 관계를 발견하는 경우도 있습니다. 해당 상황이 발생하는 경우 관계 중 하나만 활성으로 설정됩니다. 활성 관계는 서로 다른 두 테이블에서 필드를 선택할 때 Power BI Desktop이 자동으로 시각화를 만들 수 있도록 기본 관계 역할을 합니다. 그러나 자동으로 선택된 관계가 잘못된 경우도 있습니다. 관계 관리 대화 상자를 사용하여 관계를 활성 또는 비활성으로 설정하거나, 관계 편집 대화 상자에서 활성 관계를 설정합니다.
기본 관계가 있도록 하기 위해 Power BI Desktop은 지정된 시간에 두 테이블 간에 하나의 활성 관계만 허용합니다. 따라서 먼저 현재 관계를 비활성으로 설정한 다음 활성화할 관계를 설정해야 합니다.
예를 들어 살펴보겠습니다. 이 첫 번째 테이블은 ProjectTickets이고 두 번째 테이블은 EmployeeRole입니다.
ProjectTickets
| Ticket | OpenedBy | SubmittedBy | Hours | 프로젝트 | DateSubmit |
|---|---|---|---|---|---|
| 1001 | Perham, Tom | Brewer, Alan | 22 | 파랑 | 1/1/2013 |
| 1002 | Roman, Daniel | Brewer, Alan | 26 | 빨강 | 2/1/2013 |
| 1003 | Roth, Daniel | Ito, Shu | 34 | 노란색 | 12/4/2012 |
| 1004 | Perham, Tom | Brewer, Alan | 13 | Orange | 2012/1/2 |
| 1005 | Roman, Daniel | Bowen, Eli | 29 | 자주색 | 2013/10/1 |
| 1006 | Roth, Daniel | Bento, Nuno | 35 | 녹색 | 2/1/2013 |
| 1007 | Roth, Daniel | Hamilton, David | 10 | 노란색 | 2013/10/1 |
| 1008 | Perham, Tom | Han, Mu | 28 | Orange | 2012/1/2 |
| 1009 | Roman, Daniel | Ito, Shu | 22 | 자주색 | 2/1/2013 |
| 1010 | Roth, Daniel | Bowen, Eli | 28 | 녹색 | 2013/10/1 |
| 1011 | Perham, Tom | Bowen, Eli | 9 | 파랑 | 10/15/2013 |
EmployeeRole
| 직원 | 역할 |
|---|---|
| Bento, Nuno | Project Manager |
| Bowen, Eli | 프로젝트 리드 |
| Brewer, Alan | Project Manager |
| Hamilton, David | 프로젝트 리드 |
| Han, Mu | 프로젝트 리드 |
| Ito, Shu | 프로젝트 리드 |
| Perham, Tom | Project Sponsor |
| Roman, Daniel | Project Sponsor |
| Roth, Daniel | Project Sponsor |
실제로 여기에는 두 개의 관계가 있습니다.
- EmployeeRole 테이블의 Employee과 ProjectTickets 테이블의 SubmittedBy 사이입니다.
- ProjectTickets 테이블의 OpenedBy와 EmployeeRole 테이블의 Employee 사이입니다.
두 관계를 모두 모델에 추가하면(먼저 OpenedBy 추가) 관계 관리 대화 상자에 OpenedBy가 활성 상태로 표시됩니다.
이제 보고서 캔버스의 테이블 시각화에 EmployeeRole의 Role 및 Employee 필드와 ProjectTickets의 Hours 필드를 사용하는 보고서를 만들면 프로젝트 스폰서만 표시되는 데 이것은 이들만이 프로젝트 티켓을 열었기 때문입니다.
활성 관계를 변경하여 OpenedBy 대신 SubmittedBy를 가져올 수 있습니다. 관계 관리에서 ProjectTickets(OpenedBy)와 EmployeeRole(Employee) 간의 관계를 선택 취소한 다음 EmployeeRole(Employee)과 Project Tickets(SubmittedBy) 간의 관계를 선택합니다.
관계 보기의 모든 관계 참조
경우에 따라 모델에 여러 테이블이 있고 테이블 간의 관계가 복잡할 수 있습니다. Power BI Desktop의 관계 보기는 모델의 모든 관계, 방향 및 카디널리티를 이해하기 쉽고 사용자 지정할 수 있는 다이어그램으로 보여 줍니다.
자세한 내용은 Power BI Desktop의 관계 보기와 작업을 참조하세요.
문제 해결
이 섹션에서는 Power BI에서 관계로 작업할 때 지침 및 문제 해결 정보를 제공합니다.
필드 간의 관계를 확인할 수 없음
Power BI는 사용 중인 모델의 관계를 유추하여 시각적 개체에 관련 데이터를 표시하려고 합니다. 경우에 따라 이러한 유추가 명확하지 않으며 시각적 개체에서 특정 열 간에 관계가 없음을 나타내는 오류가 표시될 수 있습니다.
Power BI에서 필드가 관련되어 있는지 여부를 결정하는 방법을 설명하기 위해 예제 모델을 사용하여 다음 섹션의 몇 가지 시나리오를 설명하겠습니다. 다음 이미지는 예제 시나리오에서 사용할 샘플 모델을 보여 줍니다.
시나리오 1: 기존의 별모양 스키마와 측정값 제약 조건이 제공되지 않았습니다. 이전 이미지의 샘플 모델을 참조하여 공급업체 - 구매 - 제품 테이블을 사용하여 이미지의 오른쪽 절반을 먼저 살펴보겠습니다. 이 예제는 팩트 테이블(구매) 및 2차원 테이블(제품 및 공급업체)이 있는 기존의 별모양 스키마입니다. 차원 테이블과 팩트 테이블 간 관계는 일대다입니다(한 제품은 많은 구매에 대응되고 한 공급업체는 많은 구매에 대응됨). 이 유형의 스키마에서는 X 제품의 판매액은 얼마나 되나요? 및 공급업체 Y의 판매액은 얼마나 되나요? 및 공급업체 Y가 판매하는 제품은 무엇인가요?와 같은 질문에 답변할 수 있습니다.
제품 및 공급업체의 상관 관계를 확인하려는 경우 구매 테이블을 확인하여 동일한 제품 및 공급업체가 있는 항목이 있는지 검토하면 됩니다. 샘플 쿼리는 다음 예제와 같을 수 있습니다.
Correlate Product[Color] with Vendor[Name] where CountRows(Purchases)>0
where CountRows(Purchases)>0는 관련 데이터가 반환되도록 Power BI가 추가하는 암시적 제약 조건입니다.
구매 테이블을 통해 이 상관 관계를 수행하면 팩트 테이블에 하나 이상의 항목이 있는 제품-공급업체 쌍을 반환할 수 있습니다. 이 쌍은 데이터 관점에서 의미가 있습니다. 판매가 한 번도 발생하지 않은(분석에 도움이 되지 않음) 제품-공급업체의 부적합한 조합은 표시되지 않을 것으로 예상할 수 있습니다.
시나리오 2: 기존 별모양 스키마 및 측정값 제약 조건이 제공되었습니다. 시나리오 1의 이전 예제에서 사용자가 요약 열 형식(예: Sum/Average/Count of Purchase Qty) 또는 모델 측정값(Distinct Count of VendID) 형식으로 제약 조건을 제공하는 경우 Power BI 다음 예제 형식으로 쿼리를 생성할 수 있습니다.
Correlate Product[Color] with Vendor[Name] where MeasureConstraint is not blank
이러한 경우 Power BI는 사용자가 제공한 제약 조건에 대해 의미 있는 값이 있는 조합을 반환하려고 합니다(공백 아님). Power BI는 사용자가 제공한 제약 조건이 충분하기 때문에 이전 시나리오 1에서 수행한 것과 같이 CountRows(Purchases)>0의 자체 암시적 제약 조건도 추가할 필요가 없습니다.
시나리오 3: 별모양이 아닌 스키마와 측정값 제약 조건이 제공되지 않았습니다. 이 시나리오에서는 판매 - 제품 - 구매 테이블이 있는 모델의 중심에 집중합니다. 여기서는 1차원 테이블(제품) 및 두 개의 팩트 테이블(판매, 구매)이 있습니다. 이 예제는 별모양 스키마가 아니므로 시나리오 1에서와 동일한 종류의 질문에 대답할 수 없습니다. 구매 및 판매의 상관 관계를 파악해 보겠습니다. 구매는 제품과 다대일 관계이고, 제품은 판매와 일대다 관계입니다. 판매 및 구매는 간접적으로 다대다 관계입니다. 하나의 제품을 여러 구매에 연결하고 하나의 제품을 많은 판매에 연결할 수 있지만 하나의 판매를 여러 구매에 연결할 수 없으며 그 반대의 경우도 마찬가지입니다. 많은 구매는 많은 판매에만 연결할 수 있습니다.
이 경우 시각적 개체에서 Purchase[VenID] 및 Sales[CustID]를 결합하려고 하면 Power BI는 테이블 간의 다대다 관계로 인해 적용할 수 있는 구체적인 제약 조건이 없습니다. 다양한 시나리오에 적용할 수 있는 사용자 지정 제약 조건(반드시 모델에서 설정된 관계에서 시작될 필요는 없음)이 있을 수 있지만 Power BI는 관계만을 기준으로 기본 제약 조건을 유추할 수는 없습니다. Power BI는 두 테이블의 모든 조합을 반환하려고 하면 큰 크로스 조인을 만들고 관련 없는 데이터를 반환합니다. 이 대신 Power BI는 다음과 같이 시각적 개체에서 오류를 발생시킵니다.
시나리오 4: 별모양이 아닌 스키마 및 측정값 제약 조건이 제공되었습니다. 시나리오 3의 예제를 가져와 요약된 열(예: Count of Product[ProdID]) 또는 모델 측정값(Sales[Total Qty]) 형식으로 사용자 제공 제약 조건을 추가하는 경우 Power BI는 MeasureConstraint가 비어 있지 않은 Correlate Purchase[VenID] 및 Sales[CustID] 형식으로 쿼리를 생성할 수 있습니다.
이 경우 Power BI는 사용자의 제약 조건을 적용해야 Power BI 유일한 제약 조건으로 간주하고, 비어 있지 않은 값을 생성하는 조합을 반환합니다. 사용자는 Power BI를 원하는 시나리오로 유도했으며 Power BI는 지침을 적용합니다.
시나리오 5: 측정값 제약 조건이 제공되지만 열과 부분적으로 관련되어 있습니다. 사용자가 제공한 측정값 제약 조건이 시각적 개체의 모든 열과 완전히 관련되지는 않은 경우가 있습니다. 모델 측정값은 항상 모든 항목과 관련이 있습니다. Power BI는 이 시나리오에서 시각적 개체에서 열 간의 관계를 찾으려고 할 때 블랙 박스로 처리하고 사용자가 이를 통해 수행하는 작업을 알고 있다고 가정합니다. 그러나 Sum, Average 형식의 요약 열 및 사용자 인터페이스에서 선택한 유사한 요약은 해당 열이 속한 테이블의 관계를 기준으로 시각적 개체에서 사용되는 열/테이블의 하위 집합과만 관련될 수 있습니다. 따라서 제약 조건은 일부 열 쌍에 적용되지만 모든 열에 적용되지는 않습니다. 이 경우 Power BI는 사용자가 제공한 제약 조건과 관련되지 않은 열에 적용할 수 있는 기본 제약 조건을 찾으려고 시도합니다(예: 시나리오 1). Power BI에서 어떤 제약 조건도 찾을 수 없는 경우 다음 오류가 반환됩니다.
관계 오류 해결
필드 간 관계를 확인할 수 없습니다. 오류가 표시되면 다음 단계를 수행하여 오류를 해결할 수 있습니다.
모델을 확인합니다. 분석에서 답변하려는 질문 유형에 맞게 적절하게 설정되어 있나요? 테이블 간 관계 중 일부를 변경할 수 있나요? 간접 다대다를 만들지 않도록 할 수 있나요?
V를 뒤집은 셰이프 스키마를 두 테이블로 변환하고 Power BI Desktop에서 다 대 다 관계 적용에 설명한 대로 테이블 간에 직접 다대다 관계를 사용하는 것이 좋습니다.
요약 열 또는 모델 측정값의 형태로 시각적 개체에 제약 조건을 추가합니다.
요약된 열이 추가되고 여전히 오류가 있는 경우 모델 측정값을 사용하는 것이 좋습니다.
관련 콘텐츠
모델 및 관계에 대한 자세한 내용은 다음 문서를 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기