데이터 웨어하우스 방법론과 데이터 모델링 비교

파트 1: 핵심 데이터 웨어하우스 설계 방법론

데이터 웨어하우스(Data Warehouse, DW) 구축은 단순히 데이터를 한곳에 모으는 기술적 작업을 넘어, 기업의 비즈니스 인텔리전스(BI) 및 분석 역량을 좌우하는 전략적 결정입니다. 성공적인 데이터 웨어하우스는 조직의 데이터 자산을 신뢰할 수 있는 통찰력으로 전환하는 기반이 되지만, 잘못된 아키텍처 선택은 막대한 비용과 시간 낭비는 물론, 비즈니스 의사결정의 실패로 이어질 수 있습니다. 따라서 데이터 웨어하우스를 설계하는 데 사용되는 핵심 방법론들의 철학, 구조, 그리고 전략적 함의를 깊이 있게 이해하는 것은 모든 데이터 전문가에게 필수적입니다.

본 보고서의 첫 번째 파트에서는 데이터 웨어하우스 설계의 세 가지 주요 패러다임인 킴볼(Kimball), 인몬(Inmon), 그리고 데이터 볼트 2.0(Data Vault 2.0) 방법론을 심층적으로 분석합니다. 각 방법론의 기원과 핵심 원칙을 탐구하고, 아키텍처의 구조적 특징과 데이터 흐름을 상세히 설명하며, 어떤 비즈니스 상황과 전략적 목표에 각 방법론이 가장 적합한지에 대한 통찰을 제공할 것입니다. 이 비교 분석을 통해 각 방법론이 제시하는 장단점과 전략적 트레이드오프를 명확히 이해하고, 조직의 고유한 요구사항에 가장 부합하는 아키텍처를 선택하는 데 필요한 지침을 얻을 수 있을 것입니다.

섹션 1.1: 킴볼 방법론: 비즈니스 중심의 상향식 접근법

핵심 철학: 비즈니스 차원 수명주기와 신속한 가치 제공

랄프 킴볼(Ralph Kimball)이 주창한 킴볼 방법론은 데이터 웨어하우스 설계에 대한 근본적으로 상향식(Bottom-Up) 접근 방식을 취합니다. 이는 기업 전체의 데이터 모델을 한 번에 구축하려는 인몬의 하향식(Top-Down) 접근법과 뚜렷한 대조를 이룹니다. 킴볼 방법론의 핵심 동인은 '가치 실현 시간(Time-to-Value)'의 단축에 있습니다. 전체 기업을 대상으로 하는 거대하고 복잡한 프로젝트 대신, 특정 비즈니스 프로세스(예: 영업, 재고 관리) 하나에 집중하여 기능적으로 완전하고 유용한 데이터 마트(Data Mart)를 비교적 신속하게 제공하는 것을 목표로 합니다. 이러한 성공적인 초기 결과물은 데이터 웨어하우징 이니셔티브의 투자 대비 효과(ROI)를 입증하고, 조직 전체로 프로젝트를 확장해 나갈 동력을 확보하는 데 결정적인 역할을 합니다.

이러한 철학은 '비즈니스 차원 수명주기(Business Dimensional Lifecycle)'라는 개념에 집약되어 있습니다. 이 수명주기는 비즈니스 요구사항과 실제 소스 데이터의 현실을 파악하는 것을 모든 설계의 기초로 삼는다는 점을 강조합니다. 즉, 모든 모델링 과정은 철저히 비즈니스 중심적으로 이루어지며, 최종 사용자인 비즈니스 분석가들이 직관적으로 이해하고 쉽게 질의할 수 있는 모델을 구축하는 것을 지향합니다.

아키텍처 심층 분석: 데이터 웨어하우스 버스와 통합 차원의 역할

킴볼 아키텍처에서 개별적으로 구축된 데이터 마트들을 하나의 통합된 엔터프라이즈 데이터 웨어하우스로 묶어주는 핵심 메커니즘은 '데이터 웨어하우스 버스 아키텍처(Data Warehouse Bus Architecture)'입니다. 여기서 '버스'는 표준화된, 즉 '통합 차원(Conformed Dimensions)'이라는 공통의 프레임워크를 의미합니다.

통합 차원은 고객, 제품, 날짜 등과 같이 여러 비즈니스 프로세스에 걸쳐 공통으로 사용되는 마스터 차원을 의미하며, 여러 팩트 테이블과 데이터 마트에서 일관되게 공유되고 재사용됩니다. 이것이 킴볼 세계에서 데이터 통합을 달성하는 핵심 열쇠입니다. 예를 들어, 동일한 Dim_Product 테이블이 Fact_Sales 테이블과 Fact_Inventory 테이블 양쪽에 연결되면, 분석가들은 영업과 재고라는 두 가지 다른 비즈니스 프로세스를 넘나들며 데이터를 분석하는 '드릴 어크로스(Drill Across)'를 원활하게 수행할 수 있습니다. 통합 차원에 대한 엄격한 관리와 거버넌스가 없다면, 킴볼 접근법은 통합된 웨어하우스가 아닌, 서로 단절된 데이터 사일로의 집합으로 전락할 위험이 있습니다.

킴볼 버스 아키텍처는 백엔드 ETL 시스템과 프런트엔드 BI 애플리케이션 영역으로 나뉘며, 중앙에는 차원적으로 모델링된 데이터 마트들이 통합 차원을 통해 연결됩니다.

4단계 설계 프로세스: 실용적 가이드

킴볼은 각 차원 모델을 설계하기 위한 명확한 4단계 프로세스를 제시하며, 이 과정은 반드시 비즈니스 이해관계자들과의 협력적인 워크숍을 통해 진행되어야 한다고 강조합니다.

1. 비즈니스 프로세스 선택 (Select the Business Process): 모델링할 단일 핵심 비즈니스 활동(예: 주문 처리, 보험금 청구)을 식별합니다. 이는 구축할 데이터 마트의 범위를 정의합니다.
2. 세분성 선언 (Declare the Grain): 이는 전체 프로세스에서 가장 중요한 단계입니다. 세분성은 팩트 테이블의 한 행이 무엇을 의미하는지를 정확하게 정의합니다(예: "판매 주문의 한 라인 아이템", "계좌의 일일 잔고 스냅샷"). 가능한 한 가장 상세한 원자적(atomic) 세분성을 선택하는 것이 바람직합니다. 이는 분석의 유연성을 극대화하고, 향후 사용자들이 더 상세한 질문을 할 때 모델을 재설계해야 하는 필요성을 방지해 주기 때문입니다.
3. 차원 식별 (Identify the Dimensions): 팩트와 관련된 "누가, 무엇을, 어디서, 언제, 왜, 어떻게"라는 맥락을 결정합니다. 이러한 맥락 정보가 고객, 제품, 매장, 날짜와 같은 차원 테이블이 됩니다.
4. 팩트 식별 (Identify the Facts): 선언된 세분성 수준에서 비즈니스 프로세스와 관련된 측정 가능한 숫자 지표(예: 판매수량, 단가, 총금액)를 식별합니다.

전략적 적용: 킴볼 방법론을 사용해야 할 때

킴볼 방법론은 다음과 같은 시나리오에서 특히 효과적입니다.

• 특정 비즈니스 영역에 대한 분석 역량을 신속하게 제공해야 하는 조직이나 부서.
• 모델 자체가 비즈니스 사용자가 이해하기 쉽도록 설계되므로, 비즈니스 사용자들과의 협업이 긴밀한 팀.
• 애자일(Agile)하고 반복적인 개발 접근법을 선호하는 환경.

숨겨진 단순성의 대가

킴볼 방법론은 그 단순성과 신속성으로 널리 알려져 있습니다. 그러나 이러한 단순성은 최종 사용자의 편의를 위해 전면에 내세워진 것일 뿐, 그 이면에는 다른 곳으로 전가된 복잡성이 존재합니다.

킴볼 모델의 핵심인 비정규화된(denormalized) 스타 스키마는 사용자의 쿼리를 단순하고 성능이 뛰어나게 만듭니다. 하지만 이 비정규화된 구조를 생성하고 유지하기 위해서는 훨씬 더 복잡한 ETL(Extract, Transform, Load) 프로세스가 요구됩니다. ETL 팀은 여러 정규화된 소스 시스템에서 데이터를 통합하고, 복잡한 비즈니스 로직을 처리하며, 스타 스키마를 채우는 부담을 고스란히 떠안게 됩니다.

더 나아가, 기업 전체에 걸쳐 통합 차원을 일관되게 관리하는 것은 강력한 데이터 거버넌스와 전담 조직을 필요로 합니다. 이러한 노력이 없다면 각 데이터 마트의 차원들이 서로 다른 방향으로 발전하여 통합된 '버스' 아키텍처가 붕괴될 위험이 있습니다.

결론적으로, 킴볼 모델의 '단순성'은 전략적인 트레이드오프의 결과입니다. 이는 복잡성을 최종 사용자(쿼리)로부터 백엔드(ETL 및 거버넌스)로 이전시키는 것입니다. BI 및 분석 환경에서는 이것이 종종 올바른 선택이지만, 결코 '공짜'는 아닙니다. 킴볼 방법론을 채택하는 조직은 엔터프라이즈 규모의 성공을 위해 강력한 ETL 개발과 범부서적인 데이터 거버넌스에 상당한 투자를 할 준비가 되어 있어야 합니다. 첫 데이터 마트를 신속하게 제공하는 초기의 성공이 엔터프라이즈 통합에 필요한 장기적인 노력의 규모를 오판하게 만드는 착시를 일으킬 수 있습니다.

섹션 1.2: 인몬 방법론: 전사적 관점의 하향식 접근법

핵심 철학: 단일 통합 진실의 원천 구축

'데이터 웨어하우징의 아버지'로 불리는 빌 인몬(Bill Inmon)은 데이터 웨어하우스를 "주제 지향적이고, 통합적이며, 시계열적이고, 비휘발성인 데이터의 집합"으로 정의합니다. 이 정의는 그의 하향식 접근법의 철학적 핵심을 이룹니다. 인몬 방법론의 최우선 목표는 조직 전체를 위한 단일하고 권위 있는 진실의 원천(Single Source of Truth) 역할을 하는 중앙 집중식의 정규화된 엔터프라이즈 데이터 웨어하우스(Enterprise Data Warehouse, EDW)를 먼저 구축하는 것입니다. 이 EDW는 최종 사용자가 직접 쿼리하기 위한 것이 아니라, 모든 분석의 원천이 되는 기반으로 설계됩니다.

아키텍처 심층 분석: 기업 정보 공장(CIF)과 데이터 흐름

인몬의 아키텍처는 '기업 정보 공장(Corporate Information Factory, CIF)'으로 알려져 있으며, 데이터는 구조화된 하향식 방식으로 이 공장을 통과합니다.

1. 스테이징 영역 (Staging Area): 운영계 소스 시스템에서 추출된 데이터는 변환 및 정제를 위해 스테이징 영역으로 이동합니다.
2. 엔터프라이즈 데이터 웨어하우스 (EDW): 스테이징을 거친 데이터는 중앙 EDW로 적재됩니다. EDW는 데이터 중복을 최소화하고 데이터 무결성을 극대화하기 위해 제3정규형(3rd Normal Form, 3NF)으로 모델링됩니다.8 이곳에는 상세하고 원자적인 수준의 과거 데이터가 저장됩니다.
3. 데이터 마트 (Data Marts): 부서별 데이터 마트는 중앙 EDW로부터 데이터를 공급받아 생성됩니다. 이 데이터 마트들은 특정 비즈니스 부서(예: 마케팅, 재무)의 보고 및 분석 요구에 맞게 맞춤화되며, 종종 킴볼의 차원 모델(스타 스키마)을 사용합니다. 이는 중요한 차이점입니다. 인몬 모델에서 데이터 마트는 EDW에 종속적인 파생물인 반면, 킴볼 모델에서는 데이터 마트가 기본 구성 요소입니다.
4. 운영 데이터 저장소 (ODS): CIF는 비휘발성의 과거 데이터를 저장하는 EDW와 달리, 현재의 휘발성 데이터를 포함하여 거의 실시간에 가까운 운영 보고를 지원하기 위한 운영 데이터 저장소(Operational Data Store, ODS)를 포함할 수 있습니다.

인몬의 CIF 아키텍처는 운영 시스템에서 데이터를 추출하여 중앙의 정규화된 EDW로 통합한 후, 부서별 데이터 마트로 데이터를 공급하는 하향식 데이터 흐름을 보여줍니다.

EDW에서의 제3정규형(3NF)의 중심성

중앙 EDW를 3NF로 모델링하는 것은 인몬 접근법에서 타협할 수 없는 원칙입니다. 이러한 정규화는 데이터 중복을 줄여주며, 이는 특정 정보를 업데이트할 곳이 단 한 곳뿐이므로 ETL 프로세스를 단순화하고 기업 전체의 데이터 무결성과 일관성을 향상시키는 효과를 가져옵니다.

전략적 적용: 인몬 접근법이 유리한 시나리오

인몬 방법론은 다음과 같은 환경에 가장 적합합니다.

• 복잡하고 안정적인 비즈니스 프로세스를 가진 대규모의 성숙한 조직.
• 데이터 거버넌스, 데이터 품질, 그리고 단일 버전의 진실을 확보하는 것이 최우선 과제인 환경.
• 강력한 데이터 계보와 무결성을 요구하는 규제 및 컴플라이언스 요구사항이 많은 산업.

유연성의 역설

인몬 모델은 종종 구현이 느리고 경직된 것으로 묘사되는 반면, 그 중심에 있는 EDW의 정규화된 구조는 예측하지 못한 미래의 다양한 요구사항을 지원하는 데 있어 유연성이 높다고 평가받습니다. 이 두 가지 평가는 상충하는 것처럼 보이지만, 사실은 동전의 양면과 같습니다.

기업 전체를 포괄하는 포괄적인 3NF 모델을 설계하고 구축하는 초기 노력은 엄청납니다. 이는 모든 비즈니스 프로세스와 데이터 소스에 대한 깊은 사전 이해를 요구하며, 긴 프로젝트 기간으로 이어집니다. 이것이 바로 인몬 모델이 '느리다'는 평판을 얻게 된 주된 이유입니다.

그러나 일단 이 정규화된 기반이 구축되고 나면, 그 유연성은 매우 뛰어납니다. 데이터가 가장 원자적이고 비중복적인 형태로 저장되어 있기 때문에, 소스 시스템으로 돌아갈 필요 없이 새롭거나 예측하지 못했던 비즈니스 질문에 답하기 위해 어떤 종류의 데이터 마트(차원 모델, 플랫 파일 등)든 쉽게 재구성하여 만들 수 있습니다. 반면, 킴볼 모델은 사전에 정의된 차원의 틀 안에서만 유연합니다. 데이터의 다른 '관점'을 요구하는 새로운 질문에 답하기 위해서는 팩트 테이블을 재구축하거나 새로운 차원을 처음부터 만들어야 할 수도 있습니다.

결론적으로, 인몬 접근법은 단기적인 민첩성을 장기적인 전략적 유연성과 맞바꾸는 것입니다. '경직성'은 초기 구현 단계에 국한되며, 그 결과로 만들어진 아키텍처는 장기적으로 근본적인 비즈니스 변화에 훨씬 더 잘 적응할 수 있습니다. 이는 '유연성의 역설'을 만들어냅니다. 단기적으로 가장 민첩해 보이지 않는 방법론이 장기적으로는 가장 큰 아키텍처적 유연성을 제공하는 것입니다. 따라서 인몬과 킴볼 사이의 선택은 단순히 속도 대 품질의 문제가 아니라, 조직의 데이터 전략이 어느 정도의 시간 지평을 바라보고 있는지에 대한 질문이기도 합니다.

섹션 1.3: 데이터 볼트 2.0: 현대적이고 민첩하며 확장 가능한 접근법

핵심 철학: 민첩성, 감사 가능성, 병렬화를 위한 설계

댄 린스테트(Dan Linstedt)에 의해 개발된 데이터 볼트 2.0은 빅데이터, 클라우드 컴퓨팅, 애자일 개발과 같은 현대 데이터 환경의 도전에 대응하기 위해 설계된 하이브리드 방법론입니다. 전통적인 접근법들의 한계를 극복하는 것을 목표로 합니다. 데이터 볼트 2.0의 핵심 원칙은 유연성, 확장성, 일관성, 그리고 완벽한 감사 가능성입니다. 특히, 데이터를 병렬로 적재할 수 있도록 설계되어 대용량 데이터 처리에 매우 높은 확장성을 제공합니다.

아키텍처 심층 분석: 허브, 링크, 새틀라이트의 구성 요소

데이터 볼트 모델은 단순하면서도 강력한 세 가지 유형의 구성 요소로 이루어집니다.

1. 허브 (Hubs): 고유한 비즈니스 키(예: 고객번호, 제품SKU)만을 포함하며, 다른 속성은 담지 않습니다. 허브는 핵심 비즈니스 개념을 나타내며 모델의 안정적인 앵커 역할을 합니다.
2. 링크 (Links): 비즈니스 키 간의 관계나 트랜잭션을 표현합니다. 링크는 본질적으로 둘 이상의 허브를 연결하는 다대다(many-to-many) 조인 테이블입니다.
3. 새틀라이트 (Satellites): 허브나 링크에 대한 모든 설명적, 맥락적 속성을 저장합니다. 새틀라이트는 타임스탬프를 가지며 데이터의 모든 변경 이력을 추적하여, 설계 자체에 감사 가능한 이력을 내장합니다.

데이터 볼트 2.0 모델은 핵심 비즈니스 키를 담는 허브(Hubs), 허브 간의 관계를 정의하는 링크(Links), 그리고 허브나 링크에 대한 설명적 속성을 저장하는 새틀라이트(Satellites)로 구성됩니다.

내재된 강점: 변화에 대한 적응성과 새로운 소스의 원활한 통합

이 구조의 진정한 강점은 변화에 대한 놀라운 적응성에 있습니다. 새로운 데이터 소스가 추가되거나 비즈니스 프로세스가 변경될 때, 기존 모델을 재구성할 필요 없이 새로운 허브, 링크, 또는 새틀라이트를 추가하기만 하면 됩니다. 이는 아키텍처를 변화에 매우 탄력적으로 만듭니다.

예를 들어, 새로운 CRM 시스템으로부터 '고객'에 대한 새로운 속성이 들어온다면, 기존의 Hub_Customer에 새로운 Satellite_Customer_CRM 테이블을 생성하여 연결하기만 하면 됩니다. 기존 모델은 전혀 영향을 받지 않으므로, 개발 영향이 최소화되고 개발 시간이 단축됩니다. 이러한 모듈성은 대규모 병렬 개발 및 데이터 적재 작업을 가능하게 합니다.

전략적 적용: 복잡한 환경에서의 데이터 볼트 2.0 활용 사례

데이터 볼트 2.0은 다음과 같은 환경에서 이상적입니다.

• 다수의 이기종 소스 시스템을 통합해야 하는 조직.
• 인수 합병 등 비즈니스 환경의 변화가 잦고 역동적인 조직.
• 감사 가능성과 데이터 계보 추적이 법적 또는 규제적 요구사항으로 인해 매우 중요한 경우.
• 모델을 점진적으로, 그리고 여러 팀이 병렬적으로 구축하고 확장해야 하는 애자일 개발 환경.

데이터 볼트: "정규화된 원시 데이터 계층"으로서의 역할

데이터 볼트 2.0은 3NF와 스타 스키마의 하이브리드 모델로 설명됩니다. 그 핵심 구성 요소인 허브, 링크, 새틀라이트는 고도로 정규화된 형태를 띱니다.

실제로 데이터 볼트의 핵심 계층(종종 'Raw Vault'라 불림)은 인몬의 3NF EDW와 매우 유사한 목적, 즉 기업 데이터의 통합된 역사적 저장소 역할을 수행합니다. 비즈니스 키(허브), 관계(링크), 그리고 설명적 맥락(새틀라이트)을 분리하는 것은 전통적인 3NF보다 훨씬 더 세분화된 형태의 정규화라고 볼 수 있습니다.

인몬의 EDW와 마찬가지로, Raw Vault는 일반적으로 비즈니스 사용자가 직접 쿼리하지 않습니다. 대신, 비즈니스 사용자를 위한 정보 마트(종종 스타 스키마 형태)를 구축하는 탄력적인 기반 역할을 합니다.

결론적으로, 데이터 볼트 2.0은 킴볼이나 인몬과 직접적으로 경쟁하는 관계라기보다는, 인몬 아키텍처의 기반 계층을 현대적으로 재해석한 것으로 볼 수 있습니다. 이는 변경이 어렵고 경직된 3NF 모델을 더 유연하고, 적응성 있으며, 감사 가능한 정규화된 구조로 대체합니다. 따라서 현대의 조직은 핵심 EDW 구축에는 데이터 볼트를 채택하고, 사용자 대면 데이터 마트 구축에는 킴볼의 원칙을 사용하는 하이브리드 전략을 취할 수 있습니다. 오늘날의 아키텍처 논쟁은 "킴볼 대 인몬"이라기보다는 "중앙 통합 데이터 계층을 모델링하는 최상의 방법은 인몬의 3NF인가, 아니면 린스테트의 데이터 볼트인가?"라는 질문에 더 가깝습니다.

섹션 1.4: 방법론 비교 분석

이 섹션에서는 앞선 논의들을 종합하여 세 가지 방법론을 여러 중요한 차원에서 직접적으로 비교 분석합니다. 이 분석은 데이터 아키텍트가 아키텍처를 선택할 때 반드시 고려해야 할 전략적 트레이드오프에 초점을 맞춥니다. 아래의 요약 표는 이러한 트레이드오프를 한눈에 파악할 수 있는 참조 자료를 제공합니다.

속성	킴볼 방법론	인몬 방법론	데이터 볼트 2.0 방법론
설계 접근법	상향식 (Bottom-Up): 개별 비즈니스 프로세스에서 시작하여 전사적으로 통합	하향식 (Top-Down): 전사적 데이터 모델을 먼저 정의하고 부서별 데이터 마트로 전개	하이브리드/병렬: 비즈니스 키(Hub) 중심으로 점진적, 병렬적 확장
핵심 모델	차원 모델 (비정규화된 스타 스키마)	제3정규형 (3NF, 고도로 정규화됨)	데이터 볼트 모델 (Hub, Link, Satellite의 정규화된 조합)
데이터 중복성	높음 (쿼리 성능을 위해 의도적으로 비정규화)	매우 낮음 (중앙 EDW에서 중복 최소화)	낮음 (키와 속성을 분리하여 중복 최소화)
민첩성/적응성	중간: 초기 개발은 빠르나, 근본적인 비즈니스 변경 시 재설계 필요 가능성	낮음 (초기) / 높음 (장기): 초기 구축은 느리지만, 구축 후 새로운 요구사항에 대한 유연성 높음	매우 높음: 새로운 소스나 변경사항을 기존 구조 수정 없이 추가 가능
초기 구현 속도	빠름: 특정 비즈니스 영역에 집중하여 신속한 가치 제공 가능	느림: 전사적 모델링과 통합에 많은 초기 시간과 노력 필요	빠름 (점진적): 애자일 방식으로 작은 단위로 빠르게 구축 및 확장 가능
주요 목표	비즈니스 사용자의 사용 편의성 및 빠른 쿼리 성능	데이터 무결성, 일관성, 그리고 전사적 '단일 진실 공급원' 구축	감사 가능성, 확장성, 그리고 변화에 대한 아키텍처의 탄력성
이상적인 사용 사례	부서 단위 BI, 빠른 프로토타이핑, 분석 요구사항이 명확한 경우	대규모 기업, 데이터 거버넌스가 최우선인 안정된 환경, 규제 준수 요구가 높은 산업	다수의 이기종 소스 시스템, 비즈니스 변화가 잦은 동적 환경, 애자일 개발

파트 2: 기초 데이터 모델링 기법

데이터 웨어하우스 아키텍처를 실제로 구현하기 위해서는 파트 1에서 논의된 거시적인 방법론들을 구성하는 구체적인 빌딩 블록과 설계 패턴에 대한 깊은 이해가 필수적입니다. 이 파트에서는 모든 데이터 전문가가 반드시 숙지해야 할 핵심적인 데이터 모델링 기법들을 상세히 다룹니다. 차원 모델링의 기본 요소인 팩트와 차원 테이블의 역할부터 시작하여, 분석 성능과 데이터 구조의 복잡성 사이에서 균형을 잡는 스타 스키마와 눈송이 스키마의 차이점을 비교합니다. 또한, 데이터 무결성의 근간이 되는 데이터 정규화 원칙과, 데이터 웨어하우스의 분석 능력과 미래 유연성을 결정짓는 가장 중요한 개념인 데이터 세분성(granularity)의 전략적 의미를 탐구합니다. 이러한 기초 기법들에 대한 확고한 이해는 견고하고 효율적인 데이터 웨어하우스를 구축하는 데 있어 가장 중요한 자산이 될 것입니다.

섹션 2.1: 차원 모델링: 비즈니스 분석의 언어

소개

차원 모델링(Dimensional Modeling)은 데이터를 분석에 용이하고 성능이 뛰어나도록 만드는 가장 핵심적인 기법입니다. 이는 킴볼 방법론의 근간을 이루며, 인몬 및 데이터 볼트 접근법에서도 최종 사용자에게 데이터를 제공하는 데이터 마트 계층에서 널리 사용됩니다. 차원 모델은 항상 측정값인 '팩트(facts)'와 맥락 정보인 '차원(dimensions)'이라는 두 가지 핵심 개념으로 구성됩니다.

팩트 테이블: 비즈니스 이벤트와 지표 포착

• 역할 및 특징: 팩트 테이블은 비즈니스 프로세스의 양적 측정값을 저장하는 차원 모델의 중심입니다.12 일반적으로 숫자 형태의 가산(additive)이 가능한 데이터와, 차원 테이블을 연결하는 외래 키(foreign key)로 구성되는 것이 특징입니다. 팩트 테이블은 보통 행의 수는 매우 많고(deep), 열의 수는 적습니다(narrow).
• 예시: Fact_Sales 테이블은 판매수량, 총판매금액과 같은 측정값과 함께 제품_키, 고객_키, 날짜_키와 같은 외래 키를 포함합니다.
• 팩트 테이블 유형: 단일 이벤트를 한 행에 기록하는 '트랜잭션(Transactional) 팩트 테이블', 특정 기간의 상태를 요약하는 '주기적 스냅샷(Periodic Snapshot) 팩트 테이블', 그리고 시작과 끝이 명확한 프로세스의 경과를 추적하는 '누적 스냅샷(Accumulating Snapshot) 팩트 테이블' 등 다양한 유형이 있습니다.

차원 테이블: 필수적인 맥락 제공

• 역할 및 특징: 차원 테이블은 팩트에 대한 설명적인 텍스트 기반의 맥락을 제공합니다. "누가, 무엇을, 어디서, 언제"와 같은 질문에 답하는 역할을 합니다. 일반적으로 속성을 담은 열의 수는 많고(wide), 행의 수는 팩트 테이블보다 훨씬 적습니다(shallow).
• 예시: Dim_Product 테이블은 SKU, 제품명, 브랜드, 카테고리, 색상과 같은 속성들을 포함합니다.
• 핵심 개념: 차원 모델링에서는 대리 키(surrogate key)의 사용이 중요하며, 시간의 흐름에 따른 속성 변경을 추적하기 위한 '느리게 변화하는 차원(Slowly Changing Dimensions, SCDs)', 팩트 테이블의 외래 키로만 존재하는 '퇴화 차원(Degenerate Dimensions)', 그리고 여러 자잘한 속성들을 모아놓은 '정크 차원(Junk Dimensions)' 등 특수한 유형의 차원들이 활용됩니다.

중앙의 팩트 테이블(Fact_Sales)은 측정값(Units_Sold)과 차원 테이블에 대한 외래 키를 포함합니다. 주변의 차원 테이블(Dim_Date, Dim_Store, Dim_Product)은 팩트에 대한 설명적 맥락을 제공합니다.

섹션 2.2: 스키마 아키텍처: 스타 스키마 vs. 눈송이 스키마

스타 스키마: 단순성과 쿼리 성능에 최적화

• 구조: 중앙의 팩트 테이블이 여러 개의 비정규화된 차원 테이블에 직접 연결된 형태를 가집니다. 이 단순한 허브-앤-스포크(hub-and-spoke) 구조는 이해하기 쉽고 쿼리가 간단하다는 장점이 있습니다.
• 장점: 조인(join)의 수가 적어 쿼리가 단순해지고, 특히 BI 도구에서 빠른 성능을 보입니다. 이는 킴볼 방법론에서 선호되는 표준 스키마입니다.
• 단점: 차원 내 데이터 중복으로 인해 더 많은 저장 공간이 필요하며, ETL을 통해 신중하게 관리하지 않으면 데이터 업데이트 시 이상 현상(anomaly)이 발생할 수 있습니다.

스타 스키마는 중앙의 팩트 테이블이 각 차원 테이블에 직접 연결되는 단순한 구조를 가집니다.

눈송이 스키마: 데이터 무결성과 저장 효율에 최적화

• 구조: 눈송이 스키마는 스타 스키마를 더 정규화한 버전입니다. 차원 테이블이 여러 개의 연관된 테이블로 정규화되어, 마치 눈송이처럼 계층적인 구조를 형성합니다.
• 장점: 정규화를 통해 데이터 중복을 줄여 저장 공간을 절약하고, 속성이 단 한 곳에만 저장되고 업데이트되므로 데이터 무결성을 향상시킵니다.
• 단점: 테이블 수가 많아져 더 많은 조인이 필요한 복잡한 쿼리를 생성하게 되며, 이는 전통적으로 쿼리 성능 저하의 원인이 되었습니다.

눈송이 스키마는 스타 스키마의 차원 테이블을 정규화하여 하위 차원 테이블로 분리한 계층적 구조를 가집니다. 예를 들어, Product 차원이 Brand와 Category로 나뉩니다.

상세 비교 및 실용적 가이드

두 스키마 간의 선택은 더 이상 단순히 성능만의 문제가 아닙니다. 현대 클라우드 데이터 웨어하우스는 컬럼 기반 저장, 자동 클러스터링, 지능형 쿼리 캐싱과 같은 기술을 통해 두 스키마 간의 성능 격차를 크게 줄이고 있습니다. 벤치마크에 따르면, 최적화된 환경에서 눈송이 스키마는 스타 스키마 성능의 90% 수준에 도달할 수 있으며, 그 차이는 약 11%에 불과할 수 있습니다.

따라서 선택의 기준은 보다 전략적인 관점에서 이루어져야 합니다. 스타 스키마는 속도와 단순성이 가장 중요한 직선적인 데이터 마트에 탁월한 선택입니다. 반면, 눈송이 스키마는 차원이 매우 크고 복잡하며, 자연스러운 계층 구조를 가지고 있고, 데이터 무결성과 장기적인 유지보수성이 중요한 경우에 더 나은 선택이 될 수 있습니다.

비교 항목	스타 스키마	눈송이 스키마
핵심 구조	비정규화됨. 중앙 팩트 테이블과 직접 연결된 단일 차원 테이블들.	정규화됨. 차원 테이블이 여러 하위 차원 테이블로 분리된 계층 구조.
쿼리 성능	빠름. 조인 수가 적어 쿼리가 단순하고 효율적. (전통적 시스템에서 40-60% 우위)	상대적으로 느림. 다수의 조인으로 인해 쿼리가 복잡해짐. (클라우드 DW에서 성능 격차 감소)
저장 공간	높음. 차원 내 데이터 중복으로 인해 더 많은 저장 공간 필요.	낮음. 정규화를 통해 데이터 중복을 제거하여 저장 공간 효율화. (25-40% 절감)
데이터 무결성 및 유지보수	중간. 데이터 중복으로 인해 업데이트 이상 현상 발생 가능. 유지보수 복잡성 증가.	높음. 데이터가 한 곳에만 저장되어 업데이트가 용이하고 일관성 유지에 유리.
분석가 사용 편의성	높음. 구조가 직관적이고 단순하여 비즈니스 사용자가 이해하고 쿼리하기 쉬움.	낮음. 복잡한 계층 구조와 다수의 조인으로 인해 쿼리 작성이 더 어려움.
이상적인 사용 사례	BI 대시보드, 보고용 데이터 마트, 속도와 단순성이 최우선인 분석 환경.	매우 크고 복잡한 차원, 자연스러운 계층 구조(예: 지역, 조직도), 데이터 무결성이 중요한 경우.

섹션 2.3: 데이터 정규화의 원칙

목표: 중복성 감소와 이상 현상 방지

정규화(Normalization)는 관계형 데이터베이스에서 데이터 중복을 최소화하기 위해 테이블과 열을 체계적으로 구성하는 프로세스입니다. 정규화의 주된 이점은 데이터 무결성을 저해할 수 있는 데이터 이상 현상(anomalies)을 방지하는 데 있습니다. 이러한 이상 현상에는 새로운 데이터를 입력하기 어려운 '삽입 이상', 특정 데이터를 삭제할 때 의도치 않은 다른 데이터까지 삭제되는 '삭제 이상', 그리고 데이터를 수정할 때 여러 곳을 일관되게 변경하지 못해 발생하는 '갱신 이상'이 포함됩니다.

제1, 2, 3 정규형(1NF, 2NF, 3NF) 해설

정규화는 여러 단계의 '정규형'으로 정의되며, 여기서는 가장 기본적이고 필수적인 첫 세 가지 정규형을 하나의 일관된 예제를 통해 단계별로 설명합니다.

• 1NF (제1정규형): 테이블의 모든 열이 원자적(atomic) 값을 가져야 한다는 규칙입니다. 즉, 하나의 셀에 여러 값이나 반복되는 그룹이 포함되어서는 안 되며, 각 행은 고유해야 합니다.21 예를 들어, '구매 제품' 열에 '노트북, 마우스'와 같이 여러 값이 쉼표로 구분되어 있다면 1NF를 위반한 것입니다. 이를 해결하려면 각 제품을 별도의 행으로 분리해야 합니다.
• 2NF (제2정규형): 테이블이 1NF를 만족하고, 모든 비주요 속성(non-key attribute)이 복합 기본 키(composite primary key)의 전체에 완전 함수 종속(fully functionally dependent)되어야 합니다. 이는 복합 키의 일부에만 종속되는 '부분 함수 종속성'을 제거하는 것을 의미합니다. 예를 들어, (주문ID, 제품ID)가 기본 키인 테이블에서 '제품명'이 '제품ID'에만 종속된다면, 이는 부분 종속성이므로 '제품' 테이블을 별도로 분리해야 합니다.
• 3NF (제3정규형): 테이블이 2NF를 만족하고, 비주요 속성 간에 종속 관계가 없어야 합니다. 즉, 기본 키가 아닌 다른 속성에 종속되는 '이행적 함수 종속성(transitive functional dependency)'을 제거해야 합니다. 예를 들어, '주문' 테이블에서 '고객ID'가 '고객명'을 결정하고, '고객명'이 '고객등급'을 결정한다면, '고객등급'은 '고객ID'에 이행적으로 종속됩니다. 이를 해결하려면 '고객' 테이블을 분리하여 직접적인 종속 관계만 남겨야 합니다.

데이터 정규화는 비정규화된 테이블에서 반복 그룹을 제거하여 1NF를 만들고, 부분 종속성을 제거하여 2NF를, 이행 종속성을 제거하여 3NF를 만드는 과정입니다.

인몬 vs. 킴볼 아키텍처에서의 정규화 역할

• 인몬: 데이터 무결성과 유연성을 보장하기 위해 중앙 EDW를 3NF로 모델링하는 것을 핵심 원칙으로 삼습니다.
• 킴볼: 사용자 대면 데이터 마트에서는 쿼리 성능과 단순성을 향상시키기 위해 의도적으로 데이터를 비정규화하여 스타 스키마를 만듭니다. 정규화는 여전히 소스 시스템과, 최종 변환 전의 스테이징 영역에서는 중요한 역할을 합니다.

섹션 2.4: 세분성의 핵심 개념

"세분성" 정의: 차원 설계에서 가장 중요한 단계

세분성(Granularity)은 팩트 테이블에 저장되는 데이터의 상세 수준 또는 깊이를 의미합니다. 킴볼의 4단계 프로세스에서 '세분성 선언'은 가능한 모든 분석의 경계를 설정하기 때문에 가장 중요한 단계로 간주됩니다. 하나의 팩트 테이블은 반드시 단일하고 균일한 세분성을 가져야 합니다. 예를 들어, 일별 판매 데이터와 월별 판매 데이터를 같은 팩트 테이블에 혼합하여 저장할 수 없습니다.

트레이드오프 분석: 상세 수준 vs. 성능 및 저장 공간

• 높은 세분성 (예: 개별 거래 건): 최대의 분석적 상세함과 유연성을 제공합니다. 사용자가 데이터를 어떤 방식으로든 '자르고 쪼개어(slice and dice)' 분석할 수 있게 해줍니다. 그러나 더 많은 저장 공간을 필요로 하며, 고수준의 요약 쿼리에 대해서는 성능이 저하될 수 있습니다.
• 낮은 세분성 (예: 일별 요약): 더 적은 저장 공간을 필요로 하며 요약 보고서에 대해 빠른 성능을 제공합니다. 그러나 세부 정보가 영구적으로 손실된다는 치명적인 단점이 있습니다. 만약 일별 총 판매액만 저장한다면, 시간대별 판매 패턴이나 개별 고객의 거래 내역은 절대로 분석할 수 없게 됩니다.

세분성이 분석 능력과 미래 유연성에 미치는 영향

가장 근본적인 규칙은, 상세한 데이터(높은 세분성)는 언제든지 요약 수준으로 집계할 수 있지만, 요약된 데이터(낮은 세분성)는 절대로 다시 상세 수준으로 분해할 수 없다는 것입니다.

따라서 거의 모든 경우에 최선의 방법은 가능한 가장 원자적인(가장 높은) 세분성으로 데이터를 포착하는 것입니다. 저장 공간은 비교적 저렴하지만, 미래의 중요한 비즈니스 질문에 답할 수 없는 기회비용은 매우 비싸기 때문입니다.

세분성이 전체 데이터 생태계에 미치는 파급 효과

세분성에 대한 논의는 종종 데이터 웨어하우스 내부의 트레이드오프(저장 공간 대 상세 수준)에 국한되곤 합니다. 그러나 세분성 결정의 영향은 훨씬 더 광범위하며, 전체 데이터 가치 사슬에 걸쳐 파급 효과를 일으킵니다.

팩트 테이블의 세분성 선택은 단순히 해당 테이블의 설계에만 영향을 미치는 것이 아닙니다. 첫째, 이는 관련된 모든 차원 테이블의 설계에 직접적인 영향을 미칩니다. 만약 세분성이 '일별 매장 판매'라면, Dim_Product 차원은 개별 제품 수준이 아니라 카테고리 수준으로 설계될 수도 있습니다. 둘째, 데이터를 적재하는 데 필요한 ETL/ELT 프로세스의 복잡성과 성능을 좌우합니다. ETL 과정에서 데이터를 집계하는 것은 계산 집약적인 작업입니다.

가장 중요한 것은, 세분성이 다운스트림 애플리케이션의 정교함에 대한 명확한 상한선을 설정한다는 점입니다. 만약 영업 데이터가 일별 지역 요약 수준으로만 저장된다면, 데이터 사이언스 팀은 고객 수준의 이탈 예측 모델을 결코 구축할 수 없습니다.

결론적으로, 세분성 결정은 단순한 기술적 설계 선택이 아니라, 근본적인 비즈니스 전략 결정입니다. 이는 조직의 데이터 자산이 가질 수 있는 궁극적인 분석 및 예측 능력을 미리 결정합니다. 프로젝트 초기에 필요한 세분성을 잘못 판단하면, BI 도구와 데이터 사이언스 팀에 대한 수백만 달러의 투자가 무효화될 수 있습니다. 왜냐하면 그들이 필요로 하는 기초 데이터가 애초에 존재하지 않기 때문입니다. 이는 '세분성 선언' 단계를 기술적 과업에서, BI 분석가뿐만 아니라 데이터 과학자 및 고위 비즈니스 리더까지 반드시 참여해야 하는 중요한 전략적 검토 지점으로 격상시킵니다.

결론 및 전략적 권고

본 보고서는 데이터 웨어하우스 설계의 세 가지 핵심 방법론(킴볼, 인몬, 데이터 볼트 2.0)과 이를 구현하는 데 필요한 기초 데이터 모델링 기법(차원 모델링, 스키마, 정규화, 세분성)에 대한 심층적인 비교 분석을 제공했습니다. 분석을 통해 각 접근법이 고유한 철학, 아키텍처, 그리고 전략적 트레이드오프를 가지고 있으며, '최고'의 솔루션이 아닌 '가장 적합한' 솔루션만이 존재함을 확인했습니다.

킴볼 방법론은 비즈니스 프로세스 중심의 상향식 접근을 통해 신속한 가치 제공에 중점을 두며, 분석가의 사용 편의성을 극대화합니다. 그러나 그 단순성은 복잡한 ETL 및 거버넌스 비용을 수반합니다. 반면, 인몬 방법론은 전사적 관점의 하향식 접근을 통해 데이터 무결성과 일관성을 최우선으로 하며, 장기적인 아키텍처 유연성을 확보하지만 초기 구현에 상당한 시간과 노력이 필요합니다. 데이터 볼트 2.0은 이 두 방법론의 한계를 극복하기 위해 등장한 현대적 대안으로, 민첩성, 확장성, 감사 가능성을 핵심 가치로 삼으며, 특히 변화가 잦고 복잡한 데이터 환경에서 강력한 탄력성을 제공합니다.

이러한 분석을 바탕으로, 조직의 상황에 맞는 최적의 데이터 웨어하우스 전략을 수립하기 위한 다음과 같은 권고안을 제시합니다.

1. 조직의 목표와 성숙도에 따라 방법론을 선택하십시오.

• 신속한 성과가 필요한 부서 단위 프로젝트: 특정 비즈니스 영역에서 빠른 분석 역량 확보가 목표라면 킴볼 방법론으로 시작하는 것이 가장 효과적입니다. 이는 즉각적인 ROI를 보여주고 조직 내 데이터 문화 확산의 발판이 될 수 있습니다.
• 전사적 데이터 거버넌스가 최우선인 경우: 데이터 품질, 일관성, 그리고 규제 준수가 비즈니스의 핵심 요구사항이라면 인몬 방법론이 제공하는 중앙 집중식의 강력한 통제 구조가 더 적합합니다. 이는 장기적인 관점에서 안정적이고 신뢰할 수 있는 데이터 기반을 구축합니다.
• 복잡하고 동적인 데이터 환경: 다수의 이기종 소스 시스템을 통합해야 하거나, 비즈니스 환경이 끊임없이 변화하여 아키텍처의 유연성이 무엇보다 중요하다면 데이터 볼트 2.0을 핵심 통합 계층으로 고려해야 합니다. 이는 애자일 개발 방식과 가장 잘 부합합니다.

1. 하이브리드 아키텍처를 적극적으로 고려하십시오.
2. 현대의 데이터 아키텍처는 단일 방법론을 고수하기보다 각 방법론의 장점을 결합하는 하이브리드 형태로 발전하고 있습니다. 가장 효과적인 모델 중 하나는 데이터 볼트 2.0을 중앙 데이터 통합 계층(EDW)으로 사용하고, 그 위에 킴볼의 스타 스키마를 사용하여 비즈니스 목적에 맞는 데이터 마트를 구축하는 것입니다. 이 접근법은 데이터 볼트의 확장성과 유연성, 감사 가능성을 통해 견고한 데이터 기반을 마련하고, 킴볼의 직관적인 차원 모델을 통해 최종 사용자에게 최적의 분석 환경을 제공하는, 두 세계의 장점을 모두 취하는 전략입니다.
3. 세분성 결정을 전략적 의사결정으로 격상시키십시오.
4. 데이터의 세분성은 기술적 세부사항이 아니라, 조직의 미래 분석 역량을 결정짓는 가장 중요한 전략적 선택입니다. 이 결정은 반드시 BI 분석가, 데이터 과학자, 그리고 핵심 비즈니스 리더가 함께 참여하여 내려야 합니다. 가능한 가장 원자적인 수준의 세분성을 확보하는 것을 원칙으로 삼되, 비용과 성능의 현실적인 제약을 고려하여 최적의 균형점을 찾아야 합니다.
5. 모델링 기법을 목적에 맞게 적용하십시오.

• 분석 계층: 최종 사용자가 직접 상호작용하는 데이터 마트 계층에서는 쿼리 성능과 이해 용이성을 위해 스타 스키마를 기본으로 채택하는 것이 바람직합니다.
• 통합 계층: 중앙 EDW 계층에서는 데이터 무결성과 장기적 유연성을 위해 3NF(인몬) 또는 데이터 볼트 모델과 같은 정규화된 구조를 사용해야 합니다.

결론적으로, 성공적인 데이터 웨어하우스 아키텍처는 조직의 현재 요구사항을 충족시키는 동시에 미래의 불확실성에 유연하게 대처할 수 있어야 합니다. 본 보고서에서 제시된 심층 분석과 전략적 권고안이 각 조직의 고유한 상황에 맞는 최적의 아키텍처를 설계하고, 데이터를 진정한 전략적 자산으로 전환하는 여정에 있어 신뢰할 수 있는 나침반이 되기를 바랍니다.

참고 자료

1. Dimensional modeling - Wikipedia, 8월 31, 2025에 액세스, https://en.wikipedia.org/wiki/Dimensional_modeling
2. Kimball's Dimensional Data Modeling | The Analytics Setup ..., 8월 31, 2025에 액세스, https://www.holistics.io/books/setup-analytics/kimball-s-dimensional-data-modeling/
3. Kimball Dimensional Modeling Techniques, 8월 31, 2025에 액세스, https://www.kimballgroup.com/wp-content/uploads/2013/08/2013.09-Kimball-Dimensional-Modeling-Techniques11.pdf
4. Dimensional Modeling Techniques - Kimball Group, 8월 31, 2025에 액세스, https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/
5. Dimensional Model | Your Data Universe - Medium, 8월 31, 2025에 액세스, https://medium.com/your-data-universe/kimballs-dimensional-modeling-f64c559cdfed
6. DMBoK Figure 80 The Corporate ... - DAMA - Rocky Mountain Chapter, 8월 31, 2025에 액세스, https://damarmc.org/news/13419375
7. The Evolution of the Corporate Information Factory | EWSolutions, 8월 31, 2025에 액세스, https://www.ewsolutions.com/evolution-corporate-information-factory/
8. Best Practices for Data Warehouse Architecture - The Kimball/Inmon Hybrid - Blue Margin, 8월 31, 2025에 액세스, https://www.bluemargin.com/wp-content/uploads/2024/08/White-Paper-Architecture-Best-Practices-and-the-Modern-Data-Warehouse.pdf
9. Data Vault 2.0: A Modern Approach to Enterprise Data Modeling, 8월 31, 2025에 액세스, https://www.navicat.com/en/company/aboutus/blog/3323-data-vault-2-0-a-modern-approach-to-enterprise-data-modeling.html
10. Data Vault 2.0 Definition – Scalefree Expertise, 8월 31, 2025에 액세스, https://www.scalefree.com/consulting/data-vault-2-0/
11. Direct Data Vault 2 Consulting From The Data Vault Alliance - DataVaultAlliance, 8월 31, 2025에 액세스, https://datavaultalliance.com/dva-elite-services/
12. database - Difference between Fact table and Dimension table ..., 8월 31, 2025에 액세스, https://stackoverflow.com/questions/20036905/difference-between-fact-table-and-dimension-table
13. Fact Vs. Dimension Tables Explained - Monte Carlo Data, 8월 31, 2025에 액세스, https://www.montecarlodata.com/blog-fact-vs-dimension-tables-in-data-warehousing-explained/
14. Fact Table vs. Dimension Table: What's the Difference? | Built In, 8월 31, 2025에 액세스, https://builtin.com/articles/fact-table-vs-dimension-table
15. Difference between Fact Table and Dimension Table - GeeksforGeeks, 8월 31, 2025에 액세스, https://www.geeksforgeeks.org/computer-networks/difference-between-fact-table-and-dimension-table/
16. Star schema vs Snowflake: Choose the right data fit - Fivetran, 8월 31, 2025에 액세스, https://www.fivetran.com/learn/star-schema-vs-snowflake
17. Star Schema vs Snowflake Schema: Differences & Use Cases - DataCamp, 8월 31, 2025에 액세스, https://www.datacamp.com/blog/star-schema-vs-snowflake-schema
18. Star Schema vs Snowflake Schema: 6 Key Differences - ThoughtSpot, 8월 31, 2025에 액세스, https://www.thoughtspot.com/data-trends/data-modeling/star-schema-vs-snowflake-schema
19. Star Schema vs Snowflake Schema: Which Is Better for Your Data ..., 8월 31, 2025에 액세스, https://airbyte.com/data-engineering-resources/star-schema-vs-snowflake-schema
20. Normalization in Database | 1NF, 2NF, 3NF | by Sohaib Anser - Medium, 8월 31, 2025에 액세스, https://sohaibanser.medium.com/normalization-in-database-1nf-2nf-3nf-c0e734e8e05c
21. Database Normalization: 1NF, 2NF, 3NF & BCNF Examples ..., 8월 31, 2025에 액세스, https://www.digitalocean.com/community/tutorials/database-normalization
22. Normal Forms in DBMS - GeeksforGeeks, 8월 31, 2025에 액세스, https://www.geeksforgeeks.org/dbms/normal-forms-in-dbms/
23. Database normalization - Wikipedia, 8월 31, 2025에 액세스, https://en.wikipedia.org/wiki/Database_normalization
24. Granularity in Data Warehousing | Dremio, 8월 31, 2025에 액세스, https://www.dremio.com/wiki/granularity-in-data-warehousing/