Brain💡 핵심 인사이트
차원 모델링은 일반적인 서비스(OLTP) 테이블처럼 데이터를 쪼개고 정규화하는 방식이 아닙니다.
사장님이 "올해 강남 지점에서 팔린 남성용 패딩 매출액 합계 줘!"라는 복잡한 통계/분석용 쿼리(OLAP, 데이터 웨어하우스)를 수천만 건의 데이터 속에서 0.1초 만에 뽑아내기 위해, 데이터를 하나의 거대한 중심 별(Star) 모양으로 재배치하는 특수 설계 기법입니다.
Ⅰ. OLTP(서비스) vs OLAP(분석)의 차이
데이터베이스 설계 철학이 완전히 다릅니다.
- 일반 DB (OLTP): 당근마켓 앱의 백엔드 서버입니다. "홍길동이 방금 1만 원을 보냈다." 이 한 줄(INSERT, UPDATE)을 0.01초 만에 안전하게 넣는 것이 생명입니다. 중복을 막기 위해 테이블이 수십 개로 갈기갈기 찢어져 있습니다(3NF 정규화).
- 분석용 DB (OLAP / 데이터 웨어하우스): 경영진의 대시보드 서버입니다. 데이터 삽입은 새벽에 한 번 몰아서 하고, 오직 10년 치 데이터 수억 건을
SELECT SUM(매출액)하며 통계(조회)만 미친 듯이 돌립니다. 테이블이 잘게 찢어져 있으면 조인(Join)하다가 날밤을 샙니다.
이 OLAP 환경에서 조인 속도를 극단적으로 끌어올리기 위해 랄프 킴볼(Ralph Kimball)이 창안한 것이 **차원 모델링(스타 스키마)**입니다.
Ⅱ. 팩트(Fact)와 차원(Dimension)의 이원화
차원 모델링은 세상의 모든 데이터를 딱 두 종류로 칼같이 나눕니다.
- 팩트 테이블 (Fact Table) - 중앙의 별의 심장
- 사장님이 궁금해하는 **'진짜 결과 숫자(측정값)'**가 들어가는 거대한 테이블입니다.
- 예:
판매 수량,결제 금액,할인액. 그리고 주변 차원들과 연결될 수많은 외래 키(FK) 번호들만 꽉꽉 채워져 있습니다.
- 차원 테이블 (Dimension Table) - 별의 뾰족한 가지들
- 저 팩트(숫자)를 **"어떤 관점(각도)에서 썰어 볼 것인가?"**를 나타내는 기준 정보들입니다.
- 예: 시간 차원(2024년 1분기), 매장 차원(강남점, 부산점), 상품 차원(남성용 패딩), 고객 차원(30대 여성).
Ⅲ. 스타 스키마 (Star Schema)
가장 대표적이고 완벽한 차원 모델링 구조입니다.
- 구조: 가운데에 무겁고 뚱뚱한 **'팩트 테이블'**을 하나 박아둡니다. 그리고 그 주변에 '차원 테이블(시간, 고객, 상품, 매장)' 4개를 위성처럼 딱 한 번의 깊이(1-Depth)로만 조인되도록 빙 둘러 배치합니다. 그림을 그리면 완벽한 불가사리(별, Star) 모양이 됩니다.
- 특징 (반정규화의 극한): 가지에 달린 차원 테이블들은 더 이상 정규화(쪼개기)를 하지 않고 뚱뚱한 채로 내버려 둡니다(비정규화).
- 장점: 사장님이 쿼리를 치면, 가운데 팩트 테이블을 중심으로 단 1번의 얕은 조인(Join)만 타고 가지로 나가면 모든 통계 데이터를 1초 만에 끌고 올 수 있습니다. 쿼리 작성이 직관적이고 극도로 빠릅니다.
Ⅳ. 스노우플레이크 스키마 (Snowflake Schema)
- 스타 스키마의 가지 끝에 달린 차원 테이블이 너무 뚱뚱해서 꼴 보기 싫을 때, 그 **차원 테이블만 한 번 더 정규화해서 가지치기(쪼개기)**를 해놓은 구조입니다.
- 모양이 별을 넘어서 눈송이(Snowflake)처럼 복잡하게 가지를 칩니다.
- 장점: 중복 데이터가 줄어 디스크 용량을 아낍니다.
- 단점: 통계를 뽑으려면 조인(Join)을 2번, 3번 타고 들어가야 해서 스타 스키마보다 검색 속도가 느려집니다. 실무에서는 보통 스타 스키마를 더 사랑합니다.
📢 섹션 요약 비유: 스타 스키마는 횟집의 '회(팩트)와 4가지 소스(차원)' 상차림입니다. 한가운데에 메인 요리인 어마어마한 양의 회(팩트 테이블: 매출액, 수량)를 크게 썰어두고, 주변에 초장(시간), 간장(매장), 쌈장(상품), 와사비(고객)라는 딱 4개의 소스 그릇(차원 테이블)을 둘러놓습니다. 사장님은 회를 한 점 집어서(조회) 어떤 소스에 찍어 먹든(어떤 관점으로 분석하든) 단 1번의 젓가락질(1번의 조인)만으로 가장 맛있게 통계를 씹어 먹을 수 있는 최적화된 플레이팅입니다.