Coding Interview Prep · 강의

스타 스키마와 데이터 웨어하우스 설계

사실 테이블과 차원 테이블, 비정규화의 절충점, OLAP 모델링을 알아봅니다.

스타 스키마와 데이터 웨어하우스 설계은(는) CoddyKit의 무료 Coding Interview Prep 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Coding Interview Prep 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Coding Interview Prep 강의에는 총 4개의 강의가 포함되어 있습니다.

OLTP와 OLAP

데이터 웨어하우스 질문은 면접관이 반드시 정확히 구분하기를 기대하는 한 가지 차이에서 시작합니다. 바로 OLTP와 OLAP입니다.

OLTP(거래 처리용): 소규모 읽기/쓰기 작업이 많으며 무결성을 위해 고도로 정규화됩니다. 애플리케이션을 구동합니다.
OLAP(분석용): 과거 데이터에 대한 대규모 집계 조회는 적게 수행하며, 속도를 위해 의도적으로 비정규화됩니다. 보고서와 대시보드를 구동합니다.

스타 스키마는 OLAP 설계입니다. 중복을 감수하는 대신 빠른 분석 쿼리를 얻는 것이 이 설계의 핵심입니다.

팩트와 차원

스타 스키마는 데이터를 두 종류의 테이블로 나눕니다.

팩트 테이블: 측정 가능한 사건이나 거래(판매, 클릭)를 저장합니다. 수치 측정값과 차원을 가리키는 외래 키를 보관합니다.
차원 테이블: 데이터를 분류하거나 필터링할 때 사용하는 설명적 맥락(날짜, 상품, 고객, 매장)을 저장합니다.

팩트는 중앙에 있고 차원은 별의 꼭짓점처럼 그 주위를 둘러싸므로 이런 이름이 붙었습니다.

팩트 테이블의 구조

팩트 테이블은 대부분 외래 키와 수치 측정값으로 구성됩니다. 행이 많고 열이 적으며 계속해서 증가합니다.

측정값은 집계하는 가산 가능한 숫자입니다. 예를 들면 수량, 매출, 원가가 있습니다. 세분성(행 하나가 하나의 ?를 나타내는 기준)을 명확히 밝혀야 합니다. 여기서는 한 행이 한 판매에 포함된 하나의 상품 항목입니다.

CREATE TABLE fact_sales (
  sale_id      BIGINT PRIMARY KEY,
  date_key     INT  NOT NULL,   -- FK to dim_date
  product_key  INT  NOT NULL,   -- FK to dim_product
  customer_key INT  NOT NULL,   -- FK to dim_customer
  store_key    INT  NOT NULL,   -- FK to dim_store
  quantity     INT,             -- measure
  revenue      DECIMAL(12,2),   -- measure
  cost         DECIMAL(12,2)    -- measure
);

차원 테이블의 구조

차원 테이블은 행이 적고 열이 많습니다. 필터링하거나 그룹화할 때 사용하는 설명 열이 많기 때문입니다. 쿼리에서 차원마다 조인을 한 번만 하면 되도록 의도적으로 비정규화합니다.

dim_product가 카테고리와 브랜드를 별도의 테이블이 아니라 같은 행에 보관하는 것을 확인하십시오. 이러한 중복이 바로 핵심입니다. 쿼리 실행 시 추가 조인을 피할 수 있습니다.

CREATE TABLE dim_product (
  product_key  INT PRIMARY KEY,   -- surrogate key
  product_id   INT,              -- natural/business key
  product_name VARCHAR(100),
  category     VARCHAR(50),      -- denormalized
  brand        VARCHAR(50),      -- denormalized
  unit_price   DECIMAL(10,2)
);

스타 스키마 쿼리

이것이 바로 이 설계로 얻는 이점입니다. 일반적인 분석 쿼리는 팩트를 몇 개의 차원과 조인하고, 필터링한 다음 집계합니다. 차원마다 조인을 한 번만 하며 깊은 연결 고리가 없습니다.

면접관은 스타 스키마를 대상으로 바로 이런 종류의 쿼리를 작성하라고 요구합니다.

SELECT d.category,
       t.year,
       SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date    t ON t.date_key    = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;

대체 키

차원은 대체 키를 사용합니다. 대체 키는 데이터 웨어하우스에서 생성하는 의미 없는 정수 기본 키(예: product_key)이며, 원천 시스템의 자연 키와는 분리됩니다.

면접관이 이 점을 중요하게 보는 이유는 다음과 같습니다.

변경되는 비즈니스 키로부터 데이터 웨어하우스를 분리합니다.
팩트 테이블을 좁게 유지합니다(정수 조인은 빠릅니다).
느리게 변하는 차원으로 이력을 추적하려면 필요합니다(다음 장면에서 다룹니다).

느리게 변하는 차원

데이터 웨어하우스 면접에서 자주 나오는 주제입니다. 차원 속성이 변경될 때(예를 들어 고객이 다른 도시로 이사할 때) 어떻게 처리하시겠습니까? 이를 느리게 변하는 차원(SCD)이라고 합니다.

유형 1: 이전 값을 덮어씁니다. 이력이 없습니다.
유형 2: 유효 날짜와 현재 여부를 포함한 새 행을 추가합니다. 전체 이력을 보관하며, 이를 위해 대체 키가 필요합니다.
유형 3: "이전 값" 열을 유지합니다. 이력이 제한적입니다.

시간에 따른 변경을 추적하는 질문에서는 유형 2가 가장 자주 기대되는 답변입니다.

-- SCD Type 2 dimension
CREATE TABLE dim_customer (
  customer_key INT PRIMARY KEY,   -- surrogate
  customer_id  INT,              -- natural key
  city         VARCHAR(50),
  valid_from   DATE,
  valid_to     DATE,
  is_current   BOOLEAN
);

스타와 스노플레이크

이 비교 질문에 대비하십시오. 스노플레이크 스키마는 차원을 하위 테이블로 정규화합니다(상품 -> 카테고리 -> 부서). 반면 스타 스키마는 차원을 평평하게 유지합니다.

스타: 조인이 적고 읽기가 빠르며 중복이 일부 있습니다. 쿼리 성능에 유리합니다.
스노플레이크: 저장 공간이 적게 필요하고 차원 유지 관리가 쉽지만, 쿼리마다 조인이 더 많이 필요합니다.

다음과 같이 답하십시오. "기본값으로 쿼리 속도에는 스타를 사용하고, 차원이 크며 재사용될 때만 스노플레이크를 사용하십시오."

날짜 차원

거의 모든 스타 스키마에는 원시 날짜 열 대신 전용 날짜 차원이 있습니다. 날짜 차원은 연도, 분기, 월, 요일, 공휴일 여부, 회계 기간을 미리 계산해 둡니다.

따라서 분석가는 날짜 함수를 여러 곳에 흩어 쓰지 않고 간단한 조인만으로 "회계 분기"나 "주말 여부"를 기준으로 그룹화할 수 있습니다. 질문받지 않아도 날짜 차원을 언급하는 것은 데이터 웨어하우스를 구축해 본 사람이라는 강한 신호입니다.

CREATE TABLE dim_date (
  date_key   INT PRIMARY KEY,   -- e.g. 20250131
  full_date  DATE,
  year       INT,
  quarter    INT,
  month      INT,
  day_of_week VARCHAR(10),
  is_weekend BOOLEAN,
  fiscal_qtr VARCHAR(6)
);

세분성 선택

팩트 테이블에서 가장 중요한 단 하나의 결정은 세분성입니다. 즉, 행 하나가 무엇을 나타내는지 정하는 것입니다. 다른 모든 것보다 먼저 선언하십시오.

너무 거칠면(매장별 하루에 한 행) 세부 정보가 사라집니다.
너무 세밀하면(스캔한 항목마다 한 행) 테이블이 지나치게 커집니다.

"주문 항목별 상품마다 한 행"과 같은 명확한 세분성 선언이 어떤 차원과 측정값을 포함할지 결정합니다. 면접관은 이러한 원칙을 지키는지를 주의 깊게 봅니다.

비정규화할 시점

정규화와 연결해서 생각하십시오. OLTP 시스템은 무결성을 위해 3NF로 정규화하지만, 데이터 웨어하우스는 읽기 속도를 위해 차원을 의도적으로 비정규화합니다.

반드시 설명할 수 있어야 하는 절충점은 다음과 같습니다.

데이터 웨어하우스는 임의의 애플리케이션 쓰기가 아니라 통제된 ETL로 적재되므로, 중복된 차원 데이터를 허용할 수 있습니다.
조인이 적으면 수십억 개의 팩트 행을 더 빠르게 집계할 수 있습니다.

여기서 선임 수준의 답변을 가르는 것은 규칙이 아니라 판단입니다.

빠른 확인

판매 데이터 웨어하우스를 설계하고 있으며, 고객이 이사할 때 도시의 전체 이력을 보관해야 합니다.

복습: 스타 스키마와 웨어하우스 설계

이제 데이터 웨어하우스 모델링 질문에도 대응할 수 있습니다.

OLTP는 무결성을 위해 정규화하고, OLAP는 읽기 속도를 위해 비정규화합니다.
스타 스키마에는 중앙의 팩트 테이블(외래 키와 수치 측정값)이 있고, 그 주위를 평평한 차원이 둘러쌉니다.
대체 키와 전용 날짜 차원을 사용합니다.
SCD 유형 2로 변경 사항을 추적하고, 먼저 팩트의 세분성을 선언합니다.
쿼리 성능을 위해 스노플레이크보다 스타를 우선합니다.

자주 묻는 질문

“스타 스키마와 데이터 웨어하우스 설계” 강의는 무료인가요?

네 — “스타 스키마와 데이터 웨어하우스 설계” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Coding Interview Prep 강의 전체를 잠금 해제할 수 있습니다. Coding Interview Prep 강의에는 총 4개의 강의가 포함되어 있습니다.

“스타 스키마와 데이터 웨어하우스 설계”에서 뭘 배우나요?

사실 테이블과 차원 테이블, 비정규화의 절충점, OLAP 모델링을 알아봅니다. 브라우저에서 직접 실행하는 실습 코드로 Coding Interview Prep을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Coding Interview Prep을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Coding Interview Prep은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“스타 스키마와 데이터 웨어하우스 설계” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Coding Interview Prep 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Coding Interview Prep 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Coding Interview Prep(으)로 돌아가기