서서히 변화하는 차원
Slowly changing dimension |
데이터 관리 및 데이터 웨어하우징에서 느리게 변화하는 차원(SCD)은 정기적인 [1]일정에 따라 변화하는 것이 아니라 느리지만 예측할 수 없는 비교적 정적인 데이터를 포함하는 차원입니다.일반적으로 서서히 변화하는 치수의 예로는 지리적 위치, 고객 또는 제품의 이름으로 엔티티를 들 수 있습니다.
일부 시나리오에서는 참조 무결성 문제가 발생할 수 있습니다.
예를 들어 데이터베이스에는 판매 레코드를 저장하는 팩트 테이블이 포함될 수 있습니다.이 팩트 테이블은 외부 키를 사용하여 치수에 연결됩니다.이러한 차원 중 하나에는 회사의 영업 사원에 대한 데이터가 포함될 수 있습니다. 예를 들어, 영업 사원이 근무하는 지역 사무소 등이 포함됩니다.그러나 영업 사원들은 지역 사무소에서 다른 지사로 전근되는 경우가 있습니다.과거의 판매 보고를 위해서, 특정의 판매 담당자가 특정의 지역 오피스에 조기에 배치되어 있던 것을 기록해 둘 필요가 있는 경우가 있습니다만, 그 판매 담당자는 현재는 다른 지역 [clarification needed]오피스에 배치되어 있습니다.
이러한 문제에 대처하려면 타입 0 ~6으로 불리는SCD 관리 방법이 필요합니다.타입 6 SCD는 하이브리드SCD라고도 불립니다
유형 0: 원본 유지
유형 0 차원 속성은 변경되지 않으며 내구 값이 있거나 'Original'로 설명되는 속성에 할당됩니다.예: 생년월일, 원본 신용 점수.유형 0은 대부분의 날짜 차원 [2]속성에 적용됩니다.
유형 1: 덮어쓰기
이 메서드는 오래된 데이터를 새 데이터로 덮어쓰기 때문에 이력 데이터는 추적하지 않습니다.
공급업체 표의 예:
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 |
|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA |
위의 예에서는 Supplier_Code가 자연키이고 Supplier_Key가 대리키입니다.행은 자연키(Supply_Code)에 의해 고유하기 때문에 기술적으로 대리 키는 필요하지 않습니다.
공급업체가 본사를 일리노이주로 이전할 경우 기록이 덮어쓰게 됩니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 |
|---|---|---|---|
| 123 | ABC | ACME 서플라이 | IL |
Type 1 방식의 단점은 데이터 웨어하우스에 이력이 없다는 것입니다.단, 유지보수가 용이하다는 장점이 있습니다.
공급업체 주별로 사실을 요약한 집계 표를 계산한 경우, 공급업체_주가 변경될 [1]때 다시 계산해야 합니다.
유형 2: 새 행 추가
이 메서드는 개별 대리 키 및/또는 다른 버전 번호를 사용하여 치수 테이블에 특정 자연 키에 대한 여러 레코드를 생성하여 이력 데이터를 추적합니다.각 삽입에 대해 무제한 이력이 보존됩니다.
예를 들어 공급업체가 일리노이주로 이전하는 경우 버전 번호가 순차적으로 증가합니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 | 버전 |
|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA | 0 |
| 124 | ABC | ACME 서플라이 | IL | 1 |
또 다른 방법은 '유효 날짜' 열을 추가하는 것입니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 | 시작_날짜 | 종료_날짜 |
|---|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA | 2000-01-01T00:00:00 | 2004-12-22T00:00:00 |
| 124 | ABC | ACME 서플라이 | IL | 2004-12-22T00:00:00 | NULL |
두 번째 행의 시작 날짜/시간은 이전 행의 종료 날짜/시간과 동일합니다.두 번째 행의 null End_Date는 현재 태플 버전을 나타냅니다.대신 표준화된 대리 하이 날짜(예를 들어 9999-12-31)를 종료 날짜로 사용할 수 있으므로 필드가 인덱스에 포함될 수 있고 쿼리 시 늘 값 치환이 필요하지 않습니다.
그리고 세 번째 방법은 유효 날짜와 현재 플래그를 사용합니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 | 유효_날짜 | Current_플래그 |
|---|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA | 2000-01-01T00:00:00 | N |
| 124 | ABC | ACME 서플라이 | IL | 2004-12-22T00:00:00 | Y |
Current_Flag 값 'Y'는 현재 태플 버전을 나타냅니다.
그런 다음 특정 대리 키(Supplier_Key)를 참조하는 트랜잭션은 느리게 변화하는 차원 테이블의 해당 행에 의해 정의된 시간 슬라이스에 영구적으로 바인딩됩니다.공급업체 상태별로 사실을 요약한 집계 표에는 과거 상태, 즉 공급업체가 거래 당시 상태, 즉 업데이트가 필요하지 않은 상태가 계속 반영된다.자연키를 통해 엔티티를 참조하려면 DBMS에 의한 참조 정합성을 불가능하게 하는 고유한 제약조건을 제거해야 합니다.
차원의 내용에 소급변경이 있거나 이미 정의된 것과 다른 시행일이 있는 차원에 새로운 속성(예: Sales_Rep 열)이 추가되면 기존 트랜잭션을 갱신하여 새로운 상황을 반영해야 할 수 있습니다.이것은 고가의 데이터베이스 조작이 될 가능성이 있기 때문에 치수 모델이 자주 [1]변경되는 경우에는 타입2 SCD는 권장하지 않습니다.
유형 3: 새 속성 추가
이 메서드는 개별 열을 사용하여 변경을 추적하고 제한된 이력을 유지합니다.유형 3은 기록 데이터를 저장하도록 지정된 열 수로 제한되므로 제한된 이력을 유지합니다.유형 1과 유형 2의 원래 테이블 구조는 동일하지만 유형 3은 열을 추가합니다.다음 예제에서는 공급업체의 원래 상태를 기록하기 위해 표에 열을 추가하고 이전 기록만 저장합니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 원본_공급자_상태 | 유효_날짜 | 현재_공급자_상태 |
|---|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA | 2004-12-22T00:00:00 | IL |
이 기록에는 원래 상태와 현재 상태에 대한 열이 포함되어 있습니다. 공급업체가 두 번째로 이전할 경우 변경 사항을 추적할 수 없습니다.
이 변경 중 하나는 Original_Supplier_State 대신 Previous_Supplier_State 필드를 작성하는 것입니다.이 필드는 가장 최근의 이력 [1]변경만 추적합니다.
유형 4: 이력 테이블 추가
유형 4 방식은 보통 "이력 테이블" 사용으로 불리며, 여기서 1개의 테이블은 현재 데이터를 보관하고 추가 테이블은 일부 또는 모든 변경 사항을 기록하기 위해 사용됩니다.쿼리 성능을 향상시키기 위해 두 개의 대리 키가 팩트 테이블에서 참조됩니다.
다음 예에서는 원래 테이블 이름은 공급업체이고 이력 테이블은 공급업체입니다.이력:
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 |
|---|---|---|---|
| 124 | ABC | Acme & Johnson Supply Co. | IL |
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 | Create_Date |
|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA | 2003-06-14T00:00:00:00 |
| 124 | ABC | Acme & Johnson Supply Co. | IL | 2004-12-22T00:00:00 |
이 방법은 데이터베이스 감사 테이블 및 변경 데이터 캡처 기술의 작동 방식과 유사합니다.
타입 5
타입 5 기술은 타입 1 속성으로 덮어쓰기되는 베이스 치수에 "현재 프로파일" 미니 치수 키를 내장함으로써 타입 4 미니 치수를 기반으로 구축됩니다.이 접근방식은 4+1이 5이기 때문에 타입 5라고 불립니다.천천히 변화하는 타입 5에서는 팩트테이블을 통해 링크하지 않고 현재 할당되어 있는 미니 치수 속성 값에 기본 치수의 다른 속성 값과 함께 액세스할 수 있습니다.논리적으로 우리는 일반적으로 프레젠테이션 레이어에서 기본 치수 및 현재 미니 치수 프로파일 아웃리거를 단일 테이블로 나타냅니다.아웃리거 속성은 "Current Income Level(현재 소득 수준)"과 같은 고유한 열 이름을 사용하여 팩트 테이블에 연결된 미니 차원의 속성과 구별해야 합니다.ETL 팀은 시간이 지남에 따라 현재 미니 치수가 변경될 때마다 유형 1 미니 치수 기준을 업데이트/덮어쓰기해야 합니다.아웃리거 접근방식이 만족스러운 쿼리 성능을 제공하지 못할 경우 미니 치수 속성을 기본 [3]치수에 물리적으로 포함(및 업데이트)할 수 있다.
타입 6: 복합 어프로치
유형 6 방법은 유형 1, 2, 3(1 + 2 + 3 = 6)의 접근 방식을 결합합니다.이 용어의 기원에 대한 한 가지 가능한 설명은 랄프 킴볼이 칼리도의 스티븐[citation needed] 페이스와 대화하는 동안 이 용어가 만들어졌다는 것이다.Ralph Kimball은 Data Warehouse [1]Toolkit에서 이 방법을 "단일 버전 오버레이로 예측할 수 없는 변경 사항"이라고 부릅니다.
공급업체 표는 샘플 공급업체에 대한 하나의 레코드로 시작합니다.
| 공급자_키 | 행_키 | 공급업체_코드 | 공급업체_이름 | 현재_상태 | 이력_상태 | 시작_날짜 | 종료_날짜 | Current_플래그 |
|---|---|---|---|---|---|---|---|---|
| 123 | 1 | ABC | ACME 서플라이 | CA | CA | 2000-01-01T00:00:00 | 9999-12-31T23:59:59 | Y |
Current_State와 Historical_State는 동일합니다.옵션의 Current_Flag 속성은 이것이 이 공급업체의 현재 또는 최신 레코드임을 나타냅니다.
Acme Supply Company가 일리노이주로 이전하면 타입 2 처리와 같이 새로운 레코드가 추가됩니다.다만, 각 행에 고유의 키가 포함되어 있습니다.
| 공급자_키 | 행_키 | 공급업체_코드 | 공급업체_이름 | 현재_상태 | 이력_상태 | 시작_날짜 | 종료_날짜 | Current_플래그 |
|---|---|---|---|---|---|---|---|---|
| 123 | 1 | ABC | ACME 서플라이 | IL | CA | 2000-01-01T00:00:00 | 2004-12-22T00:00:00 | N |
| 123 | 2 | ABC | ACME 서플라이 | IL | IL | 2004-12-22T00:00:00 | 9999-12-31T23:59:59 | Y |
첫 번째 레코드(Row_Key = 1)의 Current_State 정보를 Type 1 처리와 같이 새로운 정보로 덮어씁니다.Type 2 처리와 같이 변경을 추적하기 위해 새로운 레코드를 만듭니다.또한 이력을 두 번째 상태 열(Historical_State)에 저장합니다.이 열에는 유형 3 처리가 포함되어 있습니다.
예를 들어 공급업체가 다시 이전할 경우 공급업체 차원에 다른 레코드를 추가하고 Current_State 열의 내용을 덮어씁니다.
| 공급자_키 | 행_키 | 공급업체_코드 | 공급업체_이름 | 현재_상태 | 이력_상태 | 시작_날짜 | 종료_날짜 | Current_플래그 |
|---|---|---|---|---|---|---|---|---|
| 123 | 1 | ABC | ACME 서플라이 | 뉴욕 | CA | 2000-01-01T00:00:00 | 2004-12-22T00:00:00 | N |
| 123 | 2 | ABC | ACME 서플라이 | 뉴욕 | IL | 2004-12-22T00:00:00 | 2008-02-04T00:00:00:00 | N |
| 123 | 3 | ABC | ACME 서플라이 | 뉴욕 | 뉴욕 | 2008-02-04T00:00:00:00 | 9999-12-31T23:59:59 | Y |
유형 2 / 유형 6 팩트 구현
유형 3 속성을 가진 유형 2 대리 키
많은 타입 2 및 타입 6 SCD 구현에서는 팩트 데이터가 데이터 [1]저장소에 로드될 때 자연 키 대신 디멘션의 대리 키가 팩트 테이블에 배치됩니다.대리 키는 유효일과 치수 테이블에서 Start_Date 및 End_Date를 기준으로 특정 팩트레코드에 대해 선택됩니다.이를 통해 팩트 데이터를 해당 시행일에 대한 올바른 치수 데이터에 쉽게 결합할 수 있습니다.
다음은 유형 6 하이브리드 방법을 사용하여 위에서 작성한 공급업체 표입니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 현재_상태 | 이력_상태 | 시작_날짜 | 종료_날짜 | Current_플래그 |
|---|---|---|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | 뉴욕 | CA | 2000-01-01T00:00:00 | 2004-12-22T00:00:00 | N |
| 124 | ABC | ACME 서플라이 | 뉴욕 | IL | 2004-12-22T00:00:00 | 2008-02-04T00:00:00:00 | N |
| 125 | ABC | ACME 서플라이 | 뉴욕 | 뉴욕 | 2008-02-04T00:00:00:00 | 9999-12-31T23:59:59 | Y |
배송 테이블에 올바른 Supplier_Key가 포함되면 해당 키를 사용하여 공급업체 테이블에 쉽게 결합할 수 있습니다.다음 SQL은 각 팩트 레코드에 대해 현재 공급업체 상태 및 공급업체가 제공 시점에 위치한 상태를 검색합니다.
선택한다. 배달..delivery_cost, 공급자..supply_name, 공급자..이력_상태, 공급자..current_state 부터 배달. 내부 합류하다 공급자. 온 배달..supply = 공급자..supply; 순수 타입 6의 실장
각 타임 슬라이스에 타입2 대리 키를 지정하면 치수가 [1]변경될 수 있는 경우 문제가 발생할 수 있습니다.순수한 타입 6 구현에서는 이를 사용하지 않고 각 마스터 데이터 항목에 대해 대리 키를 사용한다(예: 각 고유 공급업체에는 단일 대리 키가 있다).이렇게 하면 기존 트랜잭션 데이터에 영향을 미치는 마스터 데이터의 변경이 방지됩니다.또한 트랜잭션을 쿼리할 때 더 많은 옵션을 사용할 수 있습니다.
다음은 순수한 유형 6 방법을 사용한 공급업체 표입니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 | 시작_날짜 | 종료_날짜 |
|---|---|---|---|---|---|
| 456 | ABC | ACME 서플라이 | CA | 2000-01-01T00:00:00 | 2004-12-22T00:00:00 |
| 456 | ABC | ACME 서플라이 | IL | 2004-12-22T00:00:00 | 2008-02-04T00:00:00:00 |
| 456 | ABC | ACME 서플라이 | 뉴욕 | 2008-02-04T00:00:00:00 | 9999-12-31T23:59:59 |
다음 예시는 각 트랜잭션에 대해 단일 공급업체 레코드를 가져오기 위해 쿼리를 확장해야 하는 방법을 보여 줍니다.
선택한다. 공급자..supply_code, 공급자..supply_state 부터 공급자. 내부 합류하다 배달. 온 공급자..supply = 배달..supply 그리고. 배달..delivery_date >= 공급자..start_date 그리고. 배달..delivery_date < > 공급자..end_date; 2001년 8월 9일 발효일(Delivery_Date)의 팩트 레코드는 ABC의 Supplier_Code와 Supplier_State가 'CA'인 Supplier_Code에 링크됩니다.2007년 10월 11일의 팩트 레코드도 같은 Supplier_Code ABC에 링크되지만 Supplier_State는 'IL'입니다.
이 접근방식은 복잡하지만 다음과 같은 많은 이점이 있습니다.
- 이제 DBMS에 의한 참조 무결성은 가능하지만 제품 테이블에서 Supplier_Code를 외부 키로 사용할 수 없으며 Supplier_Key를 외부 키로 사용할 수 없습니다. 각 제품은 특정 시간 슬라이스에 묶여 있습니다.
- 팩트에 여러 날짜(Order_Date, Delivery_Date, Invoice_Payment_Date 등)가 있는 경우 쿼리에 사용할 날짜를 선택할 수 있습니다.
- 날짜 필터 로직을 변경하여 "현재", "트랜잭션 시간" 또는 "시점" 쿼리를 수행할 수 있습니다.
- 치수 테이블이 변경된 경우(예: 시간 슬라이스를 변경하는 필드를 소급하여 추가하거나 치수 테이블에서 날짜를 잘못 입력한 경우 쉽게 수정할 수 있음) 팩트 테이블을 재처리할 필요가 없습니다.
- 치수 테이블에 양 일시 날짜를 삽입할 수 있습니다.
- 이 사실을 차원 테이블의 여러 버전에 결합하면 동일한 조회에서 다른 유효 날짜의 동일한 정보를 보고할 수 있습니다.
다음은 '2012-01-01T00:00:00'(현재 날짜일 수 있음)과 같은 특정 날짜를 사용하는 예를 보여 줍니다.
선택한다. 공급자..supply_code, 공급자..supply_state 부터 공급자. 내부 합류하다 배달. 온 공급자..supply = 배달..supply 그리고. 공급자..start_date <=> '2012-01-01 T00:00:00:00' 그리고. 공급자..end_date > '2012-01-01 T00:00:00:00'; 유형 7: 하이브리드[4] - 대리 키와 자연 키 모두
대체 구현은 대리 키와 자연 키를 모두 팩트 [5]테이블에 배치하는 것입니다.이를 통해 사용자는 다음을 기준으로 적절한 치수 레코드를 선택할 수 있습니다.
- 팩트 레코드의 주요 시행일(위),
- 최신 또는 최신 정보,
- 팩트 레코드와 관련된 기타 날짜
이 방법을 사용하면 타입 6이 아닌 타입2 방식을 사용한 경우에도 디멘션에 대한 보다 유연한 링크가 가능합니다.
타입 2의 방법을 사용하여 작성했을 가능성이 있는 써플라이어 테이블을 다음에 제시하겠습니다.
| 공급자_키 | 공급업체_코드 | 공급업체_이름 | 공급업체_주 | 시작_날짜 | 종료_날짜 | Current_플래그 |
|---|---|---|---|---|---|---|
| 123 | ABC | ACME 서플라이 | CA | 2000-01-01T00:00:00 | 2004-12-21T00:00:00 | N |
| 124 | ABC | ACME 서플라이 | IL | 2004-12-22T00:00:00 | 2008-02-03T00:00:00:00 | N |
| 125 | ABC | ACME 서플라이 | 뉴욕 | 2008-02-04T00:00:00:00 | 9999-12-31T23:59:59 | Y |
현재 레코드를 가져오려면:
선택한다. 배달..delivery_cost, 공급자..supply_name, 공급자..supply_state 부터 배달. 내부 합류하다 공급자. 온 배달..supply_code = 공급자..supply_code 어디에 공급자..현재_개요 = 'Y'; 이력 레코드를 가져오려면:
선택한다. 배달..delivery_cost, 공급자..supply_name, 공급자..supply_state 부터 배달. 내부 합류하다 공급자. 온 배달..supply = 공급자..supply; 특정 날짜에 따라 이력 레코드를 가져오려면(팩트 테이블에 여러 날짜가 있는 경우)
선택한다. 배달..delivery_cost, 공급자..supply_name, 공급자..supply_state 부터 배달. 내부 합류하다 공급자. 온 배달..supply_code = 공급자..supply_code; 그리고. 배달..delivery_date 사이에 공급자..시작_날짜 그리고. 공급자..종료_날짜 주의사항:
- 관계를 만들기 위한 고유 키가 없으므로 DBMS에 의한 참조 무결성은 불가능합니다.
- 위의 문제를 해결하기 위해 대리인과 관계를 맺으면 특정 시간 슬라이스에 연결된 엔티티로 끝납니다.
- 조인 쿼리가 올바르게 작성되지 않은 경우 중복된 행을 반환하거나 잘못된 답변을 제공할 수 있습니다.
- 날짜 비교가 제대로 수행되지 않을 수 있습니다.
- 일부 비즈니스 인텔리전스 툴은 복잡한 결합 생성을 제대로 처리하지 못합니다.
- 치수표를 작성하는 데 필요한 ETL 프로세스는 각각의 개별 참조 데이터 항목에 대해 기간에 중복이 없도록 주의 깊게 설계해야 한다.
타입의 조합
테이블의 다른 열에 다른 SCD 유형을 적용할 수 있습니다.예를 들어 유형 1을 [Supplier_Name]컬럼에, 유형 2를 [Supplier_State]컬럼에 적용할 수 있습니다.
「 」를 참조해 주세요.
메모들
- ^ a b c d e f g Kimball, Ralph; Ross, Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling.
- ^ "Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7". 5 February 2013.
- ^ "Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7". 5 February 2013.
- ^ Kimball, Ralph; Ross, Margy (July 1, 2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd Edition. John Wiley & Sons, Inc. p. 122. ISBN 978-1-118-53080-1.
- ^ Ross, Margy; Kimball, Ralph (March 1, 2005). "Slowly Changing Dimensions Are Not Always as Easy as 1, 2, 3". Intelligent Enterprise.
