목차
데이터를 조금 더 체계적으로 분석하고자 한다면 DW 데이터 모델링은 필수적이라고 할 수 있습니다. 많은 기업들이 데이터 모델링을 하면서 각자의 상황과 조건에 맞는 방식을 채택하고 알맞게 잘 다듬어 적용을 할텐데요. 그 중 가장 유명하고 인용이 많이 되는 이론은 Kimball의 Star Schema(스타 스키마)이지 않을까 싶습니다.
그 유명한 DW 데이터 모델링계의 바이블이라고 할 수 있는 킴볼의 The Data Warehouse Toolkit이 1996년에 출판되었으니 벌써 20년도 넘은 어떻게 보면 올드 패션한 이론이라고 할 수 있습니다. 하지만 아직까지도 많은 엔지니어들이 차용하고 그 쓸모를 체감하고 있는 만큼 정말 치밀하게 잘 설계된 방법론이라고 할 수 있습니다.
아마 스타 스키마를 알고 계시는 분들이라면 팩트와 디멘젼 테이블에 대해서 들어보셨을텐데요. 그 중 가장 중요한 축을 담당하고 있는 팩트 테이블이 사실 여러 종류가 있다는 것을 알고 계신가요? 이번 포스팅에서는 3가지 종류의 팩트 테이블에 대해서 알아보고자 합니다!
Fact table이란?
그 전에 먼저 팩트 테이블의 정의부터 알아보도록 하겠습니다. 바이블에서는 팩트 테이블을 아래와 같이 정의하고 있습니다.
A fact table contains the numeric measures produced by an operational measurement event in the real world.
제가 생각하기에 여기서 가장 중요한 단어는 numeric measures이라고 생각하는데요. 팩트 테이블의 가장 큰 존재 이유는 해당 테이블로 무언가 수식적인 계산을 할 수 있어야 한다는 것입니다. 어찌보면 당연하다고 할 수 있는데 결국 스타 스키마 같은 방법론도 데이터 즉 어떠한 수치를 잘 보기위한 결과물이기 때문에 팩트 테이블은 아래와 같이 우리가 보고자 하는 어떤 수치를 담고 있어야 하겠죠.
즉, 팩트 테이블에서의 팩트는 수치적이거나 측정할 수 있는 숫자를 의미한다고 보시면 됩니다.
•
fact = numerical or measurable
아래 판매를 나타내는 팩트 테이블에서는 판매된 상품의 대한 전체적인 정보를 가지고 있고, 특히 amount와 같이 수치적인 컬럼을 가지고 있는 것을 볼 수 있습니다. 이 부분을 팩트라고 표현합니다.
물론 이 말이 꼭 테이블 컬럼에 무조건 숫자 타입의 컬럼을 가지고 있어야 한다는 뜻은 아닙니다. 미리 조금 티징을 하자면 모순적이지만 Factless Fact Table라는 테이블도 존재하는데요. 팩트리스 테이블은 위와 같은 수치적인 정보는 없고 일종의 브릿지 역할을 하는 테이블도 있습니다
어쨌든 숫자 타입의 컬럼이 없어도 count를 이용해 그냥 갯수를 셀 수도 있는 것이고, 팩트리스 테이블처럼 브릿지 역할을 할 수도 있습니다. 하지만 조금 더 다채로운 분석을 위해서라면 결국 숫자 타입이 있어야 하는 것도 사실입니다.
Fact table의 5가지 종류
팩트 테이블에 대해 알아봤으니 본격적으로 오늘의 주제였던 팩트 테이블의 여러 종류에 대해 알아보겠습니다. 아마 많이들 팩트 테이블이 단지 Transaction을 담고 있는 테이블 아닌가? 라고 생각하실겁니다. 물론 그 말도 맞긴 하지만 조금 더 디테일하게 알아볼 필요가 있습니다. 그럼 하나씩 살펴보도록 하죠!
Transaction Fact Table
먼저 트랜잭션 테이블입니다. 이 형태는 팩트 테이블의 가장 기본적인 형태이고, 이름에서 알 수 있다시피 row 하나가 트랜잭션의 형태를 띄고 있습니다.
Transactional Fact Table
위에서 살펴보았던 테이블이 바로 트랜잭션 테이블인데, 판매가 하나 일어날 때마다 새로운 row가 하나 추가되는 형태입니다. 아무래도 가장 기본적인 형태이기 때문에 이해가 어렵지는 않습니다.
Periodic Snapshot Fact Table
주기적 스냅샷 팩트 테이블은 정기적이고 일정한 주기로 살펴볼 수 있는 비즈니스에 필요한 형태입니다. 트랜잭션 테이블은 이벤트가 발생할 때마다 추가가 됐다면 이 테이블은 마치 사진 찍듯이 day, week, month 단위로 활동을 기록합니다. 사실상 트랜잭션 테이블을 조금 더 효율적으로 볼 수 있도록 한 팩트 테이블 형태라고 볼 수 있을 것 같습니다.
Periodic Snapshot Fact Table
예를 들면 매출에 대한 트랜잭션이 있다고 했을 때 주기적 스냅샷 팩트 테이블을 사용하면 기간으로 묶어서 미리 집계를 해놓기 때문에 퍼포먼스 측면에서 훨씬 좋은 성능을 낼 수가 있습니다.
하지만 클라우드의 MPP 기반 데이터 웨어하우스가 등장하면서 이제는 굳이 이렇게 주기적으로 집계를 하지 않아도 된 것도 사실이긴 합니다. 이제는 바로 ad-hoc하게 일, 주, 월 단위로 집계를 해도 속도나 성능 상으로 큰 어려움이 감소했기 때문이죠.
Accumulating Snapshot Fact Table
사실 이 형태는 제가 팩트 테이블에 대해 알아보고 이렇게 글까지 남기게 된 이유라고 할 수 있습니다. 팩트 테이블을 설계할수록 만약 지속적으로 상태를 트래킹해야 하는 경우면 어떡하지? 라는 의문이 계속해서 들었고 리서치를 해보면서 팩트 테이블의 여러 형태에 대해 알게 되었습니다.
누적 스냅샷 팩트 테이블이 위의 테이블들과 가장 다른 점은 기존 row를 건드릴 수 있다는 점입니다. 기본적으로 팩트 테이블은 한 번 쌓인 데이터는 더 이상 update 하지 않습니다. 그도 그럴 것이 트랜잭션 테이블은 이벤트가 발생할 때마다 단지 row를 쌓는 것이고, 주기적 스냅샷 테이블은 그런 트랜잭션 테이블을 약간 변형한 형태이니 말이죠.
하지만 팩트 테이블이라고 해서 꼭 변경이 없는 것은 아니겠죠? 예를 들어 트랜잭션 테이블이 있다고 하였을 때 t1에 대한 amount가 바뀔 수도 있습니다. 400$에서 350$로 바뀌었다고 가정해보죠. 만약 기존의 트랜잭션 테이블이라면 이런 식으로 추가가 될 겁니다.
.jpg&blockId=e0cc7510-15db-4171-8b26-bcfae25e3f15)
이렇게 되면 무슨 문제가 있을까요? 바로 t1의 진짜 amount를 식별할 수가 없다는 것이죠. 누적 스냅샷 팩트 테이블은 이러한 문제를 해결하기 위해 이러한 형태로 테이블을 관리합니다.
.jpg&blockId=081eb231-256b-4b72-a873-cb58cdcba395)
Accumulating Snapshot Fact Table
Effective Start와 Effective End라는 컬럼이 추가가 되었는데 해당 컬럼을 통해 현재 어떤 row가 active한지 판단을 할 수 있게 되었습니다.
Factless Fact Table
이름에서도 알 수 있다시피 팩트리스 팩트 테이블은 수치적이거나 측정할 수 있는 팩트가 존재하지 않습니다. 대신 디멘젼 테이블과 연결되는 FK로만 이루어져 있죠.
Factless Fact Table
그렇다면 이런 팩트 테이블이 하는 역할은 무엇일까요? 팩트리스 팩트 테이블은 값을 측정하고 집계하는 것이 아니라 단지 각 디멘젼의 브릿지 역할만을 담당합니다. 위의 테이블에서는 각 트랜잭션, 고객, 상품의 디멘젼을 서로 연결하여 하나의 트랜잭션의 디멘젼을 조망할 수 있게끔 하였습니다.
Aggregate Fact Table
마지막은 집계된 데이터가 모여있는 집계 팩트 테이블입니다. 이 테이블의 목적은 기존의 팩트 테이블을 미리 집계하여 쿼리 성능을 높일 수 있도록 해줍니다.
아래의 테이블처럼 보통은 원하는 기간에 대하여 미리 집계를 하는 경우가 많습니다.
.jpg&blockId=20509c35-bc27-426c-a27b-ce9388a6494d)
Aggregate Fact Table
