SCD(Slowly Changing Dimensions) 개념

2026. 3. 8. 18:15·3. Data Engineering/ㅤ📘 데이터 웨어하우스

# 탄생 배경

전통적인 운영 시스템(OLTP)은 데이터의 최신 상태를 유지하는 데 집중한다.
그러나 의사결정 지원 시스템이나 데이터 웨어하우스 환경에서는 '과거의 특정 시점에 데이터가 어떠했는가'라는 시계열적 관점이 필수적이다.

예를 들어, 고객의 거주지가 서울에서 부산으로 변경되었을 때, OLTP 시스템은 단순히 주소를 업데이트하면 그만이지만,
데이터 마트에서는 부산으로 이주하기 전 서울에서 발생시킨 매출 이력을 여전히 서울 지역 실적으로 집계할 수 있어야 한다.
이러한 이력 보존의 필요성과 데이터 중복 최소화 사이의 균형을 맞추기 위해 랄프 킴벌(Ralph Kimball)에 의해 SCD 개념이 정립되었다.

# 동작 원리

SCD의 핵심은 차원 테이블의 속성 변화를 감지하고, 정의된 정책에 따라 테이블 구조를 갱신하는 프로세스에 있다.

Type 0: Retain Original (원본 유지)

한 번 입력된 데이터는 변경되지 않는다고 가정한다.
주로 생년월일이나 최초 가입일처럼 변하지 않아야 할 속성에 적용된다. 
시스템 관점에서는 Update 프로세스가 원천적으로 차단된다.

Type 1: Overwrite (덮어 쓰기)

변경이 발생하면 기존 값을 지우고 새 값을 입력한다. (덮어쓰기)
이력이 남지 않으므로 과거 시점의 리포트를 재생성할 경우 결과값이 달라지는 비결정론적 특성을 갖는다.
저장 공간 효율은 높으나 데이터 분석 측면에서는 정보 손실이 크다.

Type 2: Add New Row (새 행 추가)

데이터 변경 시 기존 행은 마감(Expired) 처리를 하고 새로운 행을 삽입한다.
이를 위해 Effective_Date(유효일), Expiraton_Date(만료일), Current_Flag와 같은 메타데이터 컬럼이 추가된다.

 

Type 3: Add New Attribute ( 새 속성 추가 )

현재 속성값과 이전 속성값을 동시에 나타낸다는 점에서 유형2 와 구별된다.
단, 고객의 거주지와 같은 예측 불가능한 변화값의 경우에는 유용하지 않다. (Type 2 권장)

 

Type 4: Add Mini-Dimension (미니 차원 추가)

만약, 대용량 차원테이블에서 데이터가 변경되어야 한다면 어떻게 해야 할까?
기존의 Type 2 방식(변경될 때마다 새로운 행을 추가하여 이력을 관리하는 방식)을 사용하면, 
이미 수백만 건인 테이블에 데이터가 기하급수적으로 늘어나게 된다. 이는 결국 데이터 검색 및 필터링 성능을 크게 떨어뜨린다.

이러한 문제를 해결하기 위해 자주 분석되거나 자주 변하는 속성들만 따로 떼어내어 새로운 작은 테이블(미니 차원)을 만드는 것이 해결책이다.

- 정적 데이터와 동적 데이터의 분리: 이름, 생년월일 같은 거의 변하지 않는 속성은 수백만 건의 본래 고객 테이블에 그대로 둔다.
- 인구통계학적 프로필 생성: 연령대, 소득 수준, 구매 빈도 점수 등 자주 변하는 속성들을 모아 미니 차원을 만든다.
- 고객당 1행이 아님: 미니 차원은 고객 수만큼 행을 가지는 것이 아니라, 각 속성들의 '고유한 조합(프로필)'마다 하나의 행을 가진다.
 따라서 본래 고객 테이블이 수백만 건이라도, 미니 차원의 행 수는 훨씬 적게 유지할 수 있다.
- 연속적인 변수(예: 정확한 소득 금액)를 사전에 정의된 대역(Band)으로 그룹화

 

 

 


책에서는 하이브리드 버전 Type 7 까지 소개하고 있다.

Type 5: Mini-Dimension and Type 1 Outrigger
Type 6: Add Type 1 Attributes to Type 2 Dimension
Type 7: Dual Type 1 and Type 2 Dimensions

 

# 요약

 

 

참고 자료: The Data Warehouse Toolkit, 3rd Edition

저작자표시 비영리 변경금지 (새창열림)

'3. Data Engineering > ㅤ📘 데이터 웨어하우스' 카테고리의 다른 글

대용량 로그 기반 데이터 마트를 설계하며 배운 것  (0) 2026.06.01
데이터 정합성 검증 방법  (0) 2026.03.08
iceberg , 아이스버그 개념 및 아키텍처  (0) 2026.02.28
[Parquet 공식문서] 파케이 개념 및 아키텍처  (0) 2026.02.28
Airflow, 에어플로우의 기본 개념  (0) 2026.02.25
'3. Data Engineering/ㅤ📘 데이터 웨어하우스' 카테고리의 다른 글
  • 대용량 로그 기반 데이터 마트를 설계하며 배운 것
  • 데이터 정합성 검증 방법
  • iceberg , 아이스버그 개념 및 아키텍처
  • [Parquet 공식문서] 파케이 개념 및 아키텍처
HC.21
HC.21
hc-log 님의 블로그 입니다.
  • HC.21
    HC
    HC.21
  • 전체
    오늘
    어제
    • 분류 전체보기 (45) N
      • 1. AI (7)
      • 2. DB, DBA (19)
        • ㅤ📙 SQL (4)
        • ㅤ📘 SQL SERVER (11)
        • ㅤ📗 MYSQL (3)
        • ㅤ📒 MongoDB (1)
        • ㅤ📝 튜닝, 트러블슈팅 (0)
        • ㅤ📝 운영, 모니터링 (0)
      • 3. Data Engineering (14) N
        • ㅤ📙 데이터 아키텍처 (3) N
        • ㅤ📘 데이터 웨어하우스 (10)
        • ㅤ📗 데이터 파이프라인 (0)
      • 4. Project (4)
        • ㅤ📝 개인 프로젝트 (4)
      • 5. Learning Logs (1)
        • ㅤ📚 학습 기록 (1)
        • ㅤ📚 책, 강의 리뷰 (0)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    파케이
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.0
HC.21
SCD(Slowly Changing Dimensions) 개념
상단으로

티스토리툴바