컨폼드 디멘션

컨폼드 디멘션은 서로 다른 업무의 분석 숫자를 같은 기준으로 나란히 놓게 해 줍니다. 상품이나 날짜 같은 기준 테이블을 한 벌만 만들어 여러 업무가 함께 씁니다. 그러면 판매 숫자와 반품 숫자를 같은 상품 줄에 이어 붙일 수 있습니다. 대신 여러 팀이 그 기준의 이름과 값에 먼저 합의해야 합니다.

상세

이 절은 쇼핑몰의 판매와 반품 두 업무를 끝까지 들고 갑니다. 두 업무의 숫자를 상품 카테고리별로 한 표에 놓는 것이 목표입니다.

팩트 테이블과 차원 테이블

컨폼드 디멘션은 차원 모델링에서 나온 말입니다. 차원 모델링은 분석용 데이터를 숫자와 그 숫자를 가를 기준으로 나눠 담는 설계입니다. 숫자를 담는 테이블과 기준을 담는 테이블이 따로 있습니다.

숫자를 담는 쪽이 팩트 테이블입니다. 업무에서 일어난 일을 한 행씩 적습니다. 판매 팩트 테이블이라면 팔린 상품 한 줄이 한 행입니다. 판매 테이블이나 반품 테이블처럼 업무의 숫자를 쌓는 분석 테이블이 여기에 해당합니다.

기준을 담는 쪽이 차원 테이블입니다. 상품 차원 한 행에는 상품 이름, 브랜드, 카테고리가 들어 있습니다. 차원을 영어로 디멘션(dimension)이라고 합니다. 컨폼드 디멘션은 이 차원 테이블에 붙는 이름입니다.

팩트 테이블의 행은 상품_키 같은 번호 열로 차원 테이블의 행을 가리킵니다. 「카테고리별 판매량」은 이 번호를 따라가 카테고리로 묶은 합계입니다.

팩트 테이블은 업무마다 하나씩 생깁니다. 판매에 하나, 반품에 하나입니다. 컨폼드 디멘션은 이 두 테이블이 차원을 어떻게 나눠 쓰느냐의 문제입니다.

차원을 팀마다 따로 만들 때

판매팀과 반품팀이 각자 팩트 테이블을 만들었다고 해 봅시다. 두 팀은 상품 차원도 각자 만듭니다. 판매팀은 칫솔을 「생활용품」 카테고리에 넣습니다. 반품팀은 같은 칫솔을 「욕실」 카테고리에 넣습니다.

이제 「카테고리별 반품률」을 구하려 합니다. 반품 수량을 판매 수량으로 나눈 값입니다. 판매 쪽과 반품 쪽의 카테고리 목록이 서로 다릅니다. 어느 줄끼리 나눠야 할지 정할 수 없습니다.

같은 질문에 부서마다 다른 숫자가 나오기도 합니다. 판매팀의 생활용품에는 칫솔이 들어 있고 반품팀의 생활용품에는 칫솔이 없습니다. 두 팀이 낸 「생활용품」 숫자는 이름만 같고 담긴 상품이 다릅니다.

상품 번호도 어긋날 수 있습니다. 한 팀은 원본 시스템의 상품 번호를 그대로 씁니다. 다른 팀은 번호를 새로 매깁니다. 같은 칫솔이 두 번호를 가지면 칫솔의 판매 행과 반품 행을 같은 상품으로 짝지을 수 없습니다.

차원을 맞춘다는 것

컨폼드(conformed)는 맞춰졌다는 뜻입니다. 두 차원 테이블이 같은 열 이름을 쓰고 그 열에 같은 값을 담으면 두 차원이 맞춰졌다고 합니다. 칫솔의 카테고리가 어느 테이블에서든 「생활용품」이면 카테고리 열이 맞춰진 것입니다.

가장 쉬운 방법은 상품 차원을 한 벌만 만드는 것입니다. 판매와 반품이 그 한 벌을 함께 가리킵니다. 이렇게 여러 팩트 테이블이 함께 쓰는 차원이 컨폼드 디멘션입니다. 우리말로는 공통 차원이라고도 합니다.

아래 그림은 두 경우를 위아래로 놓았습니다. 위는 팀마다 상품 차원을 따로 만든 모양입니다. 아래는 상품 차원과 날짜 차원을 함께 쓰는 모양입니다.

flowchart TD
    subgraph A["팀마다 따로 만든 차원"]
        S1["판매 팩트 테이블"] --> P1["판매팀 상품 차원<br/>칫솔 · 생활용품"]
        R1["반품 팩트 테이블"] --> P2["반품팀 상품 차원<br/>칫솔 · 욕실"]
    end
    subgraph B["함께 쓰는 차원"]
        S2["판매 팩트 테이블"] --> P3["상품 차원<br/>칫솔 · 생활용품"]
        R2["반품 팩트 테이블"] --> P3
        S2 --> D["날짜 차원"]
        R2 --> D
    end
    P1 ~~~ S2

아래쪽에서 판매와 반품이 가리키는 칫솔은 한 행입니다. 그래서 칫솔은 두 업무에서 같은 번호와 같은 카테고리를 가집니다.

한 벌을 여러 저장소에 두는 방법

차원을 맞추려고 테이블을 꼭 하나만 둘 필요는 없습니다. 판매와 반품이 서로 다른 데이터 마트에 있을 수 있습니다. 데이터 마트는 한 부서나 한 업무가 쓸 분석 데이터만 모아 둔 저장소입니다.

이때는 상품 차원을 두 마트에 복사해 둡니다. 두 복사본의 열 이름과 값이 같으면 둘은 맞춰진 차원입니다.

상품 하나 단위로 판매와 반품을 이으려면 두 복사본에서 칫솔의 번호도 같아야 합니다. 번호가 다르면 앞에서 본 것처럼 칫솔의 판매 행과 반품 행을 짝지을 수 없습니다. 복사본을 한 곳에서 만들어 나눠 주는 까닭입니다.

두 팩트 테이블의 숫자를 잇는 쿼리

판매와 반품이 상품 차원을 함께 쓰면 카테고리별 반품률을 구할 수 있습니다. 먼저 팩트 테이블마다 카테고리별 합계를 따로 냅니다. 그다음 두 합계를 카테고리 값으로 이어 붙입니다.

이렇게 여러 팩트 테이블의 결과를 공통 차원의 값으로 잇는 조회를 드릴 어크로스(drill-across)라고 합니다. 차원 모델에서 여러 업무를 한 표에 놓는 기본 방법입니다.

아래 쿼리가 두 단계를 한 번에 합니다. 첫머리의 WITH 절은 쿼리 안에서 쓸 중간 결과에 이름을 붙입니다. 판매량과 반품량이 그 이름입니다.

WITH 판매량 AS (
  SELECT p.카테고리, SUM(s.수량) AS 판매
  FROM 판매 s
  JOIN 상품 p ON s.상품_키 = p.상품_키
  GROUP BY p.카테고리
),
반품량 AS (
  SELECT p.카테고리, SUM(r.수량) AS 반품
  FROM 반품 r
  JOIN 상품 p ON r.상품_키 = p.상품_키
  GROUP BY p.카테고리
)
SELECT 카테고리, 판매, 반품
FROM 판매량
JOIN 반품량 USING (카테고리);

마지막 두 줄이 두 중간 결과를 카테고리 열로 잇습니다. 두 쪽 모두 같은 상품 차원에서 카테고리를 가져왔습니다. 그래서 「생활용품」은 양쪽에서 같은 글자입니다. 두 쪽의 생활용품 줄이 한 줄로 이어집니다.

결과는 아래와 같습니다.

생활용품은 1200개 팔려서 36개가 돌아왔습니다. 백 개를 팔면 세 개꼴로 반품된 셈입니다.

팩트 테이블끼리 먼저 잇지 않는 까닭

두 팩트 테이블을 먼저 잇고 나서 더하면 숫자가 부풀어 오릅니다. 칫솔의 판매 행이 100개이고 반품 행이 3개라고 해 봅시다. 둘을 상품_키로 이으면 판매 행 하나마다 반품 행 셋이 붙어 300행이 생깁니다.

그 300행에서 판매 수량을 더하면 판매 행 하나가 세 번씩 더해집니다. 반품 수량은 반품 행 하나가 백 번씩 더해집니다. 그래서 드릴 어크로스는 합계를 먼저 내고 그 합계끼리 잇습니다.

그레인이 다른 팩트 테이블

모든 팩트 테이블이 상품 하나 단위로 적히지는 않습니다. 팩트 테이블 한 행이 무엇을 뜻하는지를 그레인(grain)이라고 합니다. 판매 팩트 테이블의 그레인은 「팔린 상품 한 줄」입니다.

예산 팩트 테이블은 그레인이 더 굵습니다. 예산은 상품마다 잡지 않습니다. 카테고리와 달마다 잡습니다. 그래서 한 행이 「카테고리 하나의 한 달」입니다.

이 테이블은 상품 차원을 가리킬 수 없습니다. 상품 차원의 한 행은 상품 하나입니다. 예산 행에는 상품이 없습니다. 그래서 카테고리 하나가 한 행인 카테고리 차원을 따로 둡니다.

카테고리 차원의 열은 상품 차원의 열 가운데 일부입니다. 아래 표는 두 차원이 어느 열을 가지는지 견줍니다.

겹치는 두 열은 이름도 값도 같습니다. 이렇게 큰 차원의 열 일부만 남겨 행 수를 줄인 차원을 축소 차원(shrunken dimension)이라고 합니다. 겹치는 열이 맞춰져 있으므로 축소 차원도 컨폼드 디멘션입니다.

덕분에 판매 실적과 예산을 카테고리로 이어 붙일 수 있습니다. 판매 쪽은 상품 차원의 카테고리 열로 묶습니다. 예산 쪽은 카테고리 차원으로 묶습니다. 두 결과의 「생활용품」이 같은 글자라서 한 줄에 놓입니다.

버스 매트릭스

컨폼드 디멘션이 있으면 분석 저장소를 한 번에 다 짓지 않아도 됩니다. 업무 하나씩 팩트 테이블을 늘려 가도 같은 차원을 가리키면 서로 이어집니다. 새 업무를 붙일 때 기존 차원을 가져다 쓰므로 차원을 다시 만들 일도 줄어듭니다.

어느 업무가 어느 차원을 쓰는지는 표 하나로 정리합니다. 행에 업무를 적고 열에 차원을 적습니다. 이 표가 버스 매트릭스(bus matrix)입니다.

한 열에 ✓ 가 둘 이상이면 그 차원은 여러 업무가 함께 씁니다. 날짜, 상품, 고객이 그렇습니다. 이 셋은 먼저 맞춰 둬야 할 차원입니다.

여러 팩트 테이블이 같은 차원을 함께 가리키며 이어지는 구조를 엔터프라이즈 데이터 웨어하우스 버스 아키텍처라고 합니다. 이름의 버스는 여러 장치가 공통 통로 하나에 꽂히는 컴퓨터의 버스에서 따왔습니다. 공통 차원이 그 통로를 맡습니다.

이 구조로 업무를 하나씩 붙여 가면 회사의 분석 데이터가 한곳에 모입니다. 여러 업무의 분석 데이터를 한곳에 모은 저장소를 데이터 웨어하우스라고 합니다. 앞에서 분석 저장소라고 부른 것이 이것입니다.

대가

차원을 맞추는 일은 기술보다 합의에 가깝습니다. 판매팀과 반품팀이 칫솔의 카테고리를 하나로 정해야 합니다. 「고객」에 비회원 주문자까지 넣을지도 정해야 합니다. 부서가 많을수록 합의가 오래 걸립니다.

함께 쓰는 차원은 한 팀이 혼자 고칠 수 없습니다. 카테고리 이름 하나를 바꾸면 그 차원을 쓰는 모든 팩트 테이블의 집계가 바뀝니다. 그래서 차원을 고치는 절차와 책임자를 따로 둡니다.

데이터의 정의와 품질을 조직 단위로 관리하는 일을 데이터 거버넌스라고 합니다. 공통 차원의 열 이름과 값을 정하는 것도 이 일에 들어갑니다.

맞추지 않아도 되는 경우

팩트 테이블이 하나뿐이면 맞출 상대가 없습니다. 다른 업무와 견줄 일이 없는 분석도 그 팀만의 차원으로 충분합니다.

나중에 이을 필요가 생기면 그때 맞춰야 합니다. 이미 쌓인 팩트 행의 번호를 새 차원의 번호로 바꿔야 해서 일이 커집니다. 여러 업무를 견줄 것이 처음부터 보이면 차원을 먼저 맞추고 시작하는 까닭입니다.

관련 항목

컨폼드 디멘션이 속하는 설계 방법

차원 모델링 · 스타 스키마 · 스노우플레이크 스키마 · 팩트 컨스텔레이션

컨폼드 디멘션을 이루는 구성 요소

차원 테이블 · 팩트 테이블 · 측정값 · 그레인 · 대리 키 · 자연 키 · 외래 키

컨폼드 디멘션과 함께 쓰는 차원 기법

축소 차원 · 천천히 변하는 차원 · 역할 수행 차원 · 정크 디멘션 · 퇴화 차원 · 컨폼드 팩트

컨폼드 디멘션으로 여러 업무를 잇는 구조

엔터프라이즈 데이터 웨어하우스 버스 아키텍처 · 버스 매트릭스 · 드릴 어크로스 · Corporate Information Factory

컨폼드 디멘션이 놓이는 분석 저장소

데이터 웨어하우스 · 데이터 마트 · 독립 데이터 마트 · 레이크하우스

컨폼드 디멘션을 읽는 분석 도구

OLAP · OLAP 큐브 · 비즈니스 인텔리전스 · 시맨틱 레이어

컨폼드 디멘션의 정의를 지키는 관리 체계

데이터 거버넌스 · 마스터 데이터 관리 · 데이터 카탈로그 · 메타데이터