Brain💡 핵심 인사이트 스노우플레이크 스키마(Snowflake Schema)는 스타 스키마의 차원 테이블을 제3정규형(3NF)으로 정규화하여 저장 공간의 중복을 줄인 다차원 모델링 기법입니다. 차원 테이블들이 하위 차원 테이블로 분해되어 그 모양이 눈송이(Snowflake) 구조와 유사하여 이러한 이름이 붙었습니다. 데이터 무결성과 저장 공간 효율성을 높이면서도 분석 시 다중 조인이 필요하다는 성능 트레이드오프를 감수해야 합니다.
Ⅰ. 스타 스키마에서 스노우플레이크 스키마로: 정규화의 귀환
스타 스키마는 분석의 편의를 위해 차원 테이블을 **비정규화(De-normalization)**했습니다. 그러나 관계형 데이터베이스의 정규화(Normalization) 원칙을 완전히抛弃한 것은 아닙니다.
스노우플레이크 스키마는 이 두 가지 접근법의 절충안입니다. 스타 스키마의 핵심 구조(팩트 테이블 중심, 차원 테이블 방사형 배치)를 유지하면서, 차원 테이블 내부에서 반복되는 데이터를 정규화하여 저장 공간을 절약합니다.
[스타 스키마의 비정규화 차원 테이블]
┌──────────────────────────────────────────────────────────┐
│ 제품_차원 (비정규화) │
│ ┌────────┬────────┬──────────┬──────────┬──────────────┐ │
│ │ 제품키 │ 제품명 │ 브랜드명 │ 제조사명 │ 제조사 주소 │ │
│ │ P001 │ 노트북X │ 삼성전자 │ 삼성전자 │ 서울 강남구... │ │
│ │ P002 │ 노트북Y │ 엘지전자 │ 엘지전자 │ 서울 여의도... │ │
│ │ P003 │ 노트북Z │ 삼성전자 │ 삼성전자 │ 서울 강남구... │ │
│ └────────┴────────┴──────────┴──────────┴──────────────┘ │
│ │
│ "삼성전자" 제조사 정보가 P001, P003에 반복 저장됨 │
└──────────────────────────────────────────────────────────┘
↓ 정규화 (제조사 정보를 별도 테이블로 분리)
┌──────────────────────────────────────────────────────────┐
│ 스노우플레이크 스키마의 차원 테이블 │
│ │
│ ┌────────┐ ┌─────────────────┐ │
│ │ 제조사 │ │ 제조사_정보 │ │
│ │ (차원) │───────<│ - 제조사키(PK) │ │
│ └────┬───┘ │ - 제조사명 │ │
│ │ │ - 대표자명 │ │
│ │ │ - 전화번호 │ │
│ │ │ - 주소 │ │
│ │ └─────────────────┘ │
│ │ │
│ ┌────┴────────┐ ┌─────────────────┐ │
│ │ 제품_차원 │ │ 브랜드_정보 │ │
│ │ (정규화) │───────<│ - 브랜드키(PK) │ │
│ ├─────────────┤ │ - 브랜드명 │ │
│ │ 제품키(PK) │ └─────────────────┘ │
│ │ 제품명 │ │
│ │ 브랜드키(FK)│ │
│ │ 제조사키(FK)│ │
│ └─────────────┘ │
└──────────────────────────────────────────────────────────┘
다이어그램 해석: 제품 차원 테이블에서 "제조사명, 제조사 주소" 같은 제조사 정보가 반복되는 것을 볼 수 있습니다. 스노우플레이크 스키마에서는 이 정보를 제조사_정보라는 별도의 차원 테이블로 분리합니다. 이는 제3정규형(3NF)의 "이행적 함수 종속(Transitive Functional Dependency) 제거" 원칙을 적용한 것입니다.
Ⅱ. 스노우플레이크 스키마의 계층 구조
스노우플레이크 스키마에서 차원 테이블은 하위 차원 테이블들로 분해됩니다. 이 분해가 중첩되면 중첩될수록 모양이 눈송이처럼 복잡해집니다.
[스노우플레이크 스키마 전체 구조]
┌──────────────┐
│ 시간_차원 │
│ (정규화 가능) │
└──────┬───────┘
│
┌──────────────┼──────────────┐
│ │ │
│ │ │
┌───────┴───────┐ ┌────┴────┐ ┌──────┴──────┐
│ 제품_차원 │ │ 지점_차원 │ │ 고객_차원 │
│ (하위 정규화) │ │ (하위 정규화)│ │ (하위 정규화)│
└───────┬───────┘ └────┬────┘ └──────┬──────┘
│ │ │
┌───────┴───────┐ │ ┌───────┴───────┐
│ 브랜드_정보 │ │ │ 지역_정보 │
│ (정규화) │ │ │ (정규화) │
└───────┬───────┘ │ └───────┬───────┘
│ │ │
┌───────┴───────┐ │ │
│ 제조사_정보 │ │ │
│ (정규화) │ │ │
└───────────────┘ │ │
│ │
┌──────┴───────┐
│ 판매_팩트 │
│ (중심) │
└──────────────┘
시간 차원의 정규화도 가능합니다. "년_코드 > 분기_코드 > 월_코드 > 주_코드 > 일_코드"처럼 계층이 명확한 경우, 각 수준을 별도의 테이블로 분리할 수 있습니다. 그러나 실제로는 시간 차원은 대부분 비정규화 상태로 유지하는 것이 일반적입니다. 시간은 분석에서 너무 빈번하게 사용되어, 조인 비용이 오히려 성능 저하를 유발하기 때문입니다.
Ⅲ. 스노우플레이크 vs 스타: 구조적 비교
[스타 스키마 vs 스노우플레이크 스키마 비교]
┌─────────────────────┬────────────────────┬────────────────────┐
│ 항목 │ 스타 스키마 │ 스노우플레이크 │
├─────────────────────┼────────────────────┼────────────────────┤
│ 차원 테이블 구조 │ 비정규화 (플랫) │ 정규화 (계층적) │
├─────────────────────┼────────────────────┼────────────────────┤
│ 저장 공간 │ 중복으로 인해较多 │ 정규화로 인해较少 │
├─────────────────────┼────────────────────┼────────────────────┤
│ 조인 횟수 │ 최소 (차원 수만큼) │ 증가 (하위 테이블 수) │
├─────────────────────┼────────────────────┼────────────────────┤
│ 질의 성능 │ 일반적으로 우수 │ 조인 오버헤드로稍低 │
├─────────────────────┼────────────────────┼────────────────────┤
│ 데이터 무결성 │ 중복으로 인해 변경 시 │ 정규화로 인해 유지 쉬움│
│ │ 이상 발생 가능 │ │
├─────────────────────┼────────────────────┼────────────────────┤
│ 유지보수 용이성 │ 차원 추가/수정 용이 │ 구조 변경 시 다중 테이블│
│ │ │ 영향 고려 필요 │
├─────────────────────┼────────────────────┼────────────────────┤
│ 복잡성 │ 단순, 직관적 │ 복잡, 이해 어려울 수 │
└─────────────────────┴────────────────────┴────────────────────┘
실무적 선택 기준:
-
차원 테이블 규모가 작을 때: 차원 테이블 자체가 소규모(수천~수만 행)라면, 정규화所带来的 저장 공간 절감이 미미합니다. 이 경우 스타 스키마의 단순성이 더 나은 선택입니다.
-
차원 테이블 규모가 클 때: "제조사_정보_가 수백만 개의 제품 행에 중복"처럼 중복이 심각하다면, 스노우플레이크 스키마를 고려할 수 있습니다.
-
자주 변경되는 차원: "고객 등급, 제품 카테고리"처럼 자주 변경되는 정보는 정규화하여 **변경 이상(Update Anomaly)**을 방지하는 것이 좋습니다.
-
OLAP 도구 지원: 일부 OLAP 도구는 스노우플레이크 스키마의 복잡한 조인을 최적화하지 못할 수 있습니다. 사용 중인 OLAP 도구의 특성을 고려해야 합니다.
Ⅳ. 스노우플레이크 스키마의 변형: 갈라찬 스키마(Galaxy Schema)
실무에서는 때로는 하나의 팩트 테이블이 여러 차원 테이블의 조합을 참조하는 구조가 필요합니다. 이 구조를 갈라찬 스키마(Galaxy Schema) 또는 **버스 스키마(Bus Schema)**라고 합니다.
예를 들어, "판매_팩트" 테이블과 "재고_팩트" 테이블이 동일한 시간, 지점, 제품 차원을 공유하는 경우입니다. 이 공유 차원들을 **일관된 차원(Conformed Dimension)**이라고 부릅니다.
[갈라찬 스키마 예시]
┌─────────────────────────────────────┐
│ 공유 차원 (Conformed) │
│ 시간_차원 │ 지점_차원 │ 제품_차원 │
└─────────────────────────────────────┘
│ │ │
┌─────────┘ │ └─────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ 판매_팩트 │ │ 재고_팩트 │ │ 환불_팩트 │
│ (매출,수량) │ │ (현재고, │ │ (환불건수, │
│ │ │ 입고량) │ │ 환불금액) │
└────────────┘ └────────────┘ └────────────┘
Ⅴ. 스노우플레이크 스키마의 실제 적용과 📢 비유
데이터 Vault(Modeling)와의 비교: 기업 데이터 웨어하스를 설계할 때 스노우플레이크 외에 **데이터 볼트(Data Vault)**라는 기법도 있습니다. 데이터 볼트는 "허브(Hub), 링크(Link), 샙플(Satellite)" 구조로 데이터의 追踪可能性(Lineage)과 유연성을 강조합니다. 스노우플레이크가 정규화에 초점을 맞춈 반면, 데이터 볼트는 변경에 강한 구조를 지향합니다.
하이브리드 접근: 많은 기업에서는 스타 스키마와 스노우플레이크 스키마의 하이브리드를 사용합니다. 자주 사용하는 차원은 비정규화(스타)하고, 대규모이고 자주 변경되는 차원만 정규화(스노우플레이크)합니다.
📢 섹션 요약 비유: 스노우플레이크 스키마는 **"도서관의 상세目録 카드에 비유"**할 수 있습니다. 스타 스키마가 "이 책은 3층 A구역에 있습니다"(비정규화, 직접 접근)라면, 스노우플레이크는 "3층 A구역은 humanities楼层의 literature 구역에 있습니다. humanities楼层은 본관의 3번째 층입니다."(정규화, 계층적 참조)입니다. 정보를 찾는 데 조회가 더 필요하지만, 정보의 중복이 적고 일관성이 유지됩니다. 도서관 규모가 작다면目録 카드가 오히려 방해가 되듯, 데이터 규모와 사용 패턴에 따라 적절한 전략을 선택해야 합니다.