Brain478. 스노우플레이크 스키마 (Snowflake Schema)
⚠️ 이 문서는 스타 스키마(477번 문서)의 치명적인 단점인 '데이터 중복으로 인한 용량 낭비'를 막기 위해, 가운데 있는 사실(Fact) 테이블은 놔두고, 주변에 있던 차원(Dimension) 테이블들을 제3정규형(3NF)으로 잘게 쪼개어 눈송이처럼 가지를 뻗어 나가는 데이터베이스 모델링 구조를 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 스타 스키마에서 한 걸음 더 나아가, 차원(Dimension) 테이블에 있는 중복 데이터를 제거하기 위해 **차원 테이블을 다시 한번 정규화(Normalization)**하는 기법이다.
- 모양: 중앙의 팩트 테이블에서 1단계 차원 테이블로 이어지고, 그 차원 테이블에서 또 2단계 차원 테이블로 꼬리를 물고 뻗어나가는 모양이 마치 눈송이(Snowflake)의 결정체 같다고 하여 붙여진 이름이다.
- 트레이드오프: 스타 스키마에 비해 하드디스크 용량은 아낄 수 있지만, 조인(JOIN)해야 할 테이블 개수가 기하급수적으로 늘어나서 쿼리 속도는 엄청나게 느려진다.
Ⅰ. 개요: 뚱뚱한 차원 테이블 다이어트 (Context & Necessity)
스타 스키마(477번 문서)로 만든 [상품 차원] 테이블이 있다고 치자.
[상품코드: 1, 상품명: 신라면, 제조사코드: 10, 제조사명: 농심, 제조사주소: 서울][상품코드: 2, 상품명: 짜파게티, 제조사코드: 10, 제조사명: 농심, 제조사주소: 서울]
신라면과 짜파게티 때문에 '농심'과 '서울'이라는 똑같은 텍스트가 쓸데없이 두 번이나 들어갔다. 상품이 1,000만 개면 '농심'이라는 글자도 1,000만 번 들어가서 디스크 용량이 터진다. (비정규화의 한계)
스노우플레이크 스키마는 이 꼴을 보지 못한다. "제조사 정보는 따로 빼!"
[상품 차원]$\rightarrow$[상품코드: 1, 상품명: 신라면, 제조사코드: 10(FK)][제조사 차원]$\rightarrow$[제조사코드: 10, 제조사명: 농심, 제조사주소: 서울](새로 뻗어나간 눈송이 가지)
이렇게 테이블을 잘게 쪼개면(정규화) 중복은 사라진다. 하지만 나중에 "서울에서 만든 라면 매출"을 구하려면 매출 JOIN 상품 JOIN 제조사를 해야 한다. (조인의 늪 시작)
📢 섹션 요약 비유: 스타 스키마가 햄버거 세트 구성품을 1장의 전단지에 다 욱여넣은 것이라면, 스노우플레이크 스키마는 **'다단계 사용 설명서'**와 같습니다. "햄버거 재료는 2페이지 참조 $\rightarrow$ 2페이지: 고기 원산지는 5페이지 참조 $\rightarrow$ 5페이지: 농장 주소는..." 처럼 꼬리에 꼬리를 물고 찾아가야 해서 읽기는 피곤하지만, 책의 두께(중복)는 훨씬 줄어듭니다.
Ⅱ. 스타 스키마 vs 스노우플레이크 스키마 완벽 비교 ★
시험에서 둘의 장단점을 뒤섞어 놓고 찾는 문제가 100% 출제된다.
| 구분 | 스타 스키마 (Star Schema) | 스노우플레이크 스키마 (Snowflake Schema) |
|---|---|---|
| 차원 테이블 형태 | 뚱뚱함 (비정규화) | 날씬함 (정규화 됨) |
| 디스크 용량 | 중복이 많아서 엄청나게 많이 차지함 | 중복이 제거되어 획기적으로 줄어듦 |
| 조인 (JOIN) 횟수 | 무조건 1번 (빠름) | 2번, 3번 꼬리를 물고 계속됨 (느림) |
| 쿼리 복잡도 | 단순함 (개발자가 짜기 쉬움) | 복잡함 (초보자는 쿼리 짜다 길을 잃음) |
| 업데이트 (UPDATE) | 중복 데이터 다 찾아 고쳐야 함 (나쁨) | 쪼개져 있어서 딱 한 곳만 고치면 됨 (좋음) |
Ⅲ. 왜 스노우플레이크는 패배했는가?
1990년대, 하드디스크 1GB의 가격이 엄청나게 비쌌던 시절에는 데이터를 쪼개서(정규화) 용량을 아끼는 스노우플레이크 스키마가 정답처럼 여겨졌다.
하지만 2000년대를 넘어오며 **"하드디스크 가격은 똥값이 되었고, CPU(조인 연산) 시간은 금값이다"**라는 진리가 세상을 지배하게 되었다.
- 결과: 용량을 조금 아끼겠다고 무수한
JOIN을 발생시켜 쿼리 응답 시간을 10초에서 1시간으로 늘려버리는 스노우플레이크 스키마는 현업에서 거의 퇴출당했다. - 현대의 데이터 웨어하우스(DW) 아키텍트들은 디스크를 팍팍 낭비하더라도 무조건 쿼리 속도가 빠른 **스타 스키마(비정규화)**를 기본 모델로 채택한다.
┌──────────────────────────────────────────────────────────────┐
│ 스노우플레이크 스키마(Snowflake) 구조적 시각화 │
├──────────────────────────────────────────────────────────────┤
│ │
│ [ 🏭 제조사 차원 ] ◀── (2단계 뻗어나간 눈송이 가지) │
│ ▲ │
│ │ (JOIN) │
│ [ 📦 상품 차원 ] [ 👤 고객 차원 ] │
│ ↘ ↙ │
│ ┌─────────────────────┐ │
│ │ ☀️ 판매 FACT (가운데) │ │
│ │ - 매장_ID (FK) │ │
│ │ - 상품_ID (FK) │ │
│ │ - 고객_ID (FK) │ │
│ └─────────────────────┘ │
│ ↗ ↖ │
│ [ 🏪 매장 차원 ] [ 📅 시간 차원 ] │
│ │ (JOIN) │
│ ▼ │
│ [ 🗺️ 지역 차원 ] ◀── (2단계 뻗어나간 눈송이 가지) │
│ │
│ ★ 특징: 가운데 팩트에서 시작해 밖으로 갈수록 계속 테이블이 갈라진다(정규화). │
└──────────────────────────────────────────────────────────────┘
Ⅳ. 결론
"정규화의 강박관념이 분석 시스템의 목을 조른다." 스노우플레이크 스키마는 '정규화'라는 관계형 데이터베이스의 훌륭한 철학을 분석용 데이터베이스(OLAP)에까지 억지로 끌고 들어오려다 만들어진 기형적인 아키텍처다. 데이터를 입력(Insert)하고 수정(Update)하는 시스템에서는 정규화가 무조건 맞다. 하지만 수억 건의 데이터를 오직 긁어와서(Select) 통계만 내야 하는 창고(DW) 환경에서는 조인(Join)의 사슬을 끊어내는 것이 최고의 미덕이다. 아키텍트는 "여기서는 디스크를 아끼는 것이 중요한가, CPU를 아끼는 것이 중요한가?"를 끊임없이 저울질해야 한다.
📌 관련 개념 맵
- 대척점 아키텍처: 스타 스키마 (Star Schema - 비정규화, 477번 문서)
- 설계 원리: 정규화 (Normalization - 395~404번 문서)
- 발생하는 문제점: 조인 병목 현상 (Join Bottleneck)
- 활용 시스템: OLAP (476번 문서), Data Warehouse
👶 어린이를 위한 3줄 비유 설명
- 스타 스키마는 장난감 상자에 로봇, 칼, 방패를 그냥 다 같이 쑤셔 넣어둔(비정규화) 상태예요. 상자 하나만 열면 바로 놀 수 있죠.
- 스노우플레이크 스키마는 로봇은 로봇 상자에, 칼은 무기 상자에, 방패는 방어구 상자에 아주 깔끔하게 분리해서(정규화) 정리해 둔 거예요.
- 방은 엄청 깨끗해 보이지만(용량 절약), 친구가 와서 "로봇 세트 꺼내서 놀자!"라고 하면 상자 3개를 다 열고 이리저리 뛰어다니며 조립(JOIN)해야 해서 엄청 피곤하답니다!