다음을 통해 공유

Microsoft Fabric 웨어하우스의 차원 모델링: 차원 테이블

  • 아티클

적용 대상:Microsoft Fabric의 ✅ SQL 분석 엔드포인트 및 웨어하우스

참고 항목

이 문서는 차원 모델링 시리즈 문서의 일부입니다. 이 시리즈는 Microsoft Fabric 웨어하우스의 차원 모델링과 관련된 지침 및 디자인 모범 사례에 중점을 둡니다.

이 문서에서는 차원 모델에서 차원 테이블을 설계하는 데 필요한 지침 및 모범 사례를 제공합니다. 테이블 만들기 및 테이블 데이터 관리 등 많은 T-SQL 기능을 지원하는 환경인 Microsoft Fabric의 웨어하우스에 대한 실질적인 지침을 제공합니다. 따라서 차원 모델 테이블을 만들고 데이터로 로드하는 작업을 완벽하게 제어할 수 있습니다.

참고 항목

이 문서에서 Data Warehouse라는 용어는 조직 전반에 걸쳐 중요한 데이터를 포괄적으로 통합하는 엔터프라이즈 Data Warehouse를 의미합니다. 반면, 독립 실행형 용어 웨어하우스는 Data Warehouse를 구현하는 데 사용할 수 있는 SaaS(Software as a Service) 관계형 데이터베이스 제품인 Fabric 웨어하우스를 의미합니다. 명확하게 하기 위해, 이 문서에서 후자는 Fabric 웨어하우스로 언급됩니다.

팁

차원 모델링에 대한 경험이 부족한 경우 이 문서 시리즈를 첫 번째 단계로 고려해 보세요. 차원 모델링 디자인에 대한 완전한 토론을 제공하기 위한 것은 아닙니다. 자세한 내용은 Ralph Kimball의 Data Warehouse 도구 키트: 차원 모델링에 대한 결정적 가이드(2013년 3판)와 같은 널리 출판된 콘텐츠를 직접 참조하세요.

차원 모델에서 차원 테이블은 비즈니스 및 분석 요구 사항과 관련된 엔터티를 설명합니다. 대체로 차원 테이블은 모델링하는 항목을 나타냅니다. 항목은 제품, 사람, 장소 또는 날짜 및 시간을 포함한 기타 개념일 수 있습니다. 차원 테이블을 쉽게 식별하려면 일반적으로 테이블 이름 앞에 d_ 또는 Dim_를 접두사로 붙입니다.

차원 테이블 구조

차원 테이블의 구조를 설명하기 위해 d_Salesperson라는 이름의 영업 직원 차원 테이블의 다음 예시를 살펴봅니다. 이 예시에서는 우수한 디자인 사례를 적용합니다. 다음 섹션에서 각 열 그룹에 대해 설명합니다.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

서로게이트 키

샘플 차원 테이블에는 Salesperson_SK라는 이름의 서로게이트 키가 있습니다. 서로게이트 키는 차원 테이블에 생성되고 저장되는 단일 열 고유 식별자입니다. 차원 모델의 다른 테이블과 관련되는 데 사용되는 기본 키 열입니다.

서로게이트 키는 원본 데이터의 변경으로부터 Data Warehouse를 격리하려고 합니다. 또한 다음과 같은 다양한 혜택을 제공합니다.

  • 여러 데이터 원본을 통합합니다(중복 식별자의 충돌을 방지).
  • 다중 열 자연 키를 보다 효율적인 단일 열 키로 통합합니다.
  • SCD(느린 변경 차원) 유형 2를 사용하여 차원 기록을 추적합니다.
  • 스토리지 최적화를 위해 팩트 테이블 너비를 제한합니다(가능한 가장 작은 정수 데이터 형식을 선택).

서로게이트 키 열은 자연 키(다음에 설명됨)가 허용 가능한 후보로 보이는 경우에도 권장되는 방법입니다. 또한 키 값에 의미를 부여하지 않아야 합니다(나중에 설명하는 날짜 및 시간 차원 키는 제외).

자연 키

샘플 차원 테이블에는 EmployeeID라는 이름의 자연 키도 있습니다. 자연 키는 원본 시스템에 저장된 키입니다. 이를 통해 차원 데이터를 원본 시스템에 연결할 수 있으며, 이는 일반적으로 ETL(추출, 로드, 변환) 프로세스를 통해 차원 테이블을 로드하여 수행됩니다. 경우에 따라 자연 키를 비즈니스 키라고 하며 해당 값은 비즈니스 사용자에게 그 가치가 의미 있을 수 있습니다.

차원에 자연 키가 없는 경우도 있습니다. 이는 날짜 차원 또는 조회 차원의 경우 또는 플랫 파일을 정규화하여 차원 데이터를 생성하는 경우일 수 있습니다.

차원 특성

샘플 차원 테이블에는 FirstName 열과 같은 차원 특성도 있습니다. 차원 특성은 관련 팩트 테이블에 저장된 숫자 데이터에 대한 컨텍스트를 제공합니다. 일반적으로 분석 쿼리에서 필터링 및 그룹화(슬라이스 및 다이스)하는 데 사용되는 텍스트 열이지만, 자체적으로 집계되지는 않습니다. 다른 차원 테이블에는 많은 특성이 포함되어 있는 반면(차원 모델의 쿼리 요구 사항을 지원하는 데 필요한 만큼), 일부 차원 테이블에는 특성이 거의 포함되어 있지 않습니다.

팁

필요한 차원과 특성을 결정하는 좋은 방법은 적합한 사람을 찾아 올바른 질문을 하는 것입니다. 특히, 별(by)라는 단어가 언급되는지 유의해야 합니다. 예를 들어 영업 직원별, 월별, 제품 범주별로 매출을 분석해야 한다고 말하는 경우 이러한 특성이 있는 차원이 필요하다고 말하는 것입니다.

Direct Lake 의미 체계 모델을 만들려면 필터링 및 그룹화에 필요한 모든 가능한 열을 차원 특성으로 포함해야 합니다. Direct Lake 의미 체계 모델은 계산 열을 지원하지 않기 때문입니다.

외래 키

샘플 차원 테이블에는 SalesRegion_FK라는 이름의 외래 키도 있습니다. 다른 차원 테이블은 외래 키를 참조할 수 있으며 차원 테이블에 외래 키가 있는 것은 특별한 경우입니다. 이는 해당 테이블이 다른 차원 테이블과 관련되어 있음을 나타냅니다. 즉, 눈송이 차원의 일부를 구성하거나 아웃리거 차원과 관련이 있음을 의미합니다.

Fabric 웨어하우스는 외래 키 제약 조건을 지원하지만 적용할 수는 없습니다. 따라서 데이터가 로드될 때 ETL 프로세스에서 관련 테이블 간의 무결성을 테스트하는 것이 중요합니다.

그래도 외래 키를 만드는 것이 좋습니다. 강제되지 않은 외래 키를 만드는 좋은 이유 중 하나는 Power BI Desktop과 같은 모델링 도구가 의미 체계 모델에서 테이블 간의 관계를 자동으로 감지하고 만들 수 있도록 하기 위해서입니다.

기록 추적 특성

샘플 차원 테이블에는 다양한 기록 추적 특성도 있습니다. 기록 추적 특성은 원본 시스템에서 발생하는 특정 변경 내용을 추적해야 하는 필요성에 따라 선택 사항입니다. 값을 저장하여 Data Warehouse의 주 역할을 지원할 수 있습니다. 그 역할은 과거를 정확하게 설명하는 것입니다. 특히 이러한 특성은 ETL 프로세스가 새 데이터 또는 변경된 데이터를 차원으로 로드할 때 기록 컨텍스트를 저장합니다.

자세한 내용은 이 문서의 뒷부분에 나오는 기록 변경 사항 관리를 참조하세요.

감사 특성

샘플 차원 테이블에는 다양한 감사 특성도 있습니다. 감사 특성은 선택 사항이지만 권장됩니다. 이를 통해 차원 레코드를 언제, 어떻게 생성되거나 수정되었는지 추적할 수 있으며 ETL 프로세스 중에 발생한 진단 또는 문제 해결 정보를 포함할 수 있습니다. 예를 들어 누가(또는 어떤 프로세스가) 행을 업데이트했는지, 언제 업데이트했는지 추적할 수 있습니다. 또한 감사 특성은 ETL 프로세스가 예기치 않게 중지되는 경우와 같이 어려운 문제를 진단하는 데 도움이 될 수 있습니다. 차원 멤버에 오류 또는 유추 멤버로 플래그를 지정할 수도 있습니다.

차원 테이블 크기

차원 모델에서 가장 유용하고 다재다능한 차원은 크고 넓은 차원인 경우가 많습니다. 행 측면에서는 크고(수백만 개 초과) 차원 특성의 수 측면에서는 넓습니다(잠재적으로 수백 개). 크기는 그다지 중요하지 않습니다(하지만 가능한 한 가장 작은 크기에 대해 디자인하고 최적화해야 합니다). 중요한 것은 차원이 팩트 데이터의 필수 필터링, 그룹화 및 정확한 기록 분석을 지원한다는 것입니다.

큰 차원은 여러 원본 시스템에서 제공될 수 있습니다. 이 경우 차원 처리에서 데이터를 결합, 병합, 중복 제거 및 표준화하고 서로게이트 키를 할당해야 합니다.

이에 비해 어떤 차원은 아주 작습니다. 단 몇 개의 레코드와 특성만 포함된 조회 테이블을 나타낼 수 있습니다. 이러한 작은 차원은 팩트 테이블의 트랜잭션과 관련된 범주 값을 저장하며, 팩트 레코드와 관련된 서로게이트 키가 있는 차원으로 구현됩니다.

팁

작은 차원이 많은 경우 정크 차원으로 통합하는 것이 좋습니다.

차원 설계 개념

이 섹션에서는 다양한 차원 설계 개념에 대해 설명합니다.

정규화 및 비정상화 비교

차원 테이블을 거의 항상 비정규화해야 합니다. 정규화는 반복적인 데이터를 줄이는 방식으로 저장된 데이터를 설명하는 데 사용되는 용어인 반면, 비정규화는 미리 계산된 중복 데이터가 있는 위치를 정의하는 데 사용되는 용어입니다. 중복 데이터는 일반적으로 계층 구조를 저장(나중에 설명됨)하기 때문에 발생하며, 이는 계층 구조가 평면화됨을 의미합니다. 예를 들어 제품 차원은 하위 범주(및 관련 특성) 및 범주(및 관련 특성)를 저장할 수 있습니다.

차원은 일반적으로 크기가 작기 때문에(팩트 테이블과 비교할 때) 중복 데이터를 저장하는 비용은 거의 항상 쿼리 성능과 유용성 향상에 비해 더 큽니다.

눈송이 차원

비정규화의 한 가지 예외는 눈송이 차원을 설계하는 것입니다. 눈송이 차원은 정규화되며 여러 관련 테이블에 차원 데이터를 저장합니다.

다음 다이어그램은 세 개의 관련 차원 테이블(Product, Subcategory, Category)로 구성된 눈송이 차원을 보여 줍니다.

다이어그램은 이전 단락에 설명된 눈송이 차원의 그림을 보여 줍니다.

다음과 같은 경우 눈송이 차원을 구현하는 것이 좋습니다.

  • 차원이 매우 크고 스토리지 비용이 높은 쿼리 성능의 필요성보다 큽니다. (그러나 주기적으로 여전히 해당되는지 재평가해야 합니다.)
  • 차원을 더 높은 수준의 팩트와 연관시키려면 키가 필요합니다. 예를 들어 판매 팩트 테이블은 제품 수준에서 행을 저장하지만 판매 대상 팩트 테이블은 하위 범주 수준에서 행을 저장합니다.
  • 더 높은 수준의 세분성에서 기록 변경 내용을 추적해야 합니다.

참고 항목

Power BI 의미 체계 모델의 계층 구조는 단일 의미 체계 모델 테이블의 열만을 기반으로 할 수 있습니다. 따라서 눈송이 차원은 눈송이 테이블을 결합하는 보기를 사용하여 비정규화된 결과를 제공해야 합니다.

계층 구조

일반적으로 차원 열은 계층 구조를 생성합니다. 계층 구조를 사용하면 다양한 요약 수준에서 데이터를 탐색할 수 있습니다. 예를 들어 행렬 시각적 개체의 초기 보기는 연간 매출을 표시할 수 있으며 보고서 소비자는 드릴다운을 선택하여 분기별 및 월별 매출을 확인할 수 있습니다.

계층 구조를 차원에 저장하는 데에는 세 가지 방법이 있습니다. 다음을 사용할 수 있습니다.

  • 비정규화된 단일 차원의 열
  • 여러 관련 테이블로 구성된 눈송이 차원
  • 차원의 부모-자식(자체 참조) 관계형

계층 구조는 균형이거나 불균형일 수 있습니다. 일부 계층 구조가 불규칙함을 이해하는 것도 중요합니다.

균형 있는 계층 구조

균형 있는 계층 구조는 가장 일반적인 계층 구조 유형입니다. 균형 있는 계층 구조에는 동일한 수의 수준이 있습니다. 균형 있는 계층 구조의 일반적인 예로는 연도, 분기, 월, 일의 수준으로 구성된 날짜 차원의 달력 계층 구조가 있습니다.

다음 다이어그램은 판매 지역의 균형 있는 계층 구조를 보여 줍니다. 판매 지역 그룹 및 판매 지역의 두 가지 수준으로 구성됩니다.

다이어그램은 그룹 및 판매 지역 열을 포함하는 판매 지역 차원 멤버의 테이블을 보여 줍니다.

균형 있는 계층 구조의 수준은 비정규화된 단일 차원의 열 또는 눈송이 차원을 형성하는 테이블의 열을 기반으로 합니다. 비정규화된 단일 차원을 기반으로 하는 경우 상위 수준을 나타내는 열에는 중복 데이터가 포함됩니다.

균형 있는 계층 구조의 경우 팩트는 항상 일반적으로 가장 낮은 수준인 단일 계층 구조 수준과 관련이 있습니다. 이렇게 하면 팩트를 계층 구조의 가장 높은 수준까지 집계(롤업)할 수 있습니다. 팩트는 모든 수준과 관련될 수 있으며, 이는 팩트 테이블의 범위에 따라 결정됩니다. 예를 들어 판매 팩트 테이블은 날짜 수준에서 저장될 수 있지만 판매 대상 팩트 테이블은 분기 수준에 저장될 수 있습니다.

불균형 계층 구조

균불균형 계층 구조는 가장 일반적인 계층 구조 유형입니다. 불균형 계층 구조에는 부모-자식 관계를 기반으로 수준을 갖습니다. 이러한 이유로 불균형 계층 구조의 수준 수는 특정 차원 테이블 열이 아닌 차원 행에 의해 결정됩니다.

불균형 계층 구조의 일반적인 예로는 직원 차원의 각 행이 동일한 테이블의 보고 관리자 행과 관련된 직원 계층 구조가 있습니다. 이 경우 모든 직원은 보고하는 직원이 있는 관리자가 될 수 있습니다. 당연히 계층 구조의 일부 분기는 다른 분기보다 더 많은 수준을 갖습니다.

다음 다이어그램은 불균형 계층 구조를 보여 줍니다. 4개의 수준으로 구성되며 계층 구조의 각 멤버는 영업 직원입니다. 영업 직원은 보고 대상에 따라 계층 구조에 다른 수의 상위 항목이 있습니다.

다이어그램은 '보고 대상' 열을 포함하는 영업 직원 차원 멤버 테이블을 보여줍니다.

불균형 계층 구조의 다른 일반적인 예로는 자재 명세서, 회사 소유권 모델 및 총계정원장이 있습니다.

불균형 계층 구조의 경우 팩트는 항상 차원 범위와 관련이 있습니다. 예를 들어 판매 팩트는 보고 구조가 다른 다른 영업 직원과 관련이 있습니다. 차원 테이블에는 서로게이트 키(Salesperson_SK라고 명명됨)와 ReportsTo_Salesperson_FK 기본 키 열을 참조하는 외래 키 열이 있습니다. 관리할 사람이 없는 각 영업 직원이 반드시 계층 구조의 모든 분기 중 가장 낮은 수준에 있는 것은 아닙니다. 가장 낮은 수준이 아닌 경우 영업 직원은 제품을 판매하며, 자신에게 보고하는 영업 직원도 있을 수 있습니다. 따라서 팩트 데이터의 롤업은 개별 영업 직원과 모든 하위 항목을 고려해야 합니다.

부모-자식 계층 구조를 쿼리하는 것은 특히 대규모 차원의 경우 복잡하고 느릴 수 있습니다. 원본 시스템에서 관계를 부모-자식으로 저장할 수 있지만 계층 구조를 자연화하는 것이 좋습니다. 이 경우 자연화는 차원의 계층 수준을 열로 변환하고 저장하는 것을 의미합니다.

팁

계층 구조를 자연화하지 않도록 선택하는 경우에도 Power BI 의미 체계 모델에서 부모-자식 관계를 기반으로 계층 구조를 만들 수 있습니다. 그러나 이 접근 방식은 대규모 차원에는 권장되지 않습니다. 자세한 내용은 DAX의 부모-자식 계층 구조 함수 이해를 참조하세요.

비정형 계층 구조

계층 구조에서 멤버의 부모가 바로 위 수준에 존재하지 않기 때문에 계층 구조가 비정형인 경우가 있습니다. 이러한 경우 수준 값이 누적되면 부모의 값이 반복합니다.

균형 있는 지리 계층 구조의 예를 생각해 보겠습니다. 국가/지역에 주 또는 지방이 없는 경우 비정형 계층 구조가 존재합니다. 예를 들어 뉴질랜드에는 주나 지방이 없습니다. 따라서 뉴질랜드 행을 삽입할 때 StateProvince 열에 국가/지역 값도 저장해야 합니다.

다음 다이어그램은 지리적 지역의 비정형 계층 구조를 보여 줍니다.

다이어그램은 국가/지역, 시/도 및 도시 열을 포함하는 지리 차원 멤버의 테이블을 보여 줍니다.

기록 변경 사항 관리

필요한 경우 SCD(느린 변경 차원)를 구현하여 기록 변경을 관리할 수 있습니다. SCD는 기록 컨텍스트를 새 데이터 또는 변경된 데이터로 유지 관리합니다.

가장 일반적인 SCD 유형은 다음과 같습니다.

  • 유형 1: 기존 차원 멤버를 덮어씁니다.
  • 유형 2: 새 시간 기반 버전 관리 차원 멤버를 삽입합니다.
  • 유형 3: 특성을 사용하여 제한된 기록을 추적합니다.

차원이 SCD 유형 1 및 SCD 유형 2 변경 내용을 모두 지원할 수 있습니다.

SCD 유형 3은 의미 체계 모델에서 사용하기 어렵기 때문에 일반적으로 사용되지 않습니다. SCD 유형 2 접근 방식이 더 적합한지 신중하게 고려해야 합니다.

팁

특성이 자주 변경되는 빠르게 변화하는 차원을 예상하는 경우, 대신 해당 특성을 팩트 테이블에 추가하는 것이 좋습니다. 제품 가격과 같이 특성이 숫자인 경우 팩트 테이블에 측정값으로 추가할 수 있습니다. 특성이 텍스트 값인 경우 모든 텍스트 값을 기반으로 차원을 만들고 팩트 테이블에 해당 차원 키를 추가할 수 있습니다.

SCD 유형 1

SCD 유형 1 변경 내용은 변경 내용을 추적할 필요가 없으므로 기존 차원 행을 덮어씁니다. 이 SCD 유형을 사용하여 오류를 수정할 수도 있습니다. 이는 SCD의 일반적인 유형이며 고객 이름, 전자 메일 주소 등 대부분의 변경 특성에 사용해야 합니다.

다음 다이어그램은 전화 번호가 변경된 영업 직원 차원 멤버의 이전 및 이후 상태를 보여 줍니다.

다이어그램은 영업 직원 차원 테이블의 구조와 단일 영업 직원의 변경된 전화 번호에 대한 이전 및 이후 값을 보여줍니다.

이 SCD 유형은 기존 행이 업데이트되므로 관점을 유지하지 않습니다. 즉, SCD 유형 1 변경으로 인해 더 높은 수준의 집계가 달라질 수 있습니다. 예를 들어 영업 직원이 다른 판매 지역에 할당된 경우 SCD 유형 1 변경 사항이 차원 행을 덮어씁 수 있습니다. 영업 직원의 기록 판매 결과를 지역으로 롤업하면 현재 새 판매 지역을 사용하므로 다른 결과가 생성됩니다. 마치 해당 영업 직원이 항상 새 판매 지역에 할당된 것처럼 표시됩니다.

SCD 유형 2

SCD 유형 2 변경으로 인해 차원 멤버의 시간 기반 버전을 나타내는 새 행이 생성됩니다. 항상 현재 버전 행이 있으며 원본 시스템에서 차원 멤버의 상태를 반영합니다. 차원 테이블의 기록 추적 특성은 현재 버전(현재 플래그 TRUE)과 유효 기간을 식별할 수 있는 값을 저장합니다. 여러 버전이 저장될 때 중복된 자연 키가 있기 때문에 서로게이트 키가 필요합니다.

SCD의 일반적인 유형이지만, 역사적 관점을 유지해야 하는 특성을 위해 예약해야 합니다.

예를 들어 영업 직원이 다른 판매 지역에 할당된 경우 SCD 유형 2 변경에는 업데이트 작업 및 삽입 작업이 포함됩니다.

  1. 업데이트 작업은 현재 버전을 덮어써서 기록 추적 특성을 설정합니다. 특히, 종료 유효성 열을 ETL 처리 날짜(또는 원본 시스템의 적절한 타임스탬프)로 설정하고 현재 플래그 FALSE로 설정합니다.
  2. 삽입 작업은 새 현재 버전을 추가하여 시작 유효성 열을 종료 유효성 열 값(이전 버전을 업데이트하는 데 사용됨)에 설정하고 현재 플래그를 TRUE로 설정합니다.

관련 팩트 테이블의 세분성은 영업 직원 수준이 아니라 영업 직원 버전 수준에 있다는 것을 이해하는 것이 중요합니다. 기록 판매 결과를 지역으로 롤업하면 올바른 결과가 생성되지만 분석할 영업 직원 멤버 버전이 두 개(또는 그 이상) 있을 것입니다.

다음 다이어그램은 영업 지역이 변경된 영업 직원 차원 멤버의 이전 및 이후 상태를 보여 줍니다. 조직은 할당된 지역별로 영업 직원의 활동을 분석하려고 하므로 SCD 유형 2 변경이 트리거됩니다.

다이어그램은 '시작 날짜', '종료 날짜' 및 '현재 상태' 열을 포함하는 영업 직원 차원 테이블의 구조를 보여 줍니다.

팁

차원 테이블이 SCD 유형 2 변경을 지원하는 경우 멤버 및 버전을 설명하는 레이블 특성을 포함해야 합니다. Adventure Works의 영업 직원 Lynn Tsoflias 가 호주 판매 지역에서 영국 판매 지역으로 할당을 변경하는 경우를 예로 생각해 보겠습니다. 첫 번째 버전의 레이블 특성은 ‘Lynn Tsoflias (호주)’를 읽을 수 있으며 최신 버전의 레이블 특성은 ‘Lynn Tsoflias (영국)’를 읽을 수 있습니다. 유용한 경우 레이블에 유효 날짜도 포함할 수 있습니다.

역사적 정확성과 유용성 및 효율성에 대한 필요성의 균형을 유지해야 합니다. 분석가가 이해하기 어려울 정도로 엄청난 수의 버전이 생성될 수 있으므로 차원 테이블에 SCD 유형 2 변경 내용이 너무 많지 않도록 주의해야 합니다.

또한 버전이 너무 많으면 변경 특성이 팩트 테이블에 더 잘 저장될 수 있음을 나타낼 수 있습니다. 이전 예시를 확장하여 판매 지역 변경이 빈번할 경우 판매 지역은 SCD 유형 2를 구현하는 대신 팩트 테이블에 차원 키로 저장할 수 있습니다.

다음 SCD 유형 2 기록 추적 특성을 고려할 수 있습니다.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

기록 추적 특성의 용도는 다음과 같습니다.

  • RecChangeDate_FK 열에는 변경 내용이 적용된 날짜가 저장됩니다. 이를 통해 변경이 발생한 시기를 쿼리할 수 있습니다.
  • RecValidToKey 및 RecValidFromKey 열은 행의 유효 날짜를 저장합니다. RecValidFromKey에 날짜 차원에 있는 가장 빠른 날짜를 저장하여 초기 버전을 나타내고, 현재 버전의 01/01/9999에 대해 RecValidToKey를 저장하는 것을 고려해 보세요.
  • RecReason 열은 선택 사항입니다. 이를 통해 버전이 삽입된 이유를 문서화할 수 있습니다. 어떤 속성이 변경되었는지를 인코딩할 수도 있고, 특정 비즈니스 이유를 나타내는 소스 시스템의 코드일 수 있습니다.
  • RecIsCurrent 열을 사용하면 현재 버전만 검색할 수 있습니다. ETL 프로세스가 팩트 테이블을 로드할 때 차원 키를 조회할 때 사용됩니다.

참고 항목

일부 원본 시스템은 기록 변경 내용을 저장하지 않으므로 변경 내용을 검색하고 새 버전을 구현하기 위해 차원을 정기적으로 처리하는 것이 중요합니다. 이렇게 하면 변경 내용이 발생한 직후에 변경 내용을 감지할 수 있으며 유효 날짜는 정확할 것입니다.

SCD 유형 3

SCD 유형 3 변경은 특성으로 제한된 기록을 추적합니다. 이 접근 방식은 마지막 변경 내용 또는 여러 최신 변경 내용을 기록해야 하는 경우에 유용할 수 있습니다.

이 SCD 유형은 제한된 기록 관점을 유지합니다. 초기 및 현재 값만 저장해야 하는 경우에 유용할 수 있습니다. 이 경우 중간 변경이 필요하지 않습니다.

예를 들어 영업 직원이 다른 판매 지역에 할당된 경우 SCD 유형 3 변경 내용이 차원 행을 덮어씁니다. 이전 판매 지역을 구체적으로 저장하는 열은 이전 판매 지역으로 설정되고 새 판매 지역은 현재 판매 지역으로 설정됩니다.

다음 다이어그램은 영업 지역이 변경된 영업 직원 차원 멤버의 이전 및 이후 상태를 보여 줍니다. 조직은 이전 판매 지역 할당을 확인하려고 하므로 SCD 유형 3 변경이 트리거됩니다.

다이어그램은 '이전 판매 지역' 및 '이전 판매 지역 종료 날짜' 열을 포함하는 영업 직원 차원 테이블의 구조를 보여 줍니다.

특수 차원 멤버

누락, 알 수 없음, 해당 없음 또는 오류 상태를 나타내는 행을 차원에 삽입할 수 있습니다. 예를 들어 다음 서로게이트 키 값을 사용할 수 있습니다.

키 값 용도
0 누락됨(원본 시스템에서 사용할 수 없음)
-1 알 수 없음(팩트 테이블 로드 중 조회 실패)
-2 N/A(해당 없음)
-3 오류

일정 및 시간

거의 예외 없이 팩트 테이블은 특정 시점의 측정값을 저장합니다. 날짜(및 시간)로 분석을 지원하려면 달력(날짜 및 시간) 차원이 있어야 합니다.

원본 시스템에 달력 차원 데이터가 있는 경우는 드문 일이기 때문에 Data Warehouse에서 생성해야 합니다. 일반적으로 한 번 생성되며 달력 차원인 경우 필요한 경우 이후 날짜로 확장됩니다.

날짜 차원

날짜(또는 달력) 차원은 분석에 사용되는 가장 일반적인 차원입니다. 날짜당 한 행을 저장하며 연도, 분기 또는 월과 같은 특정 날짜 기간별로 필터링하거나 그룹화하는 일반적인 요구 사항을 지원합니다.

Important

날짜 차원에는 하루 중 시간으로 확장되는 범위가 포함되어서는 안 됩니다. 하루 중 시간 분석이 필요한 경우 날짜 차원과 시간 차원이 모두 있어야 합니다(다음에 설명됨). 하루 중 시간에 대한 팩트를 저장하는 팩트 테이블에는 이러한 차원 각각에 하나씩 두 개의 외래 키가 있어야 합니다.

날짜 차원의 자연 키는 날짜 데이터 형식을 사용해야 합니다. 서로게이트 키는 YYYYMMDD 형식 및 int 데이터 형식을 사용하여 날짜를 저장해야 합니다. 서로게이트 키 값에 의미가 있고 사람이 읽을 수 있는 경우 이 허용된 방법은 유일한 예외여야 합니다(시간 차원과 함께). YYYYMMDD를 int 데이터 형식으로 저장하는 것은 효율적이고 숫자적으로 정렬될 뿐만 아니라 명확한 ISO(International Standards Organization) 8601 날짜 형식을 준수합니다.

다음은 날짜 차원에 포함할 몇 가지 일반적인 특성입니다.

  • QuarterNumberInYear, MonthNumberInYear – 텍스트 레이블을 정렬하는 데 필요할 수 있습니다.
  • FiscalYear, FiscalQuarter – 일부 회사 회계 일정은 연중 중반에 시작되므로 해당 연도 및 회계 연도의 시작/종료가 다릅니다.
  • FiscalQuarterNumberInYear, FiscalMonthNumberInYear – 텍스트 레이블을 정렬하는 데 필요할 수 있습니다.
  • WeekOfYear – 52주 또는 53주가 있는 ISO 표준을 포함하여 연도의 주에 레이블을 지정하는 여러 가지 방법이 있습니다.
  • IsHoliday, HolidayText – 조직이 여러 지역에서 운영되는 경우 각 지리가 별도의 차원으로 관찰하거나 날짜 차원의 여러 특성에서 자연화되는 여러 휴일 목록 집합을 유지 관리해야 합니다. HolidayText 특성을 추가하면 보고할 휴일을 식별하는 데 도움이 될 수 있습니다.
  • IsWeekday – 마찬가지로, 일부 지역에서는 표준 작업 주가 월요일에서 금요일이 아닙니다. 예를 들어 많은 중동 지역에서 일요일부터 목요일까지 근무하는 반면, 다른 지역에서는 4일제 또는 6일제 근무주를 사용합니다.
  • LastDayOfMonth
  • RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset – 상대 날짜 필터링을 지원하는 데 필요할 수 있습니다(예: 이전 달). 현재 기간은 0의 오프셋을 사용하고, 이전 기간은 -1, -2, -3...의 오프셋을 저장하며, 미래 기간은 1, 2, 3의 오프셋을 저장합니다.

모든 차원에서 중요한 것은 알려진 필터링, 그룹화 및 계층 구조 요구 사항을 지원하는 특성이 포함되어 있다는 것입니다. 레이블 번역을 다른 언어로 저장하는 특성도 있을 수 있습니다.

차원이 더 높은 수준의 팩트 관련에 사용되는 경우 팩트 테이블은 날짜 기간의 첫 번째 날짜를 사용할 수 있습니다. 예를 들어 분기별 영업 직원 대상을 저장하는 판매 대상 팩트 테이블은 날짜 차원에 분기의 첫 번째 날짜를 저장합니다. 또 다른 접근 방식은 날짜 테이블에 키 열을 만드는 것입니다. 예를 들어 분기 키는 YYYYQ 형식 및 smallint 데이터 형식을 사용하여 분기 키를 저장할 수 있습니다.

차원은 모든 팩트 테이블에서 사용되는 알려진 날짜 범위로 채워져야 합니다. 또한 Data Warehouse가 목표, 예산 또는 예측에 대한 펙트를 저장하는 이후 날짜도 포함해야 합니다. 다른 차원과 마찬가지로 누락, 알 수 없음, 해당 없음 또는 오류 상황을 나타내는 행을 포함할 수 있습니다.

팁

인터넷에서 ‘날짜 차원 생성기’를 검색하여 날짜 데이터를 생성하는 스크립트 및 스프레드시트를 찾아볼 수 있습니다.

일반적으로 다음 해 초에 ETL 프로세스는 날짜 차원 행을 특정 연도로 앞으로 확장해야 합니다. 차원 테이블에 상대 오프셋 특성이 포함된 경우 ETL 프로세스를 매일 실행하여 현재 날짜(오늘)를 기준으로 오프셋 특성 값을 업데이트해야 합니다.

시간 차원

경우에 따라 팩트를 특정 시점에 저장해야 합니다(예: 하루 중 시간). 이 경우 시간(또는 클록) 차원을 만듭니다. 분(24 x 60 = 1,440개 행) 또는 초(24 x 60 x 60 = 86,400개 행)가 있을 수 있습니다. 다른 가능한 단위에는 반 시간 또는 시간이 포함됩니다.

시간 차원의 자연 키는 시간 데이터 형식을 사용해야 합니다. 서로게이트 키는 적절한 형식을 사용하여 의미가 있고 사람이 읽을 수 있는 값을 저장할 수 있습니다(예: HHMM 또는 HHMMSS 형식 사용).

다음은 시간 차원에 포함할 몇 가지 일반적인 특성입니다.

  • 기간 레이블(아침, 오후, 저녁, 밤)
  • 회사 교대 근무 이름
  • 피크 또는 오프피크 플래그

일치된 차원

일부 차원은 일치된 차원일 수 있습니다. 일치된 차원은 많은 팩트 테이블과 관련되므로 차원 모델의 여러 별에서 공유됩니다. 일관성을 제공하며 지속적인 개발 및 유지 관리를 줄이는 데 도움이 될 수 있습니다.

예를 들어 팩트 테이블은 하나 이상의 날짜 차원 키를 저장하는 것이 일반적입니다(활동은 거의 항상 날짜 및/또는 시간별로 기록되기 때문). 이러한 이유로 날짜 차원은 일반적인 일치된 차원입니다. 따라서 날짜 차원에 모든 팩트 테이블의 분석과 관련된 특성이 포함되어 있는지 확인해야 합니다.

다음 다이어그램에서는 Sales 팩트 테이블과 Inventory 팩트 테이블을 보여줍니다. 각 팩트 테이블은 Date 차원 및 Product 차원과 관련이 있으며, 이는 일치된 차원입니다.

다이어그램은 이전 단락에 설명된 대로 일치된 차원의 그림을 보여 줍니다.

또 다른 예로, 직원과 사용자가 동일한 사용자 집합일 수 있습니다. 이 경우 각 엔터티의 특성을 결합하여 하나의 일치된 차원을 생성하는 것이 합리적일 수 있습니다.

롤플레잉 차원

팩트 테이블에서 차원이 여러 번 참조되는 경우 롤플레잉 차원이라고 합니다.

예를 들어 판매 팩트 테이블에 주문 날짜, 배송 날짜 및 배달 날짜 차원 키가 있는 경우 날짜 차원은 세 가지 방법으로 관련됩니다. 각 방법은 고유한 역할을 나타내지만 실제 날짜 차원은 하나뿐입니다.

다음 다이어그램에서는 Flight 팩트 테이블을 보여줍니다. Airport 차원은 Departure Airport 차원과 Arrival Airport 차원처럼 팩트 테이블과 두 번의 관련이 있기 때문에 롤플레잉 차원입니다.

다이어그램은 이전 단락에 설명된 대로 항공사 항공편 팩트의 별모양 스키마를 보여 줍니다.

정크 차원

정크 차원은 독립적인 차원이 많을 경우 특히 적은 특성(1개일 수 있음)으로 구성된 경우, 그리고 이러한 특성의 값이 낮은 카디널리티를 가질 경우(값이 적은 경우)에 유용합니다. 정크 차원의 목적은 많은 작은 차원을 단일 차원으로 통합하는 것입니다. 이 설계 접근 방식은 차원 수를 줄이고 팩트 테이블 키의 수를 줄여 팩트 테이블 스토리지 크기를 줄일 수 있습니다. 또한 사용자에게 더 적은 테이블을 표시하기 때문에 데이터 창의 어수선함을 줄이는 데 도움이 됩니다.

정크 차원 테이블은 일반적으로 모든 차원 특성 멤버의 카티전 곱과 서로게이트 키 특성을 저장합니다.

적합한 후보로는 플래그 및 지표, 주문 상태 및 고객 인구 통계 상태(성별, 연령 그룹 등)가 있습니다.

다음 다이어그램에서는 주문 상태 값과 배달 상태 값을 결합하는 Sales Status이라는 이름의 정크 차원을 보여 줍니다.

다이어그램은 주문 상태 및 배달 상태 값과 해당 값의 카티전 곱에서 '판매 상태태' 차원 행을 만드는 방법을 보여 줍니다.

중복 제거 차원

중복 제거 차원은 차원이 관련 팩트와 동일한 범위에 있을 때 발생할 수 있습니다. 중복 제거 차원의 일반적인 예로는 판매 팩트 테이블과 관련된 판매 주문 번호 차원이 있습니다. 일반적으로 청구서 번호는 팩트 테이블의 단일 비 계층적 특성입니다. 따라서 별도의 차원 테이블을 만들기 위해 이 데이터를 복사하지 않는 것이 일반적인 관행입니다.

다음 다이어그램은 판매 팩트 테이블의 Sales Order 열을 기반으로 하는 중복 제거 차원인 SalesOrderNumber 차원을 보여줍니다. 이 차원은 고유한 판매 주문 번호 값을 검색하는 보기로 구현됩니다.

다이어그램은 이전 단락에 설명된 대로 중복 제거 차원을 보여줍니다.

팁

Fabric 웨어하우스에서 중복 제거 차원을 쿼리용 차원으로 표시하는 보기를 만들 수 있습니다.

Power BI 의미 체계 모델링 관점에서 Power Query를 사용하여 중복 제거 차원을 별도의 테이블로 만들 수 있습니다. 이런 방식으로 의미 체계 모델은 필터링 또는 그룹에 사용되는 필드가 차원 테이블에서 공급되고, 팩트를 요약하는 데 사용되는 필드는 팩트 테이블에서 제공되는 모범 사례를 준수합니다.

아웃리거 차원

차원 테이블이 다른 차원 테이블과 관련된 경우 이를 아웃리거 차원이라고 합니다. 아웃리거 차원은 차원 모델의 정의를 준수하고 다시 사용하는 데 도움이 될 수 있습니다.

예를 들어 모든 우편 번호의 지리적 위치를 저장하는 지리 차원을 만들 수 있습니다. 그런 다음 고객 차원 및 영업 직원 차원에서 해당 차원을 참조하여 지리 차원의 서로게이트 키가 저장됩니다. 이런 방식으로 일관된 지리적 위치를 사용하여 고객과 영업 직원을 분석할 수 있습니다.

다음 다이어그램은 아웃리거 차원인 Geography 차원을 보여 줍니다. 이는 Sales 팩트 테이블과 직접적으로 관련이 없습니다. 대신 Customer 차원과 Salesperson 차원을 통해 간접적으로 관련됩니다.

다이어그램은 이전 단락에 설명된 대로 아웃리거 차원의 그림을 보여 줍니다.

다른 차원 테이블 특성에 날짜가 저장되어 있는 경우 날짜 차원을 아웃리거 차원으로 사용할 수 있습니다. 예를 들어 고객 차원의 생년월일은 날짜 차원 테이블의 서로게이트 키를 사용하여 저장할 수 있습니다.

다중값 차원

차원 특성이 여러 값을 저장해야 하는 경우 다중값 차원을 설계해야 합니다. 브리지 테이블(조인 테이블이라고도 함)을 만들어 다중값 차원을 구현해야 합니다. 브리지 테이블은 엔터티 간의 다 대 다 관계를 저장합니다.

예를 들어 영업 직원 차원이 있고 각 영업 직원이 하나 이상의 판매 지역에 배정되어 있다고 고려해 보겠습니다. 이 경우 판매 지역 차원을 만드는 것이 좋습니다. 해당 차원은 각 판매 지역을 한 번만 저장합니다. 브리지 테이블이라고 하는 별도의 테이블에는 각 영업 직원 및 판매 지역 관계에 대한 행이 저장됩니다. 실제로 영업 직원 차원에서 브리지 테이블까지의 일대다 관계가 존재하고, 판매 지역 차원에서 브리지 테이블에 이르는 또 다른 일대다 관계가 존재합니다. 논리적으로 보면 영업 직원과 판매 지역 간에는 다대다 관계가 있습니다.

다음 다이어그램에서 Account 차원 테이블은 Transaction 팩트 테이블과 연관되어 있습니다. 고객은 여러 계정을 가질 수 있고 계정은 여러 고객을 가질 수 있으므로 Customer 차원 테이블은 Customer Account 브리지 테이블을 통해 관련됩니다.

다이어그램은 이전 단락에 설명된 대로 다중값 차원의 그림을 보여 줍니다.

관련 콘텐츠

이 시리즈의 다음 문서에서는 책트 테이블에 대한 지침 및 디자인 모범 사례에 대해 알아봅니다.