20분
Dimension 설계: 분석가의 관점
Day 2: 분석팀이 매번 30분씩 기다려요 - 차원 모델링
Dimension 설계: 분석가의 관점
데이터 모델링 > Day 2: 분석팀이 매번 30분씩 기다려요 - 차원 모델링
학습 목표
Dimension 설계 원칙을 이해한다 Surrogate Key의 필요성을 파악한다
Dimension 설계 원칙
1. 분석가 관점으로 설계
"분석가가 어떤 기준으로 데이터를 보고 싶어할까?"
에디터 로딩 중...
분석에 쓸 속성을 Dimension에 포함!
2. Surrogate Key 사용
Surrogate Key = DW에서 새로 부여하는 인공 키
에디터 로딩 중...
왜 Surrogate Key?
- 정수가 빠름: JOIN, 인덱스 성능
- 이력 관리: 같은 고객의 과거/현재 버전 구분
- 소스 독립: OLTP 키가 바뀌어도 DW는 안정
에디터 로딩 중...
3. 비정규화 (Flatten)
OLTP에서 분리된 테이블을 DW에서는 합친다.
에디터 로딩 중...
JOIN 줄이기 위해 의도적으로 중복 저장!
에디터 로딩 중...
4. Descriptive Attribute 풍부하게
에디터 로딩 중...
분석가가 GROUP BY, WHERE에 쓸 속성을 미리 계산해둔다.
특수 Dimension
Degenerate Dimension
Fact에 직접 저장하는 Dimension (별도 테이블 없음)
에디터 로딩 중...
주문번호 같은 건 Dimension 테이블 만들 필요 없음. 속성이 주문번호 하나뿐이라 Fact에 직접 저장.
Junk Dimension
여러 플래그/코드를 묶은 Dimension
에디터 로딩 중...
조합이 적으면 미리 만들어 놓고 FK로 참조.