Power BI 모델링에서 Fact와 Dimension 테이블 개념

Power BI를 포함한 BI(Data Warehouse) 시스템에서 데이터 모델링의 핵심은 데이터를 분석하기 쉽게 구조화하는 것입니다. 이때 가장 기본적인 개념이 바로 Fact(트랜잭션) 테이블과 Dimension(마스터) 테이블입니다. 이 두 가지의 역할과 차이를 명확히 이해하는 것이 효율적이고 성능 좋은 Power BI 모델을 만드는 핵심입니다.

---

1. Fact (Transaction) 테이블의 개념

Fact 테이블은 비즈니스에서 발생한 측정 가능한 이벤트나 거래 데이터(Transaction Data)를 저장하는 테이블로, 분석에서 계산의 중심이 되는 데이터를 담습니다.

특징

• 핵심 목적: 수량, 금액, 매출, 원가 등 계산 가능한 숫자 값(Measure) 저장
• 데이터의 규모: 일반적으로 매우 크며, 빠르게 증가함 (예: 매출 내역, 주문 기록)
• 관계: 여러 Dimension 테이블과 외래키(Foreign Key)로 연결됨
• 시간에 따른 변화 추적: 날짜별·시간별로 누적 가능함

예시

비즈니스 사례	Fact 테이블 예시	주요 컬럼
매출 분석	SalesFact	판매일자ID, 제품ID, 고객ID, 매출액, 수량
재고 추적	InventoryFact	제품ID, 창고ID, 날짜ID, 재고량
생산 현황	ProductionFact	설비ID, 품목ID, 작업일자ID, 생산수량, 불량수

반응형

---

2. Dimension (Master) 테이블의 개념

Dimension 테이블은 Fact 테이블을 설명하는 속성 데이터(또는 분류 정보)를 담고 있으며, 사용자가 분석 시 데이터를 구분하고 필터링하기 위한 기준이 됩니다.

특징

• 핵심 목적: Fact 데이터의 맥락(Context)을 설명하는 텍스트 중심 데이터 저장
• 데이터의 크기: 상대적으로 작고 변화가 드묾
• 관계: Fact 테이블의 외래키와 연결되어 의미 부여
• 계층적 구조(Hierarchy) 포함 가능 (예: 도시 → 도 → 국가)

예시

비즈니스 사례	Dimension 테이블 예시	주요 칼럼
매출 분석	CustomerDim	고객ID, 고객명, 성별, 지역
제품 분석	ProductDim	제품ID, 제품명, 카테고리, 브랜드
시간 분석	DateDim	날짜ID, 일자, 월, 분기, 연도

 

---

3. Fact와 Dimension의 차이점 요약

구분	Fact 테이블	Dimension 테이블
역할	측정 값 저장	설명적 속성 제공
데이터 유형	수치 중심 (Measure)	텍스트 중심 (Attribute)
예시	매출액, 수량, 원가	제품명, 지역, 날짜, 고객군
크기	매우 크고 계속 누적	작고 정적
변경 빈도	자주 업데이트	드물게 업데이트
관계 방향	외래키를 통해 참조	기본키 제공

---

4. Fact와 Dimension을 구분하는 이유

• 분석 속도 최적화: 차원을 분리함으로써 슬라이싱·필터링 속도가 빨라짐.
• 데이터 일관성 확보: 동일한 차원을 여러 Fact 테이블이 공유 가능 (예: ProductDim이 Sales, Inventory 모두에 연결).
• 유지보수 용이성: 변경 주기가 다른 데이터(마스터 vs 트랜잭션)를 분리해 관리 효율 향상.
• Power BI 시각화 효율 개선: Dimension을 기반으로 필터·드릴다운·계층 구조 설정이 쉬움.

---

5. 모델링 구조 — 스타 스키마(Star Schema)

스타 스키마는 가장 일반적이고 Power BI에서 권장되는 모델 구조입니다. 중앙의 Fact 테이블을 중심으로 여러 Dimension 테이블이 별 모양으로 배치됩니다.

         CustomerDim      ProductDim
               \            /
                \          /
                 SalesFact
                /          \\
         DateDim         RegionDim

특징

• 중앙에 단일 Fact 테이블 존재
• 외곽에 여러 Dimension 테이블 연결
• 조인 관계 단순 → 성능 향상

대안: 스노우플레이크 스키마(Snowflake Schema)

• Dimension 테이블을 추가로 세분화한 구조 (예: Region → Country → Continent)
• 정규화 수준이 더 높지만, 복잡하고 Power BI 내에서는 상대적으로 비효율적

---

6. 실제 예시 — 판매 분석 모델

테이블 이름	유형	주요 컬럼
SalesFact	Fact	판매ID, 제품ID, 고객ID, 날짜ID, 수량, 매출액
ProductDim	Dimension	제품ID, 제품명, 카테고리, 브랜드
CustomerDim	Dimension	고객ID, 고객명, 지역, 고객등급
DateDim	Dimension	날짜ID, 일자, 월, 분기, 연도
RegionDim	Dimension	지역ID, 도시명, 도명, 국가

 

이 모델을 Power BI에서 구성하면 매출액을 지역·제품·기간별로 손쉽게 집계, 비교, 시각화할 수 있습니다.

---

7. 요약 정리

• Fact = 숫자 중심의 거래 데이터 → “무엇이 얼마나 발생했는가?”
• Dimension = 맥락 제공 데이터 → “누가, 무엇을, 언제, 어디서?”
• 별도의 구분 이유 = 성능, 일관성, 유지보수 효율
• 스타 스키마 = 중앙에 Fact, 주변에 Dimension으로 연결되는 권장 모델