다음을 통해 공유

Microsoft Fabric Warehouse의 차원 모델링: 팩트 테이블

  • 아티클

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

참고 항목

이 문서는 차원 모델링 일련의 문서의 일부를 구성합니다. 이 시리즈는 Microsoft Fabric Warehouse의 차원 모델링과 관련된 지침 및 디자인 모범 사례에 중점을 둡니다.

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

참고 항목

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

팁

차원 모델링에 대한 경험이 부족한 경우 이 일련의 문서를 첫 번째 단계로 고려해 보세요. 차원 모델링 디자인에 대한 전체 토론을 제공하기 위한 것이 아닙니다. 자세한 내용은 랄프 킴볼 등의 데이터 웨어하우스 도구 키트: 차원 모델링에 대한 최종 가이드(2013년 3판)와 같이 널리 채택된 콘텐츠를 직접 참조하세요.

차원 모델에서 팩트 테이블은 관찰 또는 이벤트와 관련된 측정값을 저장합니다. 판매 주문, 주식 잔액, 환율, 온도 수치 등을 저장할 수 있습니다.

팩트 테이블에는 일반적으로 판매 주문 수량과 같은 숫자 열인 측정값이 포함됩니다. 분석 쿼리는 차원 필터 및 그룹화 컨텍스트 내에서 측정값(합계, 개수, 평균 및 기타 함수 사용)을 요약합니다.

팩트 테이블에는 팩트의 차원을 결정하는 차원 키도 포함됩니다. 차원 키 값은 팩트의 세분성을 결정하며, 팩트를 정의하는 원자성 수준입니다. 예를 들어 판매 팩트 테이블의 주문 날짜 차원 키는 날짜 수준에서 팩트의 세분성을 설정하는 반면 판매 대상 팩트 테이블의 대상 날짜 차원 키는 분기 수준에서 세분성을 설정할 수 있습니다.

참고 항목

팩트를 더 높은 세분성으로 저장할 수 있지만 측정값을 더 낮은 세분성 수준으로 분할하는 것은 쉽지 않습니다(필요한 경우). 분석 요구 사항과 함께 깎아지른 듯한 데이터 볼륨은 더 높은 세분성 팩트를 저장하는 타당한 이유를 제공할 수 있지만 자세한 분석을 희생할 수 있습니다.

팩트 테이블을 쉽게 식별하려면 일반적으로 이름을 접두사로 사용하거나 Fact_접두사로 f_ 지정합니다.

팩트 테이블 구조

팩트 테이블의 구조를 설명하려면 명명 f_Sales된 판매 팩트 테이블의 다음 예제를 고려하세요. 이 예제에서는 좋은 디자인 사례를 적용합니다. 각 열 그룹은 다음 섹션에서 설명합니다.

CREATE TABLE f_Sales
(
    --Dimension keys
    OrderDate_Date_FK INT NOT NULL,
    ShipDate_Date_FK INT NOT NULL,
    Product_FK INT NOT NULL,
    Salesperson_FK INT NOT NULL,
    <…>
    
    --Attributes
    SalesOrderNo INT NOT NULL,
    SalesOrderLineNo SMALLINT NOT NULL,
    
    --Measures
    Quantity INT NOT NULL,
    <…>
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

기본 키

예제의 경우와 마찬가지로 샘플 팩트 테이블에는 기본 키가 없습니다. 이는 일반적으로 유용한 용도를 제공하지 않으며 테이블 스토리지 크기를 불필요하게 늘리기 때문입니다. 기본 키는 차원 키 및 특성 집합에 의해 암시되는 경우가 많습니다.

차원 키

샘플 팩트 테이블에는 팩트 테이블의 차원을 결정하는 다양한 차원 키가 있습니다. 차원 키는 관련 차원의 서로게이트 키(또는 상위 수준 특성)에 대한 참조입니다.

참고 항목

하나 이상의 날짜 차원 키를 포함하지 않는 비정상적인 팩트 테이블입니다.

팩트 테이블은 차원을 여러 번 참조할 수 있습니다. 이 경우 롤플레잉 차원이라고 합니다. 이 예제에서 팩트 테이블에는 OrderDate_Date_FK 차원 키와 ShipDate_Date_FK 차원 키가 있습니다. 각 차원 키는 고유한 역할을 나타내며 실제 날짜 차원은 하나뿐입니다.

각 차원 키를 .로 NOT NULL설정하는 것이 좋습니다. 팩트 테이블 로드 중에 특수 차원 멤버를 사용하여 누락됨, 알 수 없음, N/A 또는 오류 상태를 나타낼 수 있습니다(필요한 경우).

특성

샘플 팩트 테이블에는 두 가지 특성이 있습니다. 특성은 추가 정보를 제공하고 팩트 데이터의 세분성을 설정하지만 차원 키나 차원 특성도 아니고 측정값도 아닙니다. 이 예제에서 특성 열은 판매 주문 정보를 저장합니다. 다른 예로는 추적 번호 또는 티켓 번호가 포함될 수 있습니다. 분석을 위해 특성은 퇴행 차원을 형성할 수 있습니다.

측정값 그룹

샘플 팩트 테이블에는 열과 같은 측정값도 있습니다 Quantity . 측정값 열은 일반적으로 숫자이며 일반적으로 가산적입니다(즉, 다른 집계를 사용하여 합계를 계산하고 요약할 수 있습니다). 자세한 내용은 이 문서의 뒷부분에 있는 측정값 형식을 참조하세요.

감사 특성

샘플 팩트 테이블에는 다양한 감사 특성도 있습니다. 감사 특성은 선택 사항입니다. 팩트 레코드를 만들거나 수정하는 시기와 방법을 추적할 수 있으며 ETL(추출, 변환 및 로드) 프로세스 중에 발생한 진단 또는 문제 해결 정보를 포함할 수 있습니다. 예를 들어 행을 업데이트한 사람(또는 프로세스)과 시기를 추적하려고 합니다. 또한 감사 특성은 ETL 프로세스가 예기치 않게 중지되는 경우와 같이 어려운 문제를 진단하는 데 도움이 될 수 있습니다.

팩트 테이블 크기

팩트 테이블의 크기는 다양합니다. 크기는 차원, 세분성, 측정값 수 및 기록 양에 해당합니다. 차원 테이블에 비해 팩트 테이블은 더 좁지만(열 수가 적음) 행의 측면에서 크 거나 심지어 엄청나 게 많습니다(수십억을 초과).

팩트 디자인 개념

이 섹션에서는 다양한 팩트 디자인 개념을 설명합니다.

팩트 테이블 형식

세 가지 유형의 팩트 테이블이 있습니다.

  • 트랜잭션 팩트 테이블
  • 정기적인 스냅샷 팩트 테이블
  • 스냅샷 팩트 테이블 누적

트랜잭션 팩트 테이블

트랜잭션 팩트 테이블에는 비즈니스 이벤트 또는 트랜잭션이 저장됩니다. 각 행은 차원 키 및 측정값과 선택적으로 다른 특성을 기준으로 팩트를 저장합니다. 모든 데이터는 삽입될 때 완전히 알려져 있으며 오류 수정을 제외하고 변경되지 않습니다.

일반적으로 트랜잭션 팩트 테이블은 가능한 가장 낮은 수준의 세분성으로 팩트를 저장하며 모든 차원에 걸쳐 가산적인 측정값을 포함합니다. 모든 판매 주문 줄을 저장하는 판매 팩트 테이블은 트랜잭션 팩트 테이블의 좋은 예입니다.

정기적인 스냅샷 팩트 테이블

주기적인 스냅샷 팩트 테이블은 미리 정의된 시간 또는 특정 간격으로 측정값을 저장합니다. 시간에 따른 주요 메트릭 또는 성능 지표에 대한 요약을 제공하므로 추세 분석 및 시간에 따른 변경 모니터링에 유용합니다. 측정값은 항상 반가산적입니다 (나중에 설명).

인벤토리 팩트 테이블은 주기적인 스냅샷 테이블의 좋은 예입니다. 모든 제품의 하루말 주식 잔액으로 매일 로드됩니다.

대량의 트랜잭션을 기록하는 경우 트랜잭션 팩트 테이블 대신 주기적인 스냅샷 테이블을 사용할 수 있으며 유용한 분석 요구 사항은 지원하지 않습니다. 예를 들어 하루에 수백만 개의 주식 이동이 있을 수 있지만(거래 팩트 테이블에 저장할 수 있음) 분석은 하루 중 말 주식 수준의 추세에만 영향을 줍니다.

스냅샷 팩트 테이블 누적

누적 스냅샷 팩트 테이블은 잘 정의된 기간 또는 워크플로에 걸쳐 누적되는 측정값을 저장합니다. 비즈니스 프로세스의 상태를 고유한 단계 또는 마일스톤으로 기록하는 경우가 많으며, 완료하는 데 며칠, 몇 주 또는 몇 달이 걸릴 수 있습니다.

팩트 행은 프로세스의 첫 번째 이벤트 직후에 로드된 다음 마일스톤 이벤트가 발생할 때마다 예측 가능한 시퀀스로 업데이트됩니다. 업데이트는 프로세스가 완료될 때까지 계속됩니다.

스냅샷 팩트 테이블을 누적하면 각각 중요 시점 이벤트를 나타내는 여러 날짜 차원 키가 있습니다. 일부 차원 키는 프로세스가 특정 마일스톤에 도달할 때까지 N/A 상태를 기록할 수 있습니다. 측정값은 일반적으로 기간을 기록합니다. 중요 시점 사이의 기간은 비즈니스 워크플로 또는 어셈블리 프로세스에 대한 중요한 인사이트를 제공할 수 있습니다.

측정값 형식

측정값은 일반적으로 숫자이며 일반적으로 가산적입니다. 그러나 일부 측정값을 항상 추가할 수는 없습니다. 이러한 측정값은 반가산적 또는 비가산물로 분류됩니다.

가산 측정값

추가 측정값은 모든 차원에 걸쳐 합계를 계산할 수 있습니다. 예를 들어 주문 수량 및 판매 수익은 가산적 측정값입니다(수익 제공은 단일 통화에 대해 기록됨).

반가산적 측정값

반가산적 측정값은 특정 차원에 대해서만 합계를 계산할 수 있습니다.

다음은 반가산적 측정값의 몇 가지 예입니다.

  • 정기적인 스냅샷 팩트 테이블의 측정값은 다른 기간에 걸쳐 합계를 계산할 수 없습니다. 예를 들어 매일 밤 샘플링된 인벤토리 항목의 기간을 합하면 안 되지만, 매일 밤 선반에 있는 모든 재고 항목의 기간을 합산할 수 있습니다.
  • 재고 팩트 테이블의 주식 잔액 측정값은 다른 제품에서 합계를 계산할 수 없습니다.
  • 통화 차원 키가 있는 판매 팩트 테이블의 판매 수익은 통화 간에 합계를 계산할 수 없습니다.

비가산적 측정값

비가산적 측정값은 차원 간에 합계를 계산할 수 없습니다. 한 가지 예는 온도 판독값이며, 본질적으로 다른 판독값에 추가하는 것은 의미가 없습니다.

다른 예로는 단가 및 비율과 같은 요금이 있습니다. 그러나 비율을 계산하는 데 사용되는 값을 저장하는 것이 더 나은 사례로 간주되므로 필요한 경우 비율을 계산할 수 있습니다. 예를 들어 판매 팩트 할인 비율을 할인 금액 측정값으로 저장할 수 있습니다(판매 수익 측정값으로 나눈 값). 또는 선반에 있는 인벤토리 항목의 기간은 시간이 지남에 따라 합산해서는 안 되지만 재고 항목의 평균 기간 추세를 관찰할 수 있습니다.

일부 측정값은 합계를 계산할 수 없지만 여전히 유효한 측정값입니다. 개수, 고유 개수, 최소값, 최대값, 평균 및 기타를 사용하여 집계할 수 있습니다. 또한 비가산적 측정값은 계산에 사용될 때 가산성이 될 수 있습니다. 예를 들어 단가에 주문 수량을 곱하면 판매 수익이 생성되며 이는 가산적입니다.

팩트리스 팩트 테이블

팩트 테이블에 측정값 열이 없으면 팩트 없는 팩트 테이블이라고 합니다. 팩트 없는 팩트 테이블은 일반적으로 수업에 참석하는 학생과 같은 이벤트 또는 발생을 기록합니다. 분석 관점에서 팩트 행을 계산하여 측정을 수행할 수 있습니다.

집계 팩트 테이블

집계 팩트 테이블은 기본 팩트 테이블을 더 낮은 차원 및/또는 더 높은 세분성으로 롤업하는 것을 나타냅니다. 일반적으로 쿼리되는 차원에 대한 쿼리 성능을 가속화하는 것이 목적입니다.

참고 항목

Power BI 의미 체계 모델은 사용자 정의 집계를 생성하여 동일한 결과를 달성하거나 DirectQuery 스토리지 모드를 사용하여 데이터 웨어하우스 집계 팩트 테이블을 사용할 수 있습니다.

관련 콘텐츠

이 시리즈의 다음 문서에서는 차원 모델 테이블을 로드하기 위한 지침 및 디자인 모범 사례에 대해 알아봅니다.