Fact 테이블에서 대리 키(Surrogate key)를 사용할 시의 이점
대리키란, 테이블을 이루는 컬럼들 가운데 유일하게 식별하기에 적합한 단일 후보키가 존재하지 않을 때 추가할 수 있는 임의의 식별번호로 이루어진 후보키(Candidate key)이다.
차원 테이블과는 다르게, 팩트 테이블에선 대리키에 대해 강한 필요성은 없다. 일반적 DW의 백룸(backroom; 사용자에게 보이는 부분이 아닌 시스템 내부를 일컫는다. Kimball은 식당에서의 홀과 주방의 비유를 통해 이를 설명하였다.)인 ETL 작업을 위해 대리키를 적용한다.
팩트 테이블에 대리키를 적용하면 쿼리 성능이 저하되는 대신, 다음과 같은 이점이 있다.
•
즉각적인 unique 식별
ETL 처리 도중 여러 차원을 탐색하지 않아도 특정 행을 식별할 수 있다.
•
데이터 벌크 로드 작업 편의성
DBA가 데이터를 대량으로 로드하는 벌크 작업을 중단 혹은 재개할 때, 로드 작업이 어디까지 진행되었는지 대리키를 통해 특정할 수 있다.
•
팩트 테이블 삽입/삭제 작업
팩트 테이블의 Update 작업을 Insert plus Delete 작업으로 대체할 수 있다. 대량의 갱신 작업의 경우에는 Update 연산 보다는 Insert plus Delete 연산이 더욱 효율적이다.
•
상속 관계의 팩트 테이블
두개의 팩트 테이블을 부모 자식의 상속관계로 사용할 수 있다. 주의할 점은, 팩트 테이블을 다른 팩트 테이블과 직접적으로 조인해선 안된다. 이는 추후에 설명하도록 하겠다.(아직 모르겠음)
정규화 충동 참기 - 눈송이 스키마
차원 모델에서 Dimension 테이블을 정규화 하여 여러 테이블로 쪼개놓은 것을 눈송이 스키마(Snowflake schema)라고 한다. 이러한 확장이 필요할 때도 있지만, 일반적인 몇가지 이유로 스노우플레이킹을 자제해야 한다.
•
차원 모델의 주요 목표는 사용자 편의성이다. 과도한 스노우플레이킹은 사용자의 프레젠테이션을 더욱 복잡하게 만든다. 차원 탐색과 이에 필요한 조인관계 또한 어려워진다.
•
테이블과 조인이 많으면 쿼리 성능이 느려진다. 옵티마이저가 편향될 가능성이 더욱 높아진다.
•
디스크 공간 절약 효과가 미미하다. 데이터 용량의 높은 비중을 갖는것은 팩트테이블이다.
•
스노우플레이킹은 비트맵 인덱스의 사용을 무효화 한다.(아직 모르겠음)
팩트 테이블의 유형
다음 그림과 같이, 비즈니스 요구사항에 따라 같은 데이터에 대해 두, 세 가지 모델이 동시에 적합할 수 있다.
트랜잭션 | 정기 스냅샷 | 누적 스냅샷 | |
주기 | 트랜잭션이 발생하는 시점 | 주기적이고 예측 가능한 시간 간격으로 스냅샷 반복 생성 | 예측 불가능한 파이프라인/워크플로 실행 완료 시간 |
그레인 | 트랜잭션 1당 1개의 행 | 스냅샷 1당 1개의 행과 추가적인 차원 행들 | 파이프라인 실행 1당 1개의 행 |
날짜 차원 | 트랜잭션 날짜 | 스냅샷 날짜 | 파이프라인의 목적(마일스톤)에 따른 여러 날짜 |
팩트 | 트랜잭션 실적 | 시간 간격에 따른 누적 실적 | 파이프라인 실행에 따른 실적 |
팩트 테이블 희소성(sparsity) | 트랜잭션 활동에 따라 높거나 낮음 | 예측 가능하게 높음 | 파이프라인 싱행에 따라 높거나 낮음 |
팩트 테이블 갱신 | 에러 수정이 아닌 이상 갱신 없음 | 에러 수정이 아닌 이상 갱신 없음 | 파이프라인 실행 중 언제든 갱신 가능 |
느린 차원 변경(SCD; Slowly Changing Dimension)
기본적인 접근
Type 0: 원본 유지
•
차원 테이블의 속성값을 변경하지 않고 원본을 유지
•
영구적 내구성이 있는 속성과 키(예로, 가입 시점 신용 등급)에 적합
Type 1: 차원 테이블 행 덮어쓰기
•
이전 속성을 현재의 최신 값으로 대체
•
과거 값을 알 필요가 없는 경우 적합
•
배포되어있는 OLAP 큐브를 갱신 때 마다 재집계 해야할 수 있음
Type 2: 차원 테이블에 새로운 행 추가
•
새로운 속성 집합을 새로운 행으로 추가
•
동일한 자연키가 이미 존재하기 때문에 유일키로 사용 불가
•
행 유효기간(e.g. 최신 데이터는 9999-12-31), 만료 일, 유효성 플래그 속성을 추가하여 Type 1의 전략과 함께 사용 가능
Type 3: 차원 테이블에 새로운 속성 추가
•
새 열을 추가하여 기존 속성 값을 채운 후, 기존 속성 열을 새 속성 값으로 교체
•
차원 테이블의 수많은 행에 영향을 끼치는 변경이 있는 경우, 현재와 과거의 속성 값들이 동시에 분석했을 때 유용한 지표일 경우 적합
•
배포되어있는 OLAP 큐브를 갱신 때 마다 재집계 해야할 수 있음
Type 4: 팩트 테이블에 미니 차원 추가
•
자주 분석되거나 변경되는 속성들을 별도의 다른 차원으로 분리
•
자주 사용하는 필터 범위나 이산적인 값들의 조합을 미리 집계한 미니 차원을 사용
예시
•
빠르게 변화하는 속성값을 가진 대규모 차원 테이블에 적합
•
저장용량을 줄이고 팩트테이블 트랜잭션 시점 이력을 기준으로 매번 Join하는 불필요한 쿼리비용을 감소시킬 수 있음
참고
Type 0~4를 조합한 하이브리드적 접근
하이브리드 기법은 종종 두가지 유형의 장점을 모두 취한것 처럼 볼 수 있지만, 그에 따른 대가는 큰 복잡성이다. 비즈니스의 요구사항을 해결하는 데 이러한 옵션이 필요하다고 동의하지 않는 한 아래의 옵션을 추구해서는 안된다.
Type 5
•
Type 4와 Type 1 아웃트리거를 결합한 유형
•
Type 6
Type 7
