별모양 스키마 및 Power BI에서의 중요성 이해
이 문서는 Power BI Desktop 데이터 모델러를 대상으로 합니다. 스타 스키마 디자인과 성능 및 유용성에 최적화된 Power BI 의미 체계 모델 개발과 관련된 관련성을 설명합니다.
Important
Power BI 의미 체계 모델은 데이터를 가져오거나 연결하기 위해 파워 쿼리에 따라 달라집니다. 즉, 파워 쿼리를 사용하여 원본 데이터를 변환하고 준비해야 합니다. 이는 데이터 볼륨이 크거나 느린 변경 차원과 같은 고급 개념을 구현해야 할 때 어려울 수 있습니다(이 문서의 뒷부분에서 설명).
이러한 과제가 제시되면 먼저 데이터 웨어하우스를 개발하고 ETL(추출, 변환 및 로드) 프로세스를 개발하여 데이터 웨어하우스를 주기적으로 로드하는 것이 좋습니다. 그러면 의미 체계 모델이 데이터 웨어하우스에 연결할 수 있습니다. 자세한 내용은 Microsoft Fabric Warehouse의 차원 모델링을 참조하세요.
팁
이 문서는 별모양 스키마 디자인을 자세히 설명하기 위한 것이 아닙니다. 자세한 내용은 Ralph Kimball의 Data Warehouse 도구 키트: 차원 모델링에 대한 결정적 가이드(2013년 3판)와 같은 널리 출판된 콘텐츠를 직접 참조하세요.
별모양 스키마 개요
별모양 스키마는 관계형 데이터 웨어하우스에서 널리 채택되는 안정적인 모델링 방법입니다. 이 방법을 사용하려면 모델러가 모델 테이블을 차원 또는 팩트로 분류해야 합니다.
- 차원 테이블은 모델링 대상인 비즈니스 엔터티를 설명합니다. 엔터티에는 제품, 사람, 장소, 시간 자체를 포함하는 개념 등이 있습니다. 별모양 스키마에서 가장 일관된 테이블은 날짜 차원 테이블입니다. 차원 테이블에는 고유 식별자 역할을 하는 키 열(또는 열) 및 기타 열이 포함됩니다. 다른 열은 데이터 필터링 및 그룹화가 지원됩니다.
- 팩트 테이블 은 관찰 또는 이벤트를 저장하며 판매 주문, 주식 잔액, 환율, 온도 등이 될 수 있습니다. 팩트 테이블은 차원 테이블과 관련된 차원 키 열 및 숫자 측정값 열을 포함합니다. 차원 키 열은 팩트 테이블의 차원을 결정하는 반면, 차원 키 값은 팩트 테이블의 세분성을 결정합니다. 예를 들어 2차원 키 열과
ProductKey2차원 키 열이 있는 판매 대상을 저장하도록 디자인된 팩트 테이블을 고려합니다Date. 테이블에 두 개의 차원이 있음을 쉽게 파악할 수 있습니다. 하지만 차원 키 값을 고려하지 않으면 세분성을 확인할 수 없습니다. 이 예제에서는 열에 저장된 값이Date매월 첫째 날임을 고려합니다. 이 경우 세분성은 월-제품 수준입니다.
일반적으로 차원 테이블의 행 수는 비교적 적습니다. 반면 팩트 테이블은 많은 수의 행을 포함할 수 있으며 시간이 지남에 따라 계속 증가할 수 있습니다.
정규화 및 비정상화
이 문서에서 설명하는 몇 가지 별모양 스키마 개념을 이해하려면 정규화와 비정상화라는 두 가지 용어를 알아야 합니다.
정규화는 반복적인 데이터를 줄이는 방식으로 저장되는 데이터를 설명하는 데 사용되는 용어입니다. 제품 키와 같은 고유한 키 값 열이 있는 제품 테이블과 제품 이름, 범주, 색 및 크기와 같은 제품 특성을 설명하는 다른 열을 고려합니다. 판매 테이블은 제품 키와 같은 키만 저장하는 경우 정규화된 것으로 간주됩니다. 다음 이미지에서는 열만 ProductKey 제품을 기록합니다.
그러나 판매 테이블이 키 외에 제품 세부 정보를 저장하는 경우 비정규화 상태로 간주됩니다. 다음 이미지에서는 제품 및 기타 제품 관련 열이 제품을 기록하는 것을 확인 ProductKey 합니다.
내보내기 파일 또는 데이터 추출에서 데이터를 소싱하는 경우 비정규화된 데이터 세트를 나타낼 가능성이 높습니다. 이 경우 파워 쿼리 사용하여 원본 데이터를 정규화된 여러 테이블로 변환하고 셰이핑합니다.
이 문서에서 설명한 대로 정규화된 팩트 및 차원 데이터를 나타내는 테이블을 사용하여 최적화된 Power BI 의미 체계 모델을 개발하기 위해 노력해야 합니다. 그러나 단일 모델 테이블을 생성하기 위해 눈송이 차원이 비정규화될 수 있는 한 가지 예외가 있습니다.
Power BI 의미 체계 모델과 별모양 스키마 관련성
별모양 스키마 디자인 및 이 문서에 소개된 많은 관련 개념은 성능과 유용성에 최적화된 Power BI 모델 개발과 관련성이 높습니다.
각 Power BI 보고서 시각적 개체는 Power BI 의미 체계 모델로 전송되는 쿼리를 생성합니다. 일반적으로 쿼리는 모델 데이터를 필터링, 그룹화 및 요약합니다. 따라서 잘 디자인된 모델은 필터링 및 그룹화에 사용할 테이블과 요약에 사용할 테이블을 제공하는 모델입니다. 이 디자인은 별모양 스키마 원칙에 잘 맞습니다.
- 차원 테이블을 사용하면 필터링 및 그룹화가 가능합니다.
- 팩트 테이블은 요약을 사용하도록 설정합니다.
모델러가 테이블 형식을 차원 또는 팩트로 설정하도록 설정하는 테이블 속성이 없습니다. 실제로 모델 관계에 따라 결정됩니다. 모델 관계는 두 테이블 간에 필터 전파 경로를 설정하고 테이블 형식을 결정하는 관계의 카디널리티 속성입니다. 일반적인 관계 카디널리티는 일 대 다 또는 역으로 다 대 일입니다. "일" 쪽은 항상 차원 테이블이고 "다" 쪽은 항상 팩트 테이블입니다.
잘 구성된 모델 디자인에는 차원 테이블 또는 팩트 테이블인 테이블이 포함됩니다. 단일 테이블에서 두 가지 유형을 함께 사용하지 마세요. 또한 적절한 관계가 있는 적절한 수의 테이블을 제공하기 위해 노력하는 것이 좋습니다. 팩트 테이블은 항상 일관된 조직으로 데이터를 로드하는 것이 중요합니다.
마지막으로, 최적 모델 디자인은 과학과 예술의 결합임을 이해하는 것이 중요합니다. 타당한 이유가 있을 때는 권장 지침대로 하지 않아도 됩니다.
Power BI 의미 체계 모델에 적용할 수 있는 별모양 스키마 디자인과 관련된 많은 개념이 있습니다. 이러한 개념은 다음과 같습니다.
측정값 그룹
별모양 스키마 디자인에서 측정값은 요약할 값을 저장하는 팩트 테이블 열입니다. Power BI 의미 체계 모델에서 측정값의 정의는 다르지만 유사합니다. 모델은 명시적 측정값과 암시적 측정값을 모두 지원합니다.
- 명시적 측정값은 명시적으로 생성되며 요약을 달성하는 DAX(데이터 분석 식)로 작성된 수식을 기반으로 합니다. 측정값 식은 쿼리 시 스칼라 값 결과를 생성하기 위해 , , 및 기타와 같은
SUMMINMAXAVERAGEDAX 집계 함수를 사용하는 경우가 많습니다(값은 모델에 저장되지 않습니다). 측정값 식은 간단한 열 집계부터 필터 컨텍스트 및/또는 관계 전파를 재정의하는 더 복잡한 수식까지 다양할 수 있습니다. 자세한 내용은 Power BI Desktop의 DAX 기본 사항에 대해 읽어보세요. - 암시적 측정값 은 보고서 시각적 개체 또는 Q&A에서 요약할 수 있는 열입니다. 모델 개발자는 많은 경우에 (명시적) 측정값을 만들 필요가 없으므로 편의를 제공합니다. 예를 들어 Adventure Works 재판매인 판매
Sales Amount열은 가능한 각 집계 유형에 대한 측정값을 만들 필요 없이 다양한 방법(합계, 개수, 평균, 중앙값, 최소, 최대 등)으로 요약할 수 있습니다.
데이터 창에서 명시적 측정값은 계산기 아이콘으로 표현되고 암시적 측정값은 시그마 기호(∑)로 표시됩니다.
그러나 간단한 열 수준 요약에서도 측정값을 만들 수 있는 세 가지 강력한 이유가 있습니다.
보고서 작성자가 MDX(다차원 식)를 사용하여 의미 체계 모델을 쿼리하는 것을 알고 있는 경우 모델에 명시적 측정값이 포함되어야 합니다. MDX가 열 값의 요약을 달성할 수 없기 때문입니다. 특히 피벗 테이블이 MDX 쿼리를 실행하기 때문에 Excel에서 분석을 수행할 때 MDX가 사용됩니다.
보고서 작성자가 MDX 쿼리 디자이너를 사용하여 Power BI 페이지를 매긴 보고서를 만들 것이라는 사실을 알고 있는 경우 의미 체계 모델에 명시적 측정값이 포함되어야 합니다. MDX 쿼리 디자이너만 서버 집계를 지원합니다. 따라서 보고서 작성자가 페이지를 매긴 보고서 엔진 대신 Power BI를 통해 측정값을 평가해야 하는 경우에는 MDX 쿼리 디자이너를 사용해야 합니다.
보고서 작성자가 특정 방식으로 열을 요약하는 방법을 제어하려는 경우 예를 들어 재판매인 판매
Unit Price열(단위당 요금을 나타낸)은 특정 집계 함수를 사용해야만 요약할 수 있습니다. 합계를 계산해서는 안 되지만 min, max 또는 average와 같은 다른 집계 함수를 사용하여 요약하는 것이 적절합니다. 이 인스턴스에서 모델러는 열을 숨기고Unit Price모든 적절한 집계 함수에 대한 측정값을 만들 수 있습니다.이 디자인 방법은 Power BI 서비스에서 작성된 보고서와 질문 및 답변에 적합합니다. 그러나 Power BI Desktop 라이브 연결을 사용하면 보고서 작성자가 데이터 창에 숨겨진 필드를 표시할 수 있으므로 이 디자인 방식을 우회할 수 있습니다.
서로게이트 키
서로게이트 키는 별모양 스키마 모델링을 지원하기 위해 테이블에 추가하는 고유 식별자입니다. 정의에 따라 원본 데이터에서 정의되거나 저장되지 않습니다. 일반적으로, 서로게이트 키는 각 차원 테이블 행의 고유 식별자를 제공하기 위해 관계형 데이터 웨어하우스 차원 테이블에 추가됩니다.
Power BI 의미 체계 모델 관계는 필터를 다른 테이블의 단일 열로 전파하는 한 테이블의 단일 고유 열을 기반으로 합니다. 의미 체계 모델의 차원 테이블에 단일 고유 열이 포함되지 않은 경우 관계의 "일" 쪽이 되도록 고유 식별자를 추가해야 합니다. Power BI Desktop에서 파워 쿼리 인덱스 열을 추가하여 이 요구 사항을 달성할 수 있습니다.
인덱스 열도 추가할 수 있도록 이 쿼리를 “다” 쪽 쿼리와 병합해야 합니다. 이러한 쿼리를 의미 체계 모델에 로드하는 경우 모델 테이블 간에 일대다 관계를 만들 수 있습니다.
눈송이 차원
눈송이 차원은 단일 비즈니스 엔터티에 대한 정규화된 테이블 집합입니다. 예를 들어 Adventure Works는 범주 및 하위 범주별로 제품을 분류합니다. 제품은 하위 범주에 할당되고 하위 범주는 차례로 범주에 할당됩니다. Adventure Works 관계형 데이터 웨어하우스에서 제품 차원은 정규화되어 세 개의 관련 테이블(DimProductCategory, DimProductSubcategory 및 DimProduct)에 저장됩니다.
상상력을 발휘한다면, 팩트 테이블에서 바깥쪽으로 배치된 정규화된 테이블이 눈송이 모양을 만드는 그림을 그릴 수 있습니다.
Power BI Desktop에서 눈송이 차원 디자인을 모방하거나(원본 데이터가 수행하므로) 원본 테이블을 결합하여 비정규화된 단일 모델 테이블을 구성할 수 있습니다. 일반적으로 단일 모델 테이블의 혜택이 여러 모델 테이블의 혜택보다 큽니다. 가장 최적 결정은 모델의 데이터 볼륨 및 유용성 요구 사항에 따라 달라질 수 있습니다.
눈송이 차원 디자인을 모방하는 경우:
- Power BI가 더 많은 테이블을 로드하므로 스토리지 및 성능 관점에서 효율성이 떨어집니다. 이러한 테이블에 모델 관계를 지원하기 위한 열을 포함해야 하며, 이로 인해 모델 크기가 커질 수 있습니다.
- 더 긴 관계 필터 전파 체인을 트래버스해야 하므로 단일 테이블에 적용된 필터보다 효율성이 떨어집니다.
- 데이터 창에는 보고서 작성자에게 더 많은 모델 테이블이 표시되며, 특히 눈송이 차원 테이블에 하나 또는 두 개의 열만 포함된 경우 직관적이지 않은 환경이 발생할 수 있습니다.
- 둘 이상의 테이블의 열로 구성된 계층 구조를 만들 수 없습니다.
단일 모델 테이블로 통합하는 경우, 차원의 최고 및 최저 세분성을 포함하는 계층 구조를 정의할 수도 있습니다. 중복 비정규화된 데이터의 스토리지는 특히 큰 차원 테이블의 경우 모델 스토리지 크기가 증가할 수 있습니다.
느린 변경 차원
느린 변경 차원(또는 SCD)은 시간이 지남에 따라 차원 멤버의 변경을 적절하게 관리하는 차원입니다. 비즈니스 엔터티 값이 계획되지 않은 방식으로 시간이 지남에 따라 느리게 변경될 때 적용됩니다. SCD의 좋은 예는 이메일 주소 및 전화 번호와 같은 연락처 세부 정보 열이 자주 변경되지 않으므로 고객 차원입니다. 반면, 일부 차원은 주식의 시장 가격과 같이 차원 특성이 자주 변경될 때 빠르게 변화하는 것으로 간주됩니다. 이러한 경우의 일반적인 디자인 방법은 신속하게 변경되는 특성 값을 팩트 테이블 측정값에 저장하는 것입니다.
별모양 스키마 디자인 이론은 유형 1과 유형 2의 두 가지 일반적인 SCD 유형을 참조합니다. 차원 테이블은 형식 1 또는 형식 2이거나 서로 다른 열에 대해 두 형식을 동시에 지원할 수 있습니다.
유형 1 SCD
유형 1 SCD는 항상 최신 값을 반영하며 원본 데이터의 변경 내용이 검색되면 차원 테이블 데이터를 덮어씁니다. 이 디자인 방법은 일반적으로 고객의 메일 주소 또는 전화 번호와 같이 보충 값을 저장하는 열에 사용됩니다. 고객 메일 주소 또는 전화 번호가 변경되는 경우 차원 테이블은 고객 행을 새 값으로 업데이트합니다. 고객에게 항상 이 연락처 정보가 있는 것처럼 동작합니다.
Power BI 모델 차원 테이블의 비증분 새로 고침은 Type 1 SCD의 결과를 달성합니다. 테이블 데이터를 새로 고쳐 최신 값이 로드되도록 합니다.
유형 2 SCD
유형 2 SCD는 차원 멤버의 버전 관리를 지원합니다. 원본 시스템에서 버전을 저장하지 않는 경우 일반적으로 변경 내용을 감지하고 차원 테이블의 변경 내용을 적절하게 관리하는 데이터 웨어하우스 로드 프로세스입니다. 이 경우에는 차원 테이블이 서로게이트 키를 사용하여 차원 멤버의 버전에 대한 고유 참조를 제공해야 합니다. 또한 버전의 날짜 범위 유효성을 정의하는 열(예: StartDate 및 EndDate)과 현재 차원 멤버를 기준으로 쉽게 필터링하기 위한 플래그 열(예: IsCurrent)을 포함합니다.
예를 들어 Adventure Works는 모든 영업 사원을 영업 지역에 할당합니다. 영업 사원이 다른 지역으로 재배치되는 경우 새 버전의 영업 사원을 만들어 기록 팩트를 이전 지역과 연결된 상태로 유지해야 합니다. 영업 사원별로 정확한 판매 기록 분석을 지원하려면 차원 테이블에 영업 사원 버전 및 관련 지역을 저장해야 합니다. 시간 유효성을 정의하는 시작 날짜 및 종료 날짜 값도 테이블에 포함되어야 합니다. 현재 버전은 행이 현재 버전임을 나타내는 빈 종료 날짜(또는 12/31/9999)를 정의할 수 있습니다. 비즈니스 키(이 경우 직원 ID)는 고유하지 않으므로 테이블에 서로게이트 키도 있어야 합니다.
원본 데이터가 버전을 저장하지 않는 경우 데이터 웨어하우스와 같은 중간 시스템을 사용하여 변경 내용을 검색하고 저장해야 한다는 점을 이해하는 것이 중요합니다. 테이블 로드 프로세스는 기존 데이터를 보존하고 변경 내용을 검색해야 합니다. 변경 내용이 검색되면 테이블 로드 프로세스에서 현재 버전을 만료해야 합니다. EndDate 값을 업데이트하고, 이전 EndDate 값에서 시작하는 StartDate 값으로 새 버전을 삽입하여 이러한 변경 내용을 기록합니다. 또한 관련 팩트는 시간 기반 조회를 사용하여 팩트 날짜와 관련된 차원 키 값을 검색해야 합니다. Power BI 의미 체계 모델은 파워 쿼리를 사용하므로 이 결과를 생성할 수 없습니다. 그러나 미리 로드된 SCD 유형 2 차원 테이블에서 데이터를 로드할 수 있습니다.
팁
패브릭 웨어하우스에서 Type 2 SCD 차원 테이블을 구현하는 방법을 알아보려면 기록 변경 관리를 참조하세요.
Power BI 의미 체계 모델은 변경 내용에 관계없이 멤버에 대한 기록 데이터 쿼리와 멤버의 특정 상태를 나타내는 멤버 버전에 대한 쿼리를 지원해야 합니다. Adventure Works의 컨텍스트에서 이 디자인을 사용하면 할당된 판매 지역과 관계없이 판매 직원을 쿼리하거나, 특정 버전의 판매 직원을 쿼리할 수 있습니다.
이 요구 사항을 달성하려면 Power BI 의미 체계 모델 차원 테이블에는 영업 사원을 필터링하기 위한 열과 특정 버전의 영업 사원을 필터링하기 위한 다른 열이 포함되어야 합니다. 버전 열은 유사 David Campbell (12/15/2008-06/26/2019) 하거나 David Campbell (06/27/2019-Current)모호하지 않은 설명을 제공하는 것이 중요합니다. 또한 유형 2 SCD의 기본 사항과 올바른 필터를 적용하여 적절한 보고서 디자인을 수행하는 방법을 보고서 작성자와 소비자에게 교육하는 것이 중요합니다.
시각적 개체를 버전 수준으로 드릴다운할 수 있는 계층 구조를 포함하는 것이 좋습니다.
롤플레잉 차원
롤플레잉 차원은 관련 팩트를 다르게 필터링할 수 있는 차원입니다. 예를 들어 Adventure Works에서 날짜 차원 테이블에는 재판매인 판매 팩트의 세 가지 관계가 있습니다. 동일한 차원 테이블을 사용하여 주문 날짜, 발송 날짜 또는 배송 날짜별로 사실을 필터링할 수 있습니다.
데이터 웨어하우스에서 허용되는 디자인 방법은 단일 날짜 차원 테이블을 정의하는 것입니다. 쿼리 시간에 테이블을 조인하는 데 사용하는 팩트 열을 기준으로 날짜 차원의 “역할”이 설정됩니다. 예를 들어 주문 날짜별로 판매를 분석하는 경우 테이블 조인은 Reseller Sales의 주문 날짜 열과 관련이 있습니다.
Power BI 의미 체계 모델에서 이 디자인은 두 테이블 간에 여러 관계를 만들어 모방할 수 있습니다. Adventure Works 예제에서 날짜 테이블과 Reseller Sales 테이블 간에는 세 가지 관계가 있습니다.
이 디자인은 가능하지만 두 Power BI 의미 체계 모델 테이블 사이에는 하나의 활성 관계만 있을 수 있습니다. 나머지 관계는 모두 비활성으로 설정해야 합니다. 단일 활성 관계가 있으면 날짜에서 재판매인 판매로의 기본 필터 전파가 있음을 의미합니다. 이 경우 활성 관계는 보고서에서 사용되는 가장 일반적인 필터로 설정되며 Adventure Works에서는 주문 날짜 관계입니다.
비활성 관계를 사용하는 방법은 USERELATIONSHIP 함수를 사용하는 DAX 식을 정의하는 것뿐입니다. 이 예제에서는 모델 개발자가 발송 날짜 및 배송 날짜별로 Reseller Sales를 분석할 수 있도록 측정값을 만들어야 합니다. 이 작업은 특히 Reseller Sales 테이블에서 많은 측정값을 정의하는 경우 번거로울 수 있습니다. 또한 측정값이 과도하게 포함된 복잡한 데이터 창을 만듭니다. 다른 제한 사항도 있습니다.
- 보고서 작성자가 측정값을 정의하는 대신 열 요약을 사용하는 경우 보고서 수준 측정값을 작성하지 않고는 비활성 관계에 대한 요약을 달성할 수 없습니다. 보고서 수준 측정값은 Power BI Desktop에서 보고서를 작성하는 경우에만 정의할 수 있습니다.
- 날짜와 Reseller Sales 간에 활성 관계 경로가 하나뿐이므로, 서로 다른 날짜 유형을 기준으로 Reseller Sales를 동시에 필터링할 수 없습니다. 예를 들어 발송된 판매를 기준으로 주문 날짜 판매를 그리는 시각적 개체를 생성할 수 없습니다.
이러한 제한을 극복하기 위해 일반적인 Power BI 모델링 기술은 각 역할 재생 인스턴스에 대한 차원 테이블을 만드는 것입니다. 파워 쿼리를 사용하여 각 차원 테이블을 참조 쿼리 로 만들거나 DAX를 사용하여 계산된 테이블을 만들 수 있습니다. 모델에는 각 Ship Date 재판매인 Date 판매 테이블 열에 대한 단일 및 활성 관계가 있는 테이블, 테이블 및 Delivery Date 테이블이 포함될 수 있습니다.
이 디자인 방법을 사용하면 날짜 역할에 따라 여러 측정값을 정의할 필요가 없으며, 서로 다른 날짜 역할을 기준으로 동시에 필터링할 수 있습니다. 그러나 이 디자인 방법으로 지불해야 하는 사소한 가격은 날짜 차원 테이블이 중복되어 모델 스토리지 크기가 증가한다는 것입니다. 차원 테이블은 일반적으로 팩트 테이블을 기준으로 행 수가 적기 때문에 거의 문제가 되지 않습니다.
각 역할에 대한 모델 차원 테이블을 만들 때 좋은 디자인 방법을 따르는 것이 좋습니다.
- 열 이름이 자체 설명되도록 지정합니다. 모든 날짜 테이블에 열이 있을
Year수 있지만(열 이름은 테이블 내에서 고유함), 기본적으로 시각적 개체 제목을 자체 설명하는 것은 아닙니다. 테이블에 이름이 지정된 연도 열이 있도록 각 차원 역할 테이블의Ship Date열 이름을Ship Year바꾸는 것이 좋습니다. - 관련된 경우 테이블 설명이 필터 전파 설정 방법에 대한 보고서 작성자(데이터 창 도구 설명을 통해)에게 피드백을 제공하는지 확인합니다. 이러한 명확성은 모델에 많은 팩트 테이블을 필터링하는 데 사용되는 제네릭 명명된 테이블(예:
Date)을 포함하는 경우에 중요합니다. 예를 들어 이 테이블에 재판매인 판매 주문 날짜 열에 대한 활성 관계가 있는 경우 다음과 같은Filters reseller sales by order date테이블 설명을 제공하는 것이 좋습니다.
자세한 내용은 활성 및 비활성 관계 지침을 참조하세요.
정크 차원
정크 차원은 특히 적은 특성(1개일 수 있음)으로 구성된 차원이 많고, 이러한 특성의 값이 적은 경우에 유용합니다. 적합한 후보는 주문 상태 열 또는 성별 또는 연령 그룹과 같은 고객 인구 통계 열을 포함합니다.
정크 차원의 디자인 목표는 많은 작은 차원을 단일 차원으로 통합하여 모델 스토리지 크기를 줄이고 더 적은 수의 모델 테이블을 표시하여 데이터 창의 혼란을 줄이는 것입니다.
정크 차원 테이블은 일반적으로 각 행을 고유하게 식별하는 서로게이트 키 열이 있는 모든 차원 특성 멤버의 Cartesian 제품입니다. 데이터 웨어하우스에서 차원을 작성하거나, 파워 쿼리를 통해 전체 외부 쿼리 조인을 수행한 다음, 서로게이트 키(인덱스 열)를 추가하는 쿼리를 만들어 차원을 작성할 수 있습니다.
이 쿼리를 차원 테이블로 모델에 로드합니다. 또한 "일대다" 모델 관계 만들기를 지원하기 위해 인덱스 열이 모델에 로드되도록 이 쿼리를 팩트 쿼리와 병합해야 합니다.
중복 제거 차원
퇴화 차원은 필터링에 필요한 팩트 테이블의 특성을 나타냅니다. Adventure Works의 Reseller Sales 주문 번호가 좋은 예입니다. 이 경우 모델 스토리지 크기 가 증가하고 데이터 창이 복잡해지므로 이 하나의 열로만 구성된 독립 테이블을 만드는 것은 의미가 없습니다.
Power BI 의미 체계 모델에서는 판매 주문 번호별로 필터링 또는 그룹화할 수 있도록 팩트 테이블에 판매 주문 번호 열을 추가하는 것이 적절할 수 있습니다. 테이블 형식을 혼합해서는 안 된다는 이전에 도입된 규칙의 예외입니다(일반적으로 모델 테이블은 차원 또는 팩트여야 합니다).
그러나 Adventure Works 재판매인 판매 테이블에 주문 번호와 주문 줄 번호 열이 있고 필터링에 필요한 경우 퇴행 차원 테이블을 만드는 것이 좋습니다. 자세한 내용은 일 대 일 관계 지침(중복 제거 차원)을 참조하세요.
팩트리스 팩트 테이블
팩트리스 팩트 테이블에는 측정값 열이 없습니다. 차원 키만 포함합니다.
팩트리스 팩트 테이블은 차원 키로 정의된 관찰을 저장할 수 있습니다. 예를 들어 특정 날짜 및 시간에 특정 고객이 웹 사이트에 로그인했습니다. 팩트 없는 팩트 테이블의 행 수를 계산하여 로그인한 시기와 고객 수를 분석하는 측정값을 정의할 수 있습니다.
팩트리스 팩트 테이블의 더 강력한 사용은 차원 간의 관계를 저장하는 것이며, 다대다 차원 관계를 정의하는 데 권장되는 Power BI 의미 체계 모델 디자인 접근 방식입니다. 다대다 차원 관계 디자인에서는 팩트리스 팩트 테이블을 ‘브리징 테이블’이라고 합니다.
예를 들어 영업 사원이 하나 ‘이상’의 판매 지역에 할당될 수 있습니다. 브리징 테이블은 영업 사원 키와 지역 키라는 두 개의 열로 구성된 팩트리스 팩트 테이블로 디자인됩니다. 중복 값이 두 열에 모두 저장될 수 있습니다.
이 다대다 디자인 방법은 잘 문서화되어 있으며, 브리징 테이블이 없어도 구현할 수 있습니다. 그러나 브리징 테이블 방법은 두 차원을 관련 짓는 경우의 가장 좋은 사례로 간주됩니다. 자세한 내용은 다 대 다 관계 지침(두 차원 유형 테이블 연결)을 참조하세요.
관련 콘텐츠
별모양 스키마 디자인 또는 Power BI 의미 체계 모델 디자인에 대한 자세한 내용은 다음 문서를 참조하세요.