💡 핵심 인사이트 스타 스키마(Star Schema)는 데이터 웨어하우스 다차원 모델링에서 **"팩트 테이블 1개가 차원 테이블들의 중심에 위치하고, 각 차원 테이블이 방사형으로 연결되는 단순하고 직관적인 구조"**입니다. 별(Star)의 중심에 팩트 테이블이, 각 꼭짓점에 차원 테이블이 위치하여 그 모양이 별(Star)과 유사하여 이렇게 불립니다. 조인 구조가 단순하고, 분석가와 개발자 모두에게 이해하기 쉽다는 장점으로 인해 데이터 웨어하우스의 사실상의 표준 모델로 자리 잡았습니다.


Ⅰ. 스타 스키마의 기본 구조: 중심과 방사

스타 스키마의 이름은 그 구조적 모양에서 비롯됩니다. 中央에 팩트 테이블이 있고, 주변에 차원 테이블들이 방사형으로 연결되어 있습니다.

[스타 스키마 구조]

                    ┌──────────────┐
                    │   시간_차원   │
                    │  (Time)      │
                    │ - 날짜 키     │
                    │ - 연도        │
                    │ - 분기        │
                    │ - 월          │
                    │ - 주          │
                    │ - 일          │
                    └──────┬───────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
            │              │              │
    ┌───────┴───────┐ ┌────┴────┐ ┌──────┴──────┐
    │   제품_차원    │ │ 지점_차원 │ │   고객_차원  │
    │  (Product)    │ │ (Store)  │ │  (Customer)│
    │ - 제품 키     │ │ - 지점 키 │ │ - 고객 키   │
    │ - 제품명      │ │ - 지점명  │ │ - 고객명    │
    │ - 카테고리    │ │ - 지역    │ │ - 연령대    │
    │ - 브랜드      │ │ - 주소    │ │ - 성별      │
    │ - 제조사      │ │ - 면적    │ │ - 고객 등급 │
    └───────┬───────┘ └────┬────┘ └──────┬──────┘
            │              │              │
            │              │              │
            └──────────────┼──────────────┘
                           │
                    ┌──────┴───────┐
                    │  판매_팩트    │
                    │  (Sales)     │
                    │ ─────────────│
                    │ - 판매 키    │
                    │ - 시간 키(FK)│
                    │ - 제품 키(FK)│
                    │ - 지점 키(FK)│
                    │ - 고객 키(FK)│
                    │ - 매출액     │
                    │ - 판매수량   │
                    │ - 할인금액   │
                    │ - 원가       │
                    └──────────────┘

다이어그램 해석: 모든 차원 테이블이 직접적으로 팩트 테이블에만 연결됩니다. 차원 테이블끼리 서로 직접 연결되지 않으며, 이는 조회의 단순성을 보장합니다. 분석 시 "2024년 1분기 서울 지역에서 노트북 브랜드 A의 매출"을 구하고 싶다면, 시간-제품-지점 차원에서 해당 키 값들을 찾아 팩트 테이블과 단 세 번의 조인으로 결과를 얻을 수 있습니다.


Ⅱ. 팩트 테이블의 설계: 측정값과 외래 키

스타 스키마에서 팩트 테이블은 분석의核心이 되는 **측정값(Measure)**들을 저장합니다. 판매 데이터라면 "매출액, 판매 수량, 할인 금액, 원가, 이윤".

팩트 테이블 설계 시 고려사항:

1. 외래 키(Foreign Key)의 선택 각 차원에 대한 외래 키는 **해당 차원 테이블의 기본 키(Primary Key)**를 참조합니다. 시간 차원의 "날짜_키", 제품 차원의 "제품_키" 등이 여기에 해당합니다. 이 외래 키 조합이 팩트 테이블의 **복합 기본 키(Composite Primary Key)**를 형성하는 경우도 있습니다.

2. 측정값의 유형

  • 누적 측정값(Additive Measure): "매출액, 판매 수량"처럼 모든 차원에 대해 합산(SUM)이 가능한 측정값입니다.
  • 비누적 측정값(Non-Additive Measure): "재고율, 비율"처럼 합산하면 의미가 없어지는 측정값입니다.
  • 반누적 측정값(Semi-Additive Measure): "재고 수량"처럼 시간 차원을 제외한 다른 차원에서는 합산이 가능한 측정값입니다.

3. 팩트 테이블의 규모 팩트 테이블은 시간이 지남에 따라 지속적으로 데이터가 누적됩니다. 초대용량 데이터(数억~数조 행)를 처리하기 위해 파티셔닝, 클러스터링, 압축 등의 물리적 설계 기법이 필수적입니다.


Ⅲ. 차원 테이블의 설계: 분석의 관점 제공

차원 테이블은 분석 시 **"어떤 관점에서 데이터를 볼 것인가"**를 결정합니다. 차원 테이블이 풍부할수록 분석의 깊이와 다양성이 높아집니다.

**시간 차원(Time Dimension)**은 거의 모든 분석에서 필수적인 차원입니다:

[시간 차원 테이블 예시]

┌─────────┬────────┬────────┬────────┬────────┬────────┬──────────┐
│ 날짜_키  │ 연도    │ 분기    │ 월     │ 주     │ 일      │ 요일      │
├─────────┼────────┼────────┼────────┼────────┼────────┼──────────┤
│ 20240101│ 2024   │ 2024Q1 │ 2024-01│ 2024W01│ 01     │ 월요일    │
│ 20240102│ 2024   │ 2024Q1 │ 2024-01│ 2024W01│ 02     │ 화요일    │
│ ...     │ ...    │ ...    │ ...    │ ...    │ ...    │ ...      │
│ 20240331│ 2024   │ 2024Q1 │ 2024-03│ 2024W13│ 31     │ 일요일    │
└─────────┴────────┴────────┴────────┴────────┴────────┴──────────┘

**제품 차원(Product Dimension)**은 "제품명, 카테고리, 브랜드, 제조사, 색상, 크기, 포장 단위" 등 분석 가능한 다양한 속성을 포함합니다. 계층적 속성("카테고리 > 브랜드 > 제품명")은 **비정규화(De-normalization)**되어 단일 행에 저장됩니다.

**지점 차원(Store Dimension)**은 "지점명, 지역(시/도), 지역(구/군), 지점 유형, 면적, 개업일" 등의 속성을 가집니다. 지리적 계층("서울특별시 > 강남구 > 테헤란로 지점")이 비정규화되어 저장됩니다.


Ⅳ. 스타 스키마의 장점과 단점

장점:

1. 단순한 조인 구조 차원 테이블이 팩트 테이블에만 연결되므로, 어떤 분석이든 최대 N번의 조인(N = 차원 수)으로 결과를 얻을 수 있습니다. 복잡한 다중 조인이 필요하지 않습니다.

2. 직관적인 비즈니스 모델 중앙의 팩트 테이블이 "판매, 주문, 재고" 같은 비즈니스 프로세스를 나타내고, 주변의 차원 테이블이 "언제, 어디서, 무엇을, 누가" 같은 비즈니스 관점을 제공합니다. 비기술적인 경영진도 구조를 이해하기 쉽습니다.

3. 빠른 질의 성능 비정규화된 차원 테이블 덕분에 조인 시 참조하는 테이블 수가 적고, 차원 테이블이 소규모이므로 전체 테이블 스캔(Full Table Scan) 비용도 낮습니다.

4. 쉬운 유지보수 새로운 차원을 추가하려면 해당 차원 테이블과 팩트 테이블에 외래 키 추가만 하면 됩니다. 기존 구조에 미치는 영향이 최소화됩니다.

단점:

1. 차원 테이블의 데이터 중복 차원 테이블이 비정규화되어 저장되므로, "_서울_지점_이 수천 개_의 판매 행에 대해 반복"되는 것처럼 데이터 중복이 발생할 수 있습니다. 저장 공간이 증가합니다.

2. 차원 정보 변경 시 관리 복잡성 고객 주소 변경,产品价格调整 등 차원 테이블의 정보가 변경되면 모든 관련 팩트 행에 영향이 미칠 수 있습니다(특히 비정규화가 심한 경우). 이는 Slowly Changing Dimension(SCD) 처리 전략으로 대응합니다.


Ⅴ. 스타 스키마의 실제 적용과 📢 비유

OLAP 도구와의 연계: 스타 스키마는 Microsoft Analysis Services, SAP BW, Oracle OLAP, IBM Cognos 등 주요 OLAP 도구에서原生 支持됩니다.ROLAP(Relational OLAP) 환경에서는 스타 스키마 구조를 그대로 SQL 질의로 변환하여 처리합니다.

성능 최적화 기법:

  • _BITMAP 인덱스: 차원 키에 대해 비트맵 인덱스를 생성하면 다중 차원 필터링이 극도로 빨라집니다.
  • _实物化视图(Materialized View): 자주 사용되는 "월별 매출 합계, 지역별 매출 합계" 등을 미리 계산하여 저장합니다.
  • _축소 테이블(Summary Table):Aggregrate 데이터를 별도의 테이블로 유지합니다.

📢 섹션 요약 비유: 스타 스키마는 **"우주 공간에서 태양계 모델에 비유"**할 수 있습니다. 태양(팩트 테이블)이 중심에 있고, 각 행성(차원 테이블)이 태양을 중심으로 공전하는 구조입니다. 행성이 서로 직접 통신하지 않고 모두 태양을 통해서만 상호작용합니다. 이는 우주에서 가장 안정적인 구조 중 하나인 것처럼, 데이터 분석에서도 가장 직관적이고 효율적인 구조로 평가받고 있습니다. 모든 것이 태양을 통해 연결되므로 "금성에 사는 생명체가 지구에서 무슨 일이 일어나는지 알고 싶다면?,只需 태양을 통해 확인하면 됩니다."