데이터 마트 콘포밍 차원 (Conformed Dimension) 아키텍처

핵심 인사이트 (3줄 요약)

본질: 콘포밍 차원(Conformed Dimension)은 전사 데이터 웨어하우스(DW) 환경에서 영업, 재무, 마케팅 등 서로 다른 부서의 데이터 마트(Data Mart)들이 '고객', '날짜', '제품'과 같은 핵심 기준 정보(Dimension)를 완전히 동일한 스키마와 데이터 값으로 공유하도록 강제하는 아키텍처 설계 표준이다.

가치: 이 표준을 준수하면, 마케팅 부서의 '캠페인 팩트(Fact)' 테이블과 영업 부서의 '매출 팩트' 테이블을 하나의 쿼리로 묶어서 분석하는 '드릴 어크로스(Drill-across)'가 가능해져, 부서 간 "우리 부서 통계가 맞다"며 싸우는 데이터 정합성 붕괴(Data Silo) 현상을 원천 차단한다.

융합: 이 개념은 랄프 킴볼(Ralph Kimball)의 상향식(Bottom-up) DW 버스 아키텍처(Bus Architecture)를 지탱하는 척추(Backbone)이며, 현대의 마스터 데이터 관리(MDM) 시스템 및 데이터 카탈로그(Data Catalog)와 융합되어 단일 진실 공급원(SSOT, Single Source of Truth)을 엔터프라이즈 레벨로 확장시킨다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 콘포밍 차원(Conformed Dimension, 일치된 차원)은 물리적 또는 논리적으로 완벽하게 동일한 속성(Attribute), 구조(Schema), 키(Surrogate Key) 값을 가지며, 회사 내의 여러 다차원 데이터 모델(Star Schema)에서 재사용되는 차원 테이블을 의미한다.
필요성: 기업이 성장하면 각 부서는 자신의 입맛에 맞는 데이터 마트(Data Mart)를 개별적으로 구축한다. 마케팅팀은 '고객'을 '웹사이트 가입자'로 정의하고, 재무팀은 '고객'을 '결제 이력이 있는 사람'으로 정의하여 각자의 마트에 Dim_Customer 테이블을 따로 만든다. 사장님이 "이번 달 20대 여성 고객의 마케팅 비용 대비 매출액을 뽑아오라"고 지시하면 참사가 벌어진다. 마케팅 비용 팩트 테이블과 매출 팩트 테이블을 조인(JOIN)하려고 해도, 두 부서의 '고객' 차원 테이블이 가지고 있는 식별자(ID)와 '20대'를 나누는 기준(연령대 구간)이 달라서 쿼리 자체가 불가능하거나 엉터리 수치가 나온다. 이를 해결하기 위해 "우리 회사의 '고객'이라는 차원은 무조건 이 테이블 하나만 갖다 써라!"라고 대못을 박는 거버넌스가 바로 콘포밍 차원이다.
등장 배경 및 기술적 패러다임 전환: 1990년대 빌 인몬(Bill Inmon)은 데이터를 거대한 중앙 DW에 먼저 다 쏟아붓고(Top-down) 나중에 마트로 쪼개는 방식을 주장했다. 이는 정합성은 맞지만 구축에 수년이 걸렸다. 이에 반발한 랄프 킴볼(Ralph Kimball)은 "작은 부서별 마트부터 빠르게 만들고(Bottom-up), 나중에 이 마트들을 레고 블록처럼 조립하자"는 버스 아키텍처를 제안했다. 이 레고 블록들이 어긋나지 않고 딱 들어맞게 해주는 돌기(Interface) 역할을 하는 것이 바로 콘포밍 차원이다. 콘포밍 차원만 공유한다면, 전 세계 어디서 마트를 만들든 궁극적으로는 하나의 거대한 엔터프라이즈 DW로 매끄럽게 통합(Integration)될 수 있다.

이 다이어그램은 개별 차원의 혼돈과 콘포밍 차원을 통한 드릴 어크로스(Drill-across) 통합 분석의 차이를 극명하게 대비한다.

  ┌───────────────────────────────────────────────────────────────┐
  │         개별 차원(Silo)의 비극 vs 콘포밍 차원(Conformed)의 통합       │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  [A. 개별 차원 구조 (데이터 사일로 현상 발생)]                      │
  │   [ 마케팅 마트 ]                      [ 영업 마트 ]             │
  │   Dim_Customer (ID: 1)             Dim_Client (ID: A)         │
  │      │ (마케팅 팩트 조인)                 │ (매출 팩트 조인)         │
  │      ▼                                ▼                      │
  │   Fact_Campaign                    Fact_Sales                 │
  │   ★ 참사: "마케팅 비용 대비 매출" 쿼리 불가! 두 차원의 ID 체계가 달라     │
  │           팩트 테이블끼리 연결(Drill-across)할 수 있는 브리지가 없음.   │
  │                                                               │
  │  [B. 콘포밍 차원 구조 (DW Bus Architecture)]                    │
  │                                                               │
  │        ┌──▶  [ Conformed_Dim_Customer ]  ◀──┐                │
  │        │          (전사 표준 공통 고객 테이블)     │                │
  │        │          - Surrogate_Key: 999      │                │
  │        │          - Age_Group: '20대'        │                │
  │        │                                    │                │
  │   [ 마케팅 마트 ]                      [ 영업 마트 ]             │
  │   Fact_Campaign ──────── (Drill-across) ─────▶ Fact_Sales    │
  │   (캠페인 발송 비용)                               (최종 결제 금액) │
  │                                                               │
  │   ★ 기적: 공통된 차원(Customer Key 999)을 축으로 삼아, 두 개의 독립된   │
  │           팩트 테이블이 완벽하게 묶여서(Group by) 한 화면에 통계로 출력됨!│
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 도식의 핵심은 드릴 어크로스(Drill-across) 연산이다. 다차원 모델링(Star Schema)에서 두 개 이상의 서로 다른 팩트 테이블(예: 캠페인 팩트, 세일즈 팩트)을 직접 JOIN 하는 것은 다대다(M:N) 카테시안 곱을 유발하는 금기 사항이다. 올바른 방법은 두 팩트 테이블을 각각 쿼리하여 공통된 차원(Conformed Dimension) 기준으로 GROUP BY 한 결과를 메모리 상에서 합치는(UNION ALL 후 집계) 것이다. B 방식에서 마케팅과 영업 팩트 테이블은 서로 아무런 외래 키(FK) 관계가 없지만, 둘 다 Conformed_Dim_Customer라는 동일한 차원 테이블의 동일한 대리 키(Surrogate Key 999)를 바라보고 있다. 이 하나의 공통 분모가 있기 때문에, BI(비즈니스 인텔리전스) 툴은 "20대 고객이 소비한 마케팅 비용은 100만 원, 그들이 일으킨 매출은 500만 원"이라는 부서를 초월한 통합 인사이트를 0.1초 만에 조립해 낼 수 있는 것이다.

📢 섹션 요약 비유: 각 나라가 자기들만의 전기 플러그 모양(110V, 220V, 3구 등)을 쓰면 전자제품(팩트 데이터)을 외국에 가져가서 쓸 수가 없습니다(사일로 현상). 콘포밍 차원은 전 세계가 무조건 'USB-C 타입'이라는 하나의 똑같은 규격(표준 차원)을 쓰기로 법으로 강제하여, 어떤 회사의 전자제품이든 꽂기만 하면 다 연결되게 만드는 국제 표준화 협약과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

콘포밍 차원을 성립시키는 3대 설계 원칙

단순히 테이블 이름만 똑같이 짓는다고 콘포밍 차원이 되는 것이 아니다. 데이터의 뼛속까지 동기화되어야 한다.

설계 원칙	상세 설명 및 제약 조건	아키텍처적 목적
동일한 대리 키 (Surrogate Key)	모든 데이터 마트는 자연 키(주민번호 등) 대신, 시퀀스로 생성된 무의미한 정수형 PK(대리 키)를 사용해야 하며, 이 키값은 전사적으로 100% 동일하게 매핑되어야 한다.	느린 문자열 조인을 피하고, 소스 시스템의 키가 변경되어도 DW의 이력이 깨지지 않게 보존함
동일한 속성 명과 도메인 값	'연령대' 컬럼이 있다면, A마트는 '20~29', B마트는 '20대'로 쓰면 안 된다. 무조건 하나의 코드값(예: '20s') 규칙을 엄격히 적용해야 한다.	팩트 테이블 간 `GROUP BY`를 수행할 때 데이터가 쪼개지지 않고 정확히 하나의 그룹으로 뭉치게 함
동일한 입도 (Granularity)	'날짜' 차원이면 무조건 '일(Day)' 단위로 쪼개야 한다. 한 곳은 '월(Month)', 한 곳은 '일(Day)'로 차원을 구성하면 드릴 어크로스 시 집계 레벨이 박살 난다.	비즈니스 팩트 발생의 최소 단위를 통일하여 상하위 계층(Hierarchy)의 드릴다운을 호환시킴

콘포밍 차원의 물리적 구현 토폴로지 (Hub-and-Spoke)

실무에서 콘포밍 차원을 어떻게 수십 개의 마트에 복제할 것인가의 문제다.

중앙 집중형 (물리적 단일 테이블): 클라우드 DW(Snowflake 등) 환경에서는 중앙에 Dim_Date, Dim_Customer 테이블을 하나만 띄워두고, 모든 부서의 마트가 이 테이블을 뷰(View) 형태로 참조(Select)하게 만든다. 가장 완벽한 콘포밍이다.
복제 퍼블리싱 (Replication): 물리적으로 떨어진 서버(Oracle과 SQL Server)에 마트가 분리되어 있다면, 중앙의 마스터 데이터 관리(MDM) 서버가 매일 밤 정제된 콘포밍 차원 데이터를 각 마트의 DB로 복사(Push)해 준다.
부분 집합 (Subset Conformed Dimension): 본사용 '제품' 차원에는 [분류, 가격, 원가, 제조사] 속성이 다 있지만, 영업소용 마트에는 가벼운 쿼리를 위해 [분류, 가격] 속성만 복사해 줄 수 있다. 속성의 개수는 적더라도 남아있는 속성의 스키마와 데이터 값이 본사와 100% 일치한다면, 이 역시 훌륭한 '부분 집합 콘포밍 차원'으로 인정된다.

📢 섹션 요약 비유: 프랜차이즈 햄버거 가게(데이터 마트)가 전국에 100개가 생기더라도, 햄버거 빵(콘포밍 차원)만큼은 무조건 본사 공장(MDM)에서 똑같은 크기와 맛으로 구워서 매일 아침 각 지점으로 배달해 주어야만 전국 어디서든 '빅맥'의 표준화된 맛(데이터 정합성)이 유지되는 원리입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

Inmon (Top-down) vs Kimball (Bottom-up) 아키텍처 비교

데이터 웨어하우스(DW) 구축의 양대 산맥 철학에서 콘포밍 차원이 차지하는 위상을 분석한다.

비교 항목	Bill Inmon (엔터프라이즈 DW 중심)	Ralph Kimball (데이터 마트 & 버스 구조 중심)
설계 철학	데이터를 전사 통합 모델(3NF 정규화)로 싹 다 모은 뒤, 필요할 때 부서별 마트(다차원)로 쪼개 준다.	부서별 마트(다차원)를 먼저 빠르게 만들고, 공통 차원(Conformed Dim)으로 묶어서 전사 DW를 완성한다.
통합의 주체	EDW (Enterprise Data Warehouse)라는 거대한 물리적 중앙 DB가 통합을 강제함	Conformed Dimension (콘포밍 차원)이라는 논리적 규약이 버스(Bus) 역할을 하여 마트들을 묶어줌
구축 속도/비용	초기 설계에 엄청난 시간과 돈이 소모됨 (빅뱅 방식)	부서별로 쪼개서 시작하므로 초기 비용이 싸고 빠름 (애자일)
리스크	3년 구축하다가 비즈니스 환경이 바뀌어 폐기될 위험	콘포밍 차원 규칙을 어기고 마트를 지으면 데이터가 영원히 통합 안 되는 '데이터 사일로' 괴물이 됨

킴볼(Kimball) 모델이 현대 클라우드 시대의 승자가 된 이유는 애자일(Agile)한 개발 속도 때문이다. 하지만 킴볼 모델의 맹점은 "개발자들이 콘포밍 차원이라는 귀찮은 약속을 100% 지켜야만 시스템이 하나로 융합된다"는 전제 조건에 있다. 단 한 부서라도 "우리 부서는 우리만의 고객 차원 테이블을 만들래"라고 이탈하는 순간, 버스 아키텍처(Bus Architecture)의 척추는 두 동강이 나며 수십억을 들인 DW 프로젝트는 실패로 돌아간다.

마스터 데이터 관리 (MDM) 시스템과의 융합

콘포밍 차원의 데이터를 어디서 가져올 것인가? 각 부서의 엑셀 파일을 모아서 만들면 매일 밤 싸움이 일어난다. 따라서 전사적으로 흩어진 고객 정보를 하나로 클렌징(Cleansing)하고 중복을 제거하여 골든 레코드(Golden Record)를 만들어주는 MDM (Master Data Management) 솔루션이 콘포밍 차원의 가장 완벽한 인풋(Input) 파이프라인으로 융합된다. MDM이 원석을 깎아 보석을 만들면, ETL은 이 보석을 콘포밍 차원이라는 전시장에 예쁘게 진열하는 역할을 수행한다.

📢 섹션 요약 비유: 인몬 방식은 거대한 백화점을 다 지어놓고 각 매장(마트)을 입점시키는 방식이라면, 킴볼 방식은 길거리에 노점상(마트)들을 먼저 쭉 깔게 허락하되, 텐트의 색깔과 간판 규격(콘포밍 차원)만 똑같이 맞추라고 강제하여 결국 하나의 아름다운 전통시장(DW) 거리를 완성하는 애자일한 도시계획입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 설계 안티패턴

시나리오 — 마케팅과 재무 부서의 매출 실적 불일치 대전: 월말 보고에서 마케팅팀은 캠페인으로 '100억'을 벌었다고 보고했고, 재무팀은 전사 매출이 '90억'이라고 보고했다. 경영진이 격노했다. 원인을 까보니, 마케팅 마트의 '날짜(Date) 차원'은 주문 발생일 기준이었고, 재무 마트의 '날짜(Date) 차원'은 입금 완료일 기준이었기 때문에 10억 원의 환불/미입금 건이 다르게 집계된 것이다.
- 의사결정: 날짜 차원의 의미론적(Semantic) 분열이 낳은 비극이다. 전사 데이터 아키텍트(DA)는 즉각 Conformed_Dim_Date 테이블을 표준으로 선포한다. 그리고 팩트 테이블이 이 날짜 차원을 바라볼 때, 외래 키(FK)의 역할을 명확히 하는 롤플레잉 차원(Role-playing Dimension) 기법을 강제한다. 즉, 재무 팩트 테이블에 주문일_Date_Key, 입금일_Date_Key 두 개의 컬럼을 두고, 둘 다 똑같은 중앙 Conformed_Dim_Date 테이블을 조인하도록 아키텍처를 교정하여 수치의 모호성을 영구 박멸한다.
안티패턴 — 스노우플레이크 스키마(Snowflake Schema)의 과도한 정규화 집착: "콘포밍 차원(제품) 안에 [브랜드, 카테고리, 대분류]가 다 섞여 있어서 중복 데이터가 심해요! 이걸 제3정규형(3NF)으로 쪼개서 분리해 둡시다."
- 결과: 다차원 모델링의 금기인 스노우플레이크 스키마를 남용하면, 팩트 테이블에서 제품의 대분류를 쿼리하기 위해 Fact -> Dim_Product -> Dim_Category -> Dim_Class 무려 3번의 연속 조인(JOIN)이 발생한다. 빅데이터 환경에서 읽기(Read) 레이턴시가 폭발하며 쿼리가 뻗어버린다.
- 해결책: 데이터 웨어하우스의 차원 테이블은 디스크 용량을 좀 낭비하더라도(비정규화, Denormalization), 무조건 **크고 뚱뚱한 하나의 평면 테이블(Star Schema)**로 뭉쳐놓아야 한다. 콘포밍 차원은 '데이터 무결성'을 지키는 룰이지 '정규화'를 하라는 룰이 아니다. 쿼리 시 1번의 조인만으로 모든 속성(Attribute)을 스캔할 수 있도록 넓게 펴주는 것이 기술사적 정석이다.

엔터프라이즈 차원 모델링 의사결정 트리

콘포밍 차원 도입은 정치적인 싸움이다. 누구의 기준으로 차원을 통일할 것인가?

  ┌───────────────────────────────────────────────────────────────────┐
  │           전사 데이터 마트 차원 모델링 (Dimension Modeling) 결정 트리         │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [신규 부서(HR)의 데이터 마트(Data Mart) 구축 요건 발생]                   │
  │                │                                                  │
  │                ▼                                                  │
  │      신규 마트에 필요한 차원(예: '직원', '부서', '날짜')이 기존 DW 버스 매트릭스에 │
  │      이미 콘포밍 차원(Conformed Dimension)으로 정의되어 있는가?           │
  │          ├─ 예 ──▶ [ 기존 콘포밍 차원을 100% 그대로 재사용 (Re-use) ]      │
  │          │         - 대리 키(Surrogate Key) 매핑 로직 유지 필수         │
  │          │                                                        │
  │          └─ 아니오 (전사 최초로 도입되는 완전히 새로운 차원임)              │
  │                │                                                  │
  │                ▼                                                  │
  │      이 새로운 차원(예: '교육 이수 내역')이 미래에 다른 부서(영업, 재무)의 팩트와 │
  │      함께 묶여서(Drill-across) 통합 분석될 가능성이 있는가?                │
  │          ├─ 아니오 (완벽하게 HR 부서 내부에서만 쓰이는 고립된 데이터임)       │
  │          │      └──▶ [ 로컬 차원(Local Dimension)으로 빠르게 자체 개발 ]│
  │          │                                                        │
  │          └─ 예 (미래에 '직원 교육 수준에 따른 영업 실적' 같은 분석이 예상됨)   │
  │                │                                                  │
  │                ▼                                                  │
  │     [ 전사 데이터 거버넌스 위원회 소집 및 새로운 콘포밍 차원으로 승격(Promote)! ]│
  │       - 전사 아키텍트(DA)가 주도하여 속성명, 도메인, 대리 키 생성 규칙을 표준화 │
  │       - MDM 시스템 파이프라인에 태워 전사 공용 자산으로 중앙 배포           │
  │                                                                   │
  │   판단 포인트: "나 혼자 빨리 가려면 로컬 차원을 만들고, 다 함께 멀리 가려면       │
  │                귀찮더라도 콘포밍 차원으로 표준화의 십자가를 져야 한다."      │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 데이터 아키텍트(DA)의 가장 위대한 산출물은 'DW 버스 매트릭스(Bus Matrix)' 엑셀 문서다. 세로축에는 회사의 모든 비즈니스 프로세스(팩트)를 적고, 가로축에는 모든 콘포밍 차원(고객, 날짜, 제품 등)을 적어 'X'표를 치며 전사 데이터의 청사진을 그린다. 신규 마트를 지을 때 이 매트릭스를 확인하지 않고 테이블을 창조하는 것은 불법 건축물을 짓는 것과 같다. 만약 불가피하게 고립된 로컬 차원(Local Dimension)을 만들었더라도, 훗날 다른 부서에서 그 데이터를 탐내면 즉각 스키마를 정비하여 전사 콘포밍 차원으로 승격(Promotion)시키는 거버넌스 체계가 살아 숨 쉬어야 데이터 늪(Data Swamp)을 막을 수 있다.

📢 섹션 요약 비유: 콘포밍 차원을 정하는 과정은, 여러 나라(부서)가 모여서 "앞으로 무게의 단위는 파운드가 아니라 '킬로그램(Kg)'으로 무조건 통일하자!"라고 국제 도량형(표준)을 합의하는 험난한 외교 회담과 같습니다. 처음엔 내 단위를 버리는 게 귀찮지만, 통일하고 나면 전 세계 데이터 무역(조인 연산)이 막힘없이 뚫리게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	콘포밍 차원 부재 (사일로 방치)	콘포밍 차원 및 버스 아키텍처 도입 시	개선 효과
정량 (개발 시간)	매번 마트 만들 때마다 차원 테이블 새로 ETL 개발	기 만들어진 공통 차원을 그대로 복사/참조만 함	신규 데이터 마트 구축 리드 타임 70% 이상 극단적 단축
정량 (정합성)	부서 간 조인 불가, 수작업 엑셀 VLOOKUP 매핑	BI 툴에서 드릴 어크로스(Drill-across) 즉각 수행	크로스 도메인(Cross-domain) 쿼리 응답 시간 밀리초(ms) 단위 달성
정성 (거버넌스)	임원 회의 시 부서마다 다른 매출 지표 들고 싸움	"Single Source of Truth" (단일 진실 공급원) 확보	전사 데이터 신뢰도 100% 확보 및 데이터 리터러시 문화 정착

미래 전망

시맨틱 레이어 (Semantic Layer)로의 진화: 과거에는 콘포밍 차원을 물리적으로 DB 테이블에 똑같이 복사해서 심어주어야 했다. 현대 클라우드 데이터 스택(Modern Data Stack)에서는 dbt(Data Build Tool)나 Cube 같은 '시맨틱 레이어(의미론적 계층)' 미들웨어가 중간에 껴서, 물리적인 테이블은 각기 다르더라도 BI 툴로 넘어가기 직전에 코드로 짠 논리적 뷰(Logical View)를 통해 실시간으로 콘포밍 차원의 탈을 씌워버리는 논리적 데이터 가상화(Data Virtualization) 시대로 진화하고 있다.
데이터 메시 (Data Mesh)와의 철학적 결합: 중앙 집중형 DW를 거부하고 각 도메인 부서가 알아서 데이터를 개발하는 최신 '데이터 메시' 사상에서도, 도메인 간의 데이터(Data Product)를 엮기 위한 '글로벌 연합 룰(Global Federated Governance)'의 1원칙으로 킴볼의 콘포밍 차원 사상이 부활하여 필수적인 인터페이스 규약으로 재평가받고 있다.

참고 표준

The Data Warehouse Toolkit (Ralph Kimball): 상향식 DW 버스 아키텍처와 콘포밍 차원의 개념을 창시한 데이터 모델링의 바이블
DMBOK (Data Management Body of Knowledge): 국제 데이터 관리 협회(DAMA)가 정의한 기준 정보(Master Data) 및 차원 모델링 아키텍처 글로벌 표준

"통합되지 않는 데이터는 썩어가는 쓰레기에 불과하다." 기업이 수십억 원을 들여 하둡(Hadoop)이나 클라우드 데이터 레이크를 구축해도 임원들이 분노하는 이유는, 마케팅 데이터와 재무 데이터가 서로 맞물려 돌아가지 않아 "그래서 결국 마케팅에 쓴 돈이 매출로 이어졌는가?"라는 본질적인 질문에 대답하지 못하기 때문이다. 콘포밍 차원(Conformed Dimension)은 화려한 기술이 아니라 뼈를 깎는 약속이자 거버넌스다. 모든 부서가 나만의 이기적인 정의(Definition)를 버리고, 전사적인 룰(Rule)에 맞춰 대리 키와 속성을 철저히 통일하는 이 인내의 시간을 거쳐야만 비로소 데이터는 부서의 장벽을 넘어 흐르는 거대한 엔터프라이즈의 혈관으로 거듭날 수 있다.

📢 섹션 요약 비유: 수백만 개의 톱니바퀴(데이터 마트)가 모여 거대한 시계(전사 DW)를 돌리려면, 모든 톱니바퀴의 '이빨 간격(콘포밍 차원)'이 한 치의 오차도 없이 동일하게 깎여 있어야만 합니다. 이빨 규격이 하나라도 다르면 시계 전체가 박살 나며, 톱니를 똑같이 깎아내는 규격서가 바로 데이터 아키텍처의 핵심입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
스타 스키마 (Star Schema)	정중앙에 무거운 팩트(Fact) 테이블을 두고, 그 주변을 감싸는 차원(Dimension) 테이블로 구성된 모델. 콘포밍 차원은 이 별의 모서리(차원)를 규격화하는 작업이다.
드릴 어크로스 (Drill-across)	두 개 이상의 서로 다른 팩트 테이블을, 그들이 공통으로 바라보고 있는 콘포밍 차원을 매개체 삼아 하나로 조인/병합해 내는 다차원 분석의 꽃이다.
마스터 데이터 관리 (MDM)	회사 전역의 고객/제품 기준 정보를 하나로 클렌징하는 시스템으로, 여기서 만들어진 골든 레코드가 콘포밍 차원 테이블로 꽂히게 된다.
대리 키 (Surrogate Key)	콘포밍 차원 테이블의 PK로 쓰이는 무의미한 정수형 일련번호. 영업과 마케팅의 소스 코드가 달라도 이 대리 키를 발급받아 통일된 신원을 부여받는다.
데이터 사일로 (Data Silo)	콘포밍 차원 규칙을 지키지 않고 각자 부서 파티션에 데이터를 가둬둔 상태로, 데이터 통합을 막는 기업의 가장 큰 암적인 현상이다.

👶 어린이를 위한 3줄 비유 설명

학교에서 체육부장은 '달리기 1등', 미술부장은 '그림 1등'을 각각 자기 수첩(데이터 마트)에 적어뒀어요.
교장 선생님이 "우리 학교 1등들을 다 모아봐!"라고 했는데, 두 수첩에 적힌 친구들 이름표(차원) 모양이 달라서 누가 누군지 합칠 수가 없었어요.
그래서 교장 선생님이 "앞으로는 무조건 똑같이 생긴 '전교생 공통 학생증(콘포밍 차원)' 번호로만 기록해!"라고 규칙을 정해서, 어떤 수첩을 가져와도 1초 만에 합칠 수 있게 만든 거랍니다!