Power BI의 핵심: 데이터 모델링 및 스키마 심층 탐구

Source: Dev.to

Power BI는 다양한 데이터 소스에 연결하고, 데이터를 시각화하며, 조직 전체에 인사이트를 공유할 수 있게 해 주는 강력한 비즈니스 인텔리전스 도구입니다. 모든 Power BI 프로젝트의 핵심에는 데이터 모델이 있으며, 이는 데이터가 어떻게 조직되고, 관계가 설정되며, 분석에 활용되는지를 정의하는 중요한 구성 요소입니다. 데이터 모델을 이해하는 것은 Power BI의 잠재력을 최대한 발휘하는 데 필수적입니다.

이 기사에서는 다음 내용을 설명합니다:

• 데이터 모델이 무엇인지
• Power BI에서 데이터 모델이 왜 중요한지
• 스타 스키마(권장)와 스노우플레이크 스키마(적절한 경우)를 사용하여 깔끔하고 빠르며 정확한 모델을 설계하는 방법

Power BI에서 데이터 모델이란?

Power BI의 데이터 모델은 테이블, 관계, 및 계산의 모음으로, 데이터의 기본 구조를 나타냅니다. 모델은 다음을 정의합니다:

• 데이터가 저장되는 방식
• 서로 다른 데이터 엔터티가 어떻게 연결되는지
• 계산(측정값 및 계산된 열)이 수행되는 방법

이 모델은 보고서와 대시보드를 만들기 위한 기반이 되며, 의미 있는 분석 및 시각화를 가능하게 합니다.

Source:

테이블: 사실 테이블 vs. 차원 테이블 – 중요한 구분

사실 테이블 ( “무엇이 일어났는가” 테이블)

• 측정 가능한 정량 데이터(지표/KPI)를 포함
• 예시: 매출 금액, 수량, 건수, 기간
• 일반적으로 많은 행을 가짐(수백만/수십억)
• 차원 테이블과 연결되는 외래 키를 저장

사실 테이블 구조 예시

Sales_Fact
----------
SalesKey      (Primary Key)
DateKey       (Foreign Key → Date dimension)
ProductKey    (Foreign Key → Product dimension)
CustomerKey   (Foreign Key → Customer dimension)
SalesAmount   (measure)
Quantity      (measure)
Profit        (measure)

차원 테이블 ( “누가, 무엇을, 언제, 어디서” 테이블)

• 설명적인 속성 및 카테고리를 포함
• 예시: 제품 상세, 고객 인구통계, 날짜 계층 구조
• 일반적으로 행 수가 적음(수천 개)
• 분석에 필요한 컨텍스트 제공

차원 테이블 구조 예시

Product_Dim
-----------
ProductKey   (Primary Key)
ProductName
Category
Brand
Color
Size
PriceRange

관계

관계는 데이터 모델에서 테이블이 어떻게 연결되는지를 정의합니다. 서로 다른 테이블의 열 사이에 링크를 설정하여 교차 테이블 계산 및 복잡한 시각화를 가능하게 합니다.

Power BI는 여러 관계 유형을 지원합니다:

Measures & Calculated Columns

Measures are calculations performed on the fly during query execution.

Total Sales   = SUM ( Sales[SalesAmount] )
Average Price = AVERAGE ( Products[Price] )

Calculated Columns are custom columns stored in the table at refresh time.

Profit Margin = DIVIDE ( Sales[Profit], Sales[SalesAmount], 0 )

계층 구조

계층 구조는 데이터를 여러 수준으로 조직하여 세부적으로 탐색하기 쉽게 합니다.
예시: 연도 → 분기 → 월 → 일.

스타 스키마 – Power BI의 골드 스탠다드

스타 스키마가 뛰어난 이유

• Performance – Simple relationships → faster query execution
  성능 – 간단한 관계 → 더 빠른 쿼리 실행

• DAX Simplicity – Clear context transition for calculations
  DAX 단순성 – 계산을 위한 명확한 컨텍스트 전환

• User‑Friendly – Intuitive for report consumers
  사용자 친화적 – 보고서 사용자가 직관적으로 이해

• Optimized Storage – Columnstore indexing works optimally
  최적화된 저장소 – 컬럼스토어 인덱싱이 최적의 성능을 발휘

The Snowflake Schema – When Normalization Matters

스노우플레이크 스키마는 차원 테이블을 여러 개의 관련 테이블로 정규화하여 “스노우플레이크” 형태의 패턴을 만듭니다.

When to Consider a Snowflake

• 원본 데이터가 이미 많이 정규화되어 있을 때
• 저장 효율성을 위해 데이터 중복을 최소화해야 할 때
• 여러 계층 수준을 가진 복잡한 차원일 때
• 기존 정규화된 데이터베이스와 통합할 때

Trade‑off: 중복 감소 ↔ 복잡성 증가, 이는 Power BI 성능에 영향을 줄 수 있습니다 (테이블이 많아질수록 관계가 늘어나고 계산이 느려짐).

Pro Tip: Power BI에서는 Power Query 변환을 사용해 스노우플레이크 차원을 다시 스타 스키마 형태로 “평탄화”할 수 있어, 두 가지 장점을 모두 활용할 수 있습니다.

잘 설계된 데이터 모델이 중요한 이유

1. 성능 – 속도 차이가 극적

실제 영향

• 스타 스키마 보고서: 3초 로드 시간 → 80 % 사용자 채택
• 부실 모델링 동일 보고서: 30초 로드 시간 → 20 % 채택

2. 정확성 – 신뢰할 수 있는 수치 vs. 추측

• Fan traps – 적절한 브리징 없이 다대다 관계
• Chasm traps – 관계 누락으로 인한 집계 부족
• Ambiguous contexts – 테이블 간 다중 활성 경로

예시: 적절한 날짜 차원 관계가 없으면 TOTALYTD() 또는 SAMEPERIODLASTYEAR()와 같은 시계열 함수가 잘못된 결과를 반환합니다.

3. 확장성 – 솔루션의 미래 대비

• 증가된 데이터 양을 원활히 처리
• 일관된 성능 유지
• 새로운 데이터 소스 추가가 용이
• 행 수준 보안 구현 지원

4. 유지보수성 – 기술 부채 감소

• 새로운 요구 사항에 대한 업데이트가 쉬움
• 문제 해결이 간단함
• 다른 개발자에게 원활한 인수인계
• 향후 참조를 위한 명확한 문서화

Power BI에서 데이터 모델 구축 – 단계별

1. Import / Connect 데이터 소스에 연결합니다.
2. Transform 데이터를 Power Query에서 변환합니다 (정리, 이름 바꾸기, 열 분할 등).
3. Load 테이블을 모델에 로드합니다.
4. Define relationships 관계를 정의합니다 (가능하면 일대다 스타 스키마를 선호).
5. Create measures DAX를 사용해 측정값을 생성합니다.
6. Add calculated columns 필요할 때만 계산된 열을 추가합니다.
7. Build hierarchies 드릴‑다운 분석을 위한 계층 구조를 만듭니다.
8. Validate 모델 성능을 검증합니다 (Performance Analyzer 사용).
9. Document 모델을 문서화합니다 (테이블, 관계 및 주요 계산 설명).

Quick Reference Cheat‑Sheet

Remember: 깨끗하고 잘 구조화된 데이터 모델은 빠르고 정확하며 유지 관리가 쉬운 Power BI 솔루션의 기반입니다. 모델링에 초기부터 시간을 투자하면 성능, 사용자 채택 및 확장성 측면에서 하류 이점이 크게 나타납니다.

프로세스 살펴보기

1. 데이터 가져오기 및 변환

모델링을 위한 핵심 변환

• Date 테이블을 적절히 생성 (팩트‑테이블 날짜를 직접 사용하지 않음)
• 가능한 경우 정규화된 구조를 스타 스키마로 평탄화
• 관련 열 간에 일관된 데이터 유형을 보장

2. 관계 정의 및 스키마 선택

데이터를 로드한 후 테이블 간 관계를 정의합니다. 기억하세요:

• 가능한 경우 스타 스키마를 목표로 함
• 적절한 교차‑필터 방향 설정 (보통 단일 방향)
• 관계에 정수 키 사용 (텍스트보다 빠름)

3. 측정값 및 계산 열 만들기

스키마가 설정되면 비즈니스 로직을 만듭니다:

• 집계 계산(합계, 평균, 비율)을 위한 Measures
• 행‑레벨 분류를 위한 Calculated columns
• 날짜 차원을 활용한 Time‑intelligence measures

4. 모델 정리 및 문서화

• 관련 테이블을 folders 로 그룹화
• 명확하고 일관된 naming conventions 사용
• 보고서 보기에서 불필요한 필드 숨기기
• 테이블 및 열에 descriptions 추가

5. 성능 최적화

• 불필요한 열 제거
• 가능한 경우 카디널리티 감소
• DAX 계산 최적화
• 병목 현상을 찾기 위해 Performance Analyzer 사용

Best‑Practice Checklist

1. 항상 스타 스키마 설계부터 시작하세요

2. 적절한 날짜 차원을 구현하세요

   // Create comprehensive Date table
   Date = 
   ADDCOLUMNS (
       CALENDAR ( DATE (2020, 1, 1), DATE (2025, 12, 31) ),
       "Year",      YEAR ( [Date] ),
       "Quarter",   "Q" & FORMAT ( [Date], "Q" ),
       "Month",     FORMAT ( [Date], "MMM" ),
       "Weekday",   FORMAT ( [Date], "dddd" ),
       "IsWeekend", IF ( WEEKDAY ( [Date], 2 ) > 5, TRUE, FALSE )
   )

3. 관계에는 정수 키를 사용하세요

4. 순환 참조와 양방향 필터링을 피하세요

5. 계산된 열보다 측정값을 선호하세요

6. 행 수준 보안을 초기에 구현하세요

7. 정기적으로 테스트하고 검증하세요

   • 소스 시스템과 계산을 검증합니다
   • Performance Analyzer를 사용해 병목 현상을 찾아냅니다
   • 보고서 응답성에 대한 사용자 피드백을 받습니다

Power BI에서 데이터 모델링이 중요한 이유

데이터 모델은 모든 Power BI 프로젝트의 핵심입니다. 원시 데이터를 실행 가능한 인사이트로 전환하는 데 필요한 구조와 논리를 제공합니다. fact와 dimension 테이블 간의 중요한 구분을 이해하고, 적절한 star 또는 snowflake 스키마를 구현하며, 검증된 모범 사례를 따름으로써 다음을 보장하는 기반을 구축합니다:

• Blazing performance – 보고서가 몇 초 안에 로드됩니다(몇 분이 아니라)
• Unquestionable accuracy – 이해관계자가 신뢰할 수 있는 숫자
• Effortless scalability – 비즈니스와 함께 성장하는 모델
• Sustainable maintenance – 기술 부채가 되지 않는 솔루션

star와 snowflake 스키마 사이의 선택은 단순히 학문적인 것이 아니라 보고서 성능과 사용자 경험에 실제적인 영향을 미칩니다. 일반적으로 Power BI에서는 star 스키마가 더 나은 선택이지만, 두 접근 방식을 모두 이해하면 특정 요구 사항에 따라 현명한 결정을 내릴 수 있습니다.

Remember: Power BI에서는 모델이 곧 보고서입니다. 아름다운 시각화는 부실한 기반을 보완할 수 없습니다. 올바른 데이터 모델링에 시간을 투자하면, 만들게 되는 모든 보고서가 더 빠르고, 더 정확하며, 유지보수가 쉬워집니다.

데이터‑분석 단계별 리소스

저장소: