Basic Dimension Table Techniques
Dimension Table Structure
•
모든 디멘젼 테이블은 싱글 PK를 가지고 있습니다.
•
이 PK는 팩트 테이블의 행의 컨텍스트를 이해할 수 있는 키로 이용됩니다.
•
일반적으로 넓고, 비정규화된 카디널리티가 낮은 테이블입니다.
Dimension Surrogate Keys
•
디멘젼 테이블은 기본적으로 컬럼 하나가 유니크한 PK로 동작하도록 설계되었습니다.
•
이 PK는 운영상의 자연키가 될 수 없는데 이유는 시간이 지남에 따라 변경 사항을 추적할 때 해당 기본 키에 대한 여러 차원 행이 있기 때문입니다.
◦
디멘젼에 변경사항이 있어도 해당 테이블의 자연키는 그대로이고 거기에 딸린 속성들만 변하기 때문
•
따라서 모든 디멘젼에 대해 따로 PK가 필요합니다.
•
Dimension Surrogate Keys는 순서에 따른 정수가 될 수 있습니다.
◦
dbt에서는 컬럼을 이용하여 surrogate key를 만들 수 있습니다.
•
날짜 차원은 이러한 규칙이 필요 없습니다.
Natural, Durable, and Supernatural Keys
•
Natural keys(자연키)는 DW/BI와 상관없이 운영 상 필요한 키입니다.
◦
예를 들어, 사원번호는 사원이 퇴사하거나 재고용 된다면 바뀌게 됩니다.
•
DW에서 해당 사원에 대해 단일 키를 사용하려면 영구적이고 변경되지 않는 Durable key를 만들어야 합니다.
◦
durable supernatural key라고 부르기도 합니다.
◦
만약 사원번호가 바뀌게 된다면 디멘젼 테이블과 연관된 팩트 테이블의 FK도 전부 바뀌어야 하는 문제가 있습니다.
◦
이를 위해 DW에서만 사용하는 절대 변하지 않는 디멘젼 키를 만드는 것이 좋습니다.
•
최선의 Durable key는 비즈니스 프로세스와는 상관없는 포맷을 가지고 있습니다.
•
surrogate keys는 만약 사원의 프로필이 시간이 지남에 따라 바뀐다면 변하지만 durable key는 절대 변하지 않습니다.
Drilling Down
•
드릴 다운은 데이터를 분석할 때 가장 기본적인 방법입니다.
•
존재하는 쿼리에 헤더를 추가하는 것을 말하는데, 여기서 헤더는 디멘젼 속성을 말합니다.
◦
SELECT MANUFACTURER, SUM(SALES) → SELECT MANUFACTURER, BRAND, SUM(SALES)
◦
즉, GROUP BY 할 속성을 더 추가하는 것을 말합니다.
•
속성은 팩트 테이블과 연관된 어떤 디멘젼도 가능합니다.
Degenerate Dimensions
•
팩트 테이블은 measure만 있는 것이 아니라 디멘전이 존재할 수도 있는데 이를 Degenerate Dimensions라고 합니다.
•
예를 들어 고객 구매 상태 이력이 자동 혹은 수동이 있다고 가정해보겠습니다.
◦
상태가 2개 밖에 없기 때문에 디멘젼이 아니라 팩트 테이블에 해당 속성을 넣을 수도 있습니다.
•
상태 이력 Fact에 있는 경우
1.
A모델처럼 상태이력을 팩트에 넣을 수 있는데 이를 Degenerate Dimensions이라고 합니다.
a.
단순하지만 팩트 크기에 영향을 미친다
b.
규칙이 바뀌면 관리가 어려워질 수 있다
2.
B모델처럼 디멘젼으로 빠져나올 수도 있습니다.
a.
팩트의 크기를 줄이고, 코드화할 수 있다는 것이 장점이지만 모델 자체는 조금 더 복잡해집니다.
•
상태 이력 Dimension에 있는 경우
◦
여러 디멘젼에 넣을 수 있겠지만 어디에 배치할 것인지는 잘 고려해야 합니다.
◦
예를 들어 고객, 날짜 디멘젼은 범용성이 매우 높고, 고객과 같은 차원은 Row수가 매우 많은 대형차원이므로 이를 뻥튀기 한다면 매우 큰 부담이 될 수 있습니다.
◦
또한 날짜의 경우는 대부분의 Fact에서 쓰는 것으로 개념의 범위가 조금 더 좁으면 좋습니다.
◦
상품과 같은 것은 아마도 '매출' 주제영역에만 영향을 끼칠 것이기 때문에 상품차원에 '자동여부'를 두기로 하는 것이 좋다고 판단할 수 있습니다.
Denormalized Flattened Dimensions
•
디멘젼 설계자는 기본적으로 정규화를 멀리하고 비정규화를 통한 단순성과 속도라는 디멘젼 모델링의 두 가지 목표를 달성하고자 해야합니다.
Multiple Hierarchies in Dimensions
•
하나의 디멘젼 테이블에는 여러 계층이 있을 수 있습니다.
•
예를 들어, 달력 디멘젼에는 일, 주, 월, 연 단위의 계층이, 위치 디멘젼에는 나라, 주, 시 등의 계층이 함께 존재할 수 있습니다.
Flags and Indicators as Textual Dimension Attributes
•
플래그나 약어는 독립적으로 이해할 수 있는 텍스트로 보완되어야 합니다.
•
예를 들어, 아래의 왼쪽과 같이 휴일이냐 아니냐를 Y/N와 같이 플래그로 표시한다면 컨텍스트가 없다면 이해할 수가 없습니다.
•
따라서 오른쪽의 Holiday, Non-holiday와 같이 명시적인 형태로 표시를 해주어야 합니다.
Null Attributes in Dimensions
•
속성이 없는 경우는 디멘젼 테이블에 null이 존재할 수 있습니다.
•
이럴 때는 그냥 null이 아니라 Unknown이나 Not Applicable과 같은 문자열로 채우는 것을 추천합니다.
◦
각 데이터베이스마다 null을 처리하는 로직이 다를 가능성이 많기 때문입니다.
Calendar Date Dimensions
•
Calendar Date Dimensions는 날짜를 더 쉽게 처리하기 위한 디멘젼 테이블입니다.
•
파티셔닝을 위해서라도 이 디멘젼에서는 surrogate key와 같은 키보다는 YYYYMMDD와 같이 의미있는 형태가 PK로 더 좋습니다.
•
만약 정확성을 요구한다면 date/timestamp를 팩트 테이블에 추가할 수 있습니다.
◦
date/timestamp는 디멘젼 테이블에 대한 FK가 아니라 독립적인 컬럼입니다.
•
비즈니스 사용자가 팩트 테이블에 대해 요일, 휴일 여부와 같은 디멘젼으로 보기를 원한다면 팩트 테이블에 달력 디멘젼 테이블에 대한 FK를 넣어주면 됩니다.
Role-Playing Dimensions
•
하나의 디멘젼 테이블이 팩트 테이블에서 여러 번 참조될 수도 있습니다.
◦
팩트 테이블이 여러 date를 가졌다면 여러 번 참조될 수 있습니다.
◦
예를 들어, transaction 팩트 테이블에서 order_date와 requested_ship_date라는 날짜 관련 키가 있다면 date 디멘젼 테이블이 여러 번 참조될 수 있습니다.
•
하지만 참조되는 디멘젼은 하나의 인스턴스로만 사용되면 안되고 각 디멘젼에 따라 뷰를 나누어야 합니다.
◦
order_date와 requested_ship_date가 결국 date 디멘젼을 참조한다고 하더라도 order_date와 requested_ship_date에 해당하는 각각의 디멘젼을 view나 aliases 형태로 만들어 컬럼명을 이에 맞게 만들어서 조인해야 합니다.
•
이렇게 함으로서 각각의 디멘젼이 의미하는 바를 더 명확하게 나타낼 수가 있습니다.
Junk Dimensions
•
다른 디멘젼에 속하지 않는 낮은 카디널리티 조합을 가진 디멘젼 테이블
◦
예를 들어 pg사, 결제 방법, 통화 등의 속성을 가진 팩트테이블이 있다고 가정
◦
이를 위해 각각의 분리된 디멘젼이 아니라 이러한 조합을 모두 갖는 하나의 정크 디멘젼을 가질 수 있습니다.
◦
이렇게 함으로서 팩트 테이블이 너무 많은 FK를 갖지 않도록 하고, 쿼리 속도를 높일 수 있습니다.
Snowflaked Dimensions
•
디멘젼 테이블을 계속해서 정규화시키다보면, 디멘젼 테이블에 위계가 생기게 되고 스노우플레이크 디멘젼이라 불리는 형태가 만들어지게 됩니다.
•
스노우플레이크가 계층적 데이터를 정확하게 나타내지만, 비즈니스 사용자가 스노우플레이크를 이해하고 탐색하기 어렵기 때문에 웬만하면 피해야 합니다.
•
또한 쿼리 성능에 부정적인 영향을 줄 수도 있습니다.
Outrigger Dimensions
•
디멘젼은 다른 디멘젼을 참조할 수 있습니다.
•
예를 들어, 계좌 디멘젼이 계좌가 개설된 날짜를 나타내는 별도의 디멘젼을 참조할 수 있습니다.
•
이러한 보조 디멘젼을 아웃트리거 디멘젼이라고 합니다.
•
아웃트리거 디멘젼은 허용은 되지만 신중하게 사용해야 합니다.
◦
대부분의 경우에는 차원 간의 상관관계는 두 차원이 별도로 표시되는 팩트 테이블로 만들어야 합니다.
