느린 변경 차원

3. SCD 유형

SCD(Slowly Changing Dimension, 느린 변경 차원)는 데이터 변경을 처리하는 방식에 따라 여러 유형으로 나뉜다.

• Type 1: 덮어쓰기 - 오래된 데이터를 새 데이터로 덮어쓰는 방식으로, 과거 데이터를 추적하지 않는다. 유지 관리가 쉽지만, 데이터 웨어하우스에 기록이 남지 않는다.^[1]
• Type 2: 새 행 추가 - 데이터가 변경될 때마다 새로운 행을 추가하여 변경 이력을 추적한다. 자연 키와 대체 키를 함께 사용하며, 각 레코드의 유효 기간을 나타내기 위해 시작 날짜, 종료 날짜 또는 버전 번호를 사용한다.^[1]
• Type 3: 새 열 추가 - 별도의 열을 추가하여 변경 사항을 추적하지만, 지정된 열의 수만큼만 기록을 보존할 수 있다. 예를 들어, 원래 상태와 현재 상태를 기록하는 열을 추가할 수 있지만, 두 번 이상의 변경은 추적할 수 없다.^[1]
• Type 4: 히스토리 테이블 추가 - 현재 데이터를 유지하는 테이블과 변경 이력을 기록하는 별도의 히스토리 테이블을 사용하는 방식이다. 쿼리 성능 향상을 위해 두 테이블 모두에서 대체 키를 참조한다.^[1]
• Type 5: Type 4 + Type 1 - Type 4 미니 차원을 기반으로, Type 1 속성으로 덮어쓰여지는 "현재 프로필" 미니 차원 키를 기본 차원에 내장하는 방식이다. 팩트 테이블을 거치지 않고도 현재 할당된 미니 차원 속성 값과 기본 차원의 다른 속성 값에 접근할 수 있다.^[3]
• Type 6: Type 1 + Type 2 + Type 3 - Type 1, 2, 3 방식을 모두 결합한 방식이다. 랄프 킴볼은 이 방식을 "단일 버전 오버레이를 사용한 예측 불가능한 변경"이라고 불렀다.^[1]

3. 1. Type 0: 원본 유지

3. 2. Type 1: 덮어쓰기

위의 예에서 Supplier_Code는 자연 키이고, Supplier_Key는 대리 키이다. 기술적으로, 자연 키(Supplier_Code)로 행이 고유하므로 대리 키는 필요하지 않다.

만약 공급업체가 본사를 일리노이로 이전하면 레코드가 다음과 같이 덮어쓰여진다.

Type 1 방법은 데이터 웨어하우스에 기록이 없다는 단점이 있지만, 유지 관리가 쉽다는 장점이 있다.

공급업체 주별로 팩트를 요약하는 집계 테이블을 계산한 경우에는 Supplier_State가 변경되면 다시 계산해야 한다.^[1]

3. 3. Type 2: 새 행 추가

위의 표에서 "공급업체 코드"(ABC)는 자연 키 역할을 한다.

'유효 날짜' 열을 추가하여 변경 이력을 관리할 수도 있다.

두 번째 행의 시작 날짜는 이전 행의 종료 날짜와 같고, 종료 날짜가 없는 것은 현재 유효한 레코드임을 의미한다. 종료 날짜에 9999-12-31과 같은 표준화된 대체 높은 날짜를 넣어 빈 값 사용을 피할 수도 있다.

유효 날짜와 현재 플래그를 함께 사용하는 방법도 있다.

현재 플래그가 'Y'이면 해당 레코드가 현재 유효한 버전임을 나타낸다.

Type 2 방식은 특정 대체 키(공급업체 키)를 참조하는 트랜잭션이 해당 시간 슬라이스에 영구적으로 고정되도록 한다. 따라서 과거 데이터를 정확하게 반영할 수 있다. 그러나 차원 내용에 소급 변경이 있거나 새 속성이 추가되는 경우에는 기존 트랜잭션을 업데이트해야 할 수도 있어서, 변경이 잦은 경우에는 적합하지 않다.^[1]

3. 4. Type 3: 새 열 추가

이 기록에는 원래 상태와 현재 상태에 대한 열이 포함되어 있다. 하지만 공급업체가 두 번째로 이전하는 경우에는 변경 사항을 추적할 수 없다.

이 방법의 한 가지 변형은 Original_Supplier_State 대신 Previous_Supplier_State 필드를 생성하여 가장 최근의 기록 변경 사항만 추적하는 것이다.^[1]

3. 5. Type 4: 히스토리 테이블 추가

이 방법은 데이터베이스 감사 테이블 및 변경 데이터 캡처 기술의 기능과 유사하다.^[1]

3. 6. Type 5: Type 4 + Type 1

3. 7. Type 6: Type 1 + Type 2 + Type 3

Current_State와 Historical_State는 동일하다. 선택적 Current_Flag 속성은 이것이 이 공급업체의 현재 또는 가장 최근 레코드임을 나타낸다.

Acme Supply Company가 일리노이 주로 이사할 경우, Type 2 처리와 같이 새로운 레코드를 추가하지만, 각 행에 고유한 키가 있는지 확인하기 위해 행 키가 포함된다.

Type 1 처리와 같이 첫 번째 레코드(Row_Key = 1)의 Current_State 정보를 새로운 정보로 덮어쓴다. Type 2 처리와 같이 변경 사항을 추적하기 위해 새로운 레코드를 생성한다. 그리고 Type 3 처리를 통합하는 두 번째 State 열(Historical_State)에 기록을 저장한다.

예를 들어, 공급업체가 다시 이사하게 될 경우, 공급업체 차원에 다른 레코드를 추가하고 Current_State 열의 내용을 덮어쓴다.

4. 팩트 테이블 구현

팩트 테이블은 느린 변경 차원(SCD)을 참조하여 데이터 저장소에 로드될 때, 차원의 자연 키 대신 대리 키를 사용한다.^[1] 대리 키는 유효 날짜와 차원 테이블의 시작 날짜 및 종료 날짜를 기반으로 선택되어, 팩트 데이터를 해당 유효 날짜에 맞는 올바른 차원 데이터에 쉽게 연결(join)할 수 있게 한다.

유형 2 및 유형 6 SCD(Slowly Changing Dimension, 변경되지 않는 차원) 구현 방식과 순수 Type 6 구현 방식이 있으며, 유형에 따라 차원의 대리 키를 활용하는 방식과 장단점이 다르다.

4. 1. Type 2/Type 6 팩트 구현

배송 테이블에 올바른 공급업체_키가 포함되면 해당 키를 사용하여 공급업체 테이블에 쉽게 결합(join)할 수 있다.

4. 2. 순수 Type 6 팩트 구현

각 거래에 대해 단일 공급업체 레코드를 검색하기 위한 쿼리는 다음과 같이 확장할 수 있다.



SELECT

supplier.supplier_code,

supplier.supplier_state

FROM supplier

INNER JOIN delivery

ON supplier.supplier_key = delivery.supplier_key

AND delivery.delivery_date >= supplier.start_date AND delivery.delivery_date < supplier.end_date;



2001-08-09T00:00:00^영어의 유효 날짜(Delivery_Date)가 있는 팩트 레코드는 'CA'의 Supplier_State와 함께 ABC의 Supplier_Code에 연결된다. 2007-10-11T00:00:00^영어의 유효 날짜가 있는 팩트 레코드는 동일한 Supplier_Code ABC에 연결되지만 'IL'의 Supplier_State에 연결된다.

이 접근 방식은 더 복잡하지만 다음과 같은 여러 장점이 있다.

# DBMS에 의한 참조 무결성이 가능해진다. Product 테이블에서 Supplier_Code를 외래 키로 사용할 수는 없지만, 각 제품이 특정 시간 슬라이스에 묶여 있는 Supplier_Key를 외래 키로 사용할 수 있다.

# 팩트에 날짜가 둘 이상 있는 경우(예: Order_Date, Delivery_Date, Invoice_Payment_Date) 쿼리에 사용할 날짜를 선택할 수 있다.

# 날짜 필터 로직을 변경하여 "현재 시점", "거래 시점", "특정 시점" 쿼리를 수행할 수 있다.

# 차원 테이블에 변경 사항이 있는 경우 팩트 테이블을 다시 처리할 필요가 없다. 예를 들어 시간 슬라이스를 변경하는 추가 필드를 소급하여 추가하거나, 차원 테이블의 날짜에 실수를 한 경우 쉽게 수정할 수 있다.

# 이중 시간적 날짜를 차원 테이블에 도입할 수 있다.

# 동일한 쿼리에서 서로 다른 유효 날짜로 동일한 정보를 보고할 수 있도록 팩트를 차원 테이블의 여러 버전과 조인할 수 있다.

다음은 '2012-01-01T00:00:00^영어'(현재 datetime일 수 있음)과 같은 특정 날짜를 사용하는 방법의 예시이다.



SELECT

supplier.supplier_code,

supplier.supplier_state

FROM supplier

INNER JOIN delivery

ON supplier.supplier_key = delivery.supplier_key

AND supplier.start_date <= '2012-01-01T00:00:00' AND supplier.end_date > '2012-01-01T00:00:00';

5. 유형 결합

6. 한국적 맥락에서의 SCD

한국 기업들은 데이터 기반 의사 결정을 강화하면서, 느린 변경 차원(SCD)을 활용한 데이터 웨어하우스 구축에 대한 관심이 높아지고 있다. 급변하는 시장 환경과 소비자 트렌드에 대응하기 위해, Type 2, Type 6와 같이 변경 이력을 상세히 추적하는 방식이 선호되는 경향이 있다. 금융, 유통, 통신 등 다양한 산업 분야에서 고객 데이터, 상품 데이터, 계약 데이터 등의 변화를 관리하고 분석하는 데 SCD가 활용되고 있다.
정부 정책 변화에 따른 데이터 관리: 정부 정책 변화에 따라 기업은 관련 데이터를 신속하고 정확하게 변경하고 관리해야 한다. 예를 들어, 새로운 개인정보보호 규정이 시행되면 기업은 고객 데이터 처리 방식을 변경하고, 이 변경 이력을 SCD를 통해 관리해야 한다. 이러한 관리는 특히 Type 2 (새 행 추가) 방식을 통해 효과적으로 이루어질 수 있다.
인물 정보 관리의 복잡성: 한국의 정치적, 사회적 환경은 인물 정보 관리에 있어 더욱 복잡한 요구사항을 제시한다. 예를 들어, 정치인이나 고위 공직자의 경우, 소속 정당, 직위, 정책 입장 등이 시간에 따라 변경될 수 있으며, 이러한 변경 이력은 투명하게 관리되어야 한다. Type 6 (Type 1 + Type 2 + Type 3) 방식은 이러한 복잡한 변경 이력을 효과적으로 관리할 수 있는 방법을 제공한다.

7. 한계점

느린 변경 차원(SCD)은 설계 및 구현이 복잡하다는 단점이 있다. 특히, Type 2와 Type 6 방식은 변경 이력을 모두 저장하므로 데이터 저장 공간을 많이 차지한다. 또한, 쿼리 시에 최신 데이터를 판별하거나 변경 이력을 추적해야 하므로 쿼리 성능 저하를 유발할 수 있다. 데이터 정합성 유지를 위한 추가적인 노력이 필요하다는 점도 한계점으로 지적된다.^[1][2]

참조

_[1] 서적 The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling
_[2] 웹사이트 Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7 https://www.kimballg[...] 2013-02-05
_[3] 웹사이트 Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7 https://www.kimballg[...] 2013-02-05
_[4] 서적 The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd Edition John Wiley & Sons, Inc 2013-07-01
_[5] 간행물 Slowly Changing Dimensions Are Not Always as Easy as 1, 2, 3 http://intelligent-e[...] 2005-03-01