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판)와 같은 널리 출판된 콘텐츠를 직접 참조하세요.
차원 모델에서 팩트 테이블은 관찰 또는 이벤트와 관련된 측정값을 저장합니다. 판매 주문, 주식 잔액, 환율, 온도 수치 등을 저장할 수 있습니다.
팩트 테이블에는 일반적으로 판매 주문 수량과 같은 숫자 열인 측정값이 포함됩니다. 분석 쿼리는 차원 필터 및 그룹화의 컨텍스트 내에서 측정값(합계, 개수, 평균 및 기타 함수 사용)을 요약합니다.
팩트 테이블에는 팩트의 차원성을 결정하는 차원 키도 포함됩니다. 차원 키 값은 팩트의 세분성을 결정하며, 이는 팩트를 정의하는 원자성 수준입니다. 예를 들어 판매 팩트 테이블의 주문 날짜 차원 키는 날짜 수준에서 팩트의 세분성을 설정하는 반면, 판매 대상 팩트 테이블의 대상 날짜 차원 키는 분기 수준에서 세분성을 설정할 수 있습니다.
참고 항목
팩트를 더 높은 수준의 세분성으로 저장할 수 있지만 측정값을 더 낮은 수준의 세분성으로 분할하는 것은 쉽지 않습니다(필요한 경우). 엄청난 양의 데이터와 분석 요구 사항을 고려할 때, 더 높은 수준의 세분성 팩트를 저장해야 하는 타당한 이유가 제공되지만 세부적인 분석은 희생해야 합니다.
팩트 테이블을 쉽게 식별하려면 일반적으로 테이블 이름 앞에 f_ 또는 Fact_를 접두사로 붙입니다.
팩트 테이블 구조
팩트 테이블의 구조를 설명하기 위해 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 스토리지 모드를 사용하여 Data Warehouse 집계 팩트 테이블을 사용할 수 있습니다.
관련 콘텐츠
이 시리즈의 다음 문서에서는 차원 모델 테이블을 로드하기 위한 지침 및 디자인 모범 사례에 대해 알아봅니다.