차원 모델링이란 / Dimensional modeling

차원 모델링(Dimensional Modeling)은 매우 일반적인 데이터 모델링 기법으로, 데이터 웨어하우스에서 특히 널리 사용됩니다. 차원 모델링은 사업에 대한 이해를 도모하고, 데이터를 조직하고, 빠르게 정보를 검색하는 데 중점을 두고 설계됩니다. Dimension, Facts 테이블로 나눠서 모델링해서 조금 더 효율적이고 편하게 데이터를 분석이 가능해집니다.

1.차원(Dimensions)

: 데이터의 특정 관점을 나타내며, 데이터를 분류하고 표시하는 데 사용됩니다. 예를 들어, 시간(날짜, 분기, 연도 등), 위치(도시, 국가 등), 제품(제품 ID, 제품 이름, 카테고리 등)과 같은 정보가 차원에 포함될 수 있습니다.

2.측정값(Facts):

관측된 사업적 성과를 나타내며, 일반적으로 수치적인 값을 갖습니다. 측정값은 분석을 수행하거나 의사 결정을 지원하는 데 사용됩니다. 매출, 비용, 이익 등의 값이 이에 해당합니다.

 

3. dimension, facts 테이블로 분리함으로써 얻는 장점.

• 성능 향상: 정규화된 데이터 구조는 데이터베이스의 성능을 크게 향상시킵니다. Fact 테이블에는 키 값만 있으며, 대부분의 비즈니스 로직은 Dimension 테이블에서 처리되기 때문입니다. 따라서 쿼리 성능이 향상됩니다.
• 유지보수성: Dimension과 Fact 테이블로 분리하면, 각 테이블을 별도로 유지 관리하고 업데이트할 수 있으므로, 변경이 필요한 경우 전체 시스템을 수정하지 않고도 해당 부분만 수정할 수 있습니다.
• 데이터 품질: Dimension 테이블은 기존의 데이터 품질을 향상시키며, 비즈니스 규칙과 프로세스를 더 잘 이해할 수 있도록 합니다. Fact 테이블은 일반적으로 트랜잭션 데이터를 저장하므로, 이 두 가지 테이블을 분리함으로써 데이터 품질을 관리하고 향상시킬 수 있습니다.
• 데이터 가독성: 데이터를 논리적으로 구분하면, 데이터를 이해하고 해석하는 데 도움이 됩니다. 각 Dimension 테이블은 특정 주제(예: 고객, 제품, 시간 등)에 대한 데이터를 보유하고, Fact 테이블은 이러한 Dimension들 사이의 관계를 정의하는 측정 가능한 값(예: 판매량, 매출 등)을 보유합니다. -> 비즈니스 로직 제거 (백엔드 로직을 몰라도 정확한 데이터를 추출 가능)
• 데이터 중복 최소화: 특히 별도의 Dimension 테이블을 사용하면 데이터 중복을 크게 줄일 수 있습니다. 예를 들어, "제품" Dimension 테이블에서는 각 제품에 대한 정보를 한 번만 저장하면 되므로, 여러 Fact 테이블에서 같은 정보를 반복해서 저장할 필요가 없습니다.

→ User 입장: 분석하기 편하다!! 즉, 비즈니스 레벨에서 질의 할 수 있는 형태로 데이터를 가공합니다. 

 

<예시>

# 예시를 위한 상황입니다.
# 월 별 A 프러덕트의 판매량을 알고 싶음.


# 모델링 하지 않은 기존 데이터, 비즈니스 로직을 알아야만 추출 가능.
select
	date_format(ordered_at, '%Y-%m'),
    sum(order_product.quantity)
from order
inner join order_product on order.id = order_product.order_id
inner join product on product.id = order_product.product_id
where product.name = 'A' AND order.status='DONE' AND order.deleted_at IS NULL .....


# 모델링한 경우
select
	date_format(ordered_at, '%Y-%m'),
    count(order_product)
from order_fact
inner join product_dim on order_fact.product_id = product_dim.id
inner JOIN dim_time t ON f.date_id = t.date_id
WHERE 
  p.product_name = 'A'
GROUP BY 
  t.year, t.month;


-------기존 테이블 -------
user table
- id
- name
- gender
- age
- joined_at

product table
- id 
- name
- category
- price

order_product table
- order_id
- product_id
- quantity

order 
- id
- user_id
- total_price
- ordered_at

-------모델링 테이블 -------
fact_orders (order_id는 중복이 가능한 형태)
- order_id
- product_id
- user_id
- date_id
- quantity
- total_price

차원 테이블 생략...

 

차원 모델링의 기본 요소는 차원(dimension)과 측정값(fact)입니다.

1. 차원(Dimensions): 데이터의 특정 관점을 나타내며, 데이터를 분류하고 표시하는 데 사용됩니다. 예를 들어, 시간(날짜, 분기, 연도 등), 위치(도시, 국가 등), 제품(제품 ID, 제품 이름, 카테고리 등)과 같은 정보가 차원에 포함될 수 있습니다.

2. 측정값(Facts): 관측된 사업적 성과를 나타내며, 일반적으로 수치적인 값을 갖습니다. 측정값은 분석을 수행하거나 의사 결정을 지원하는 데 사용됩니다. 매출, 비용, 이익 등의 값이 이에 해당합니다.

차원 모델링에는 일반적으로 두 가지 기본 형태인 스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)가 있습니다.

1. 스타 스키마(Star Schema)

스타 스키마는 중심에 팩 테이블이 있고, 그 주위에 차원 테이블들이 배치된 구조를 가집니다. 이는 '별'과 같은 모양을 띠기 때문에 스타 스키마라 불립니다.

예를 들어, 우리의 판매 데이터 모델을 스타 스키마로 만들면 다음과 같습니다:

팩 테이블(Fact_Sales):
- date_id
- product_id
- user_id
- order_id
- quantity

차원 테이블(Dimension tables):
1. Dim_Date:
   - date_id
   - day
   - month
   - year
   - ordered_at
2. Dim_Product:
   - product_id
   - name
   - category
   - price
3. Dim_User:
   - user_id
   - name
   - gender
   - age

2. 스노우플레이크 스키마(Snowflake Schema)

스노우플레이크 스키마는 스타 스키마를 확장한 형태로, 차원 테이블들이 정규화되어 추가적인 차원 테이블을 갖는 구조입니다. 이는 '눈송이'와 같은 모양을 띠기 때문에 스노우플레이크 스키마라 불립니다.

위의 예시를 스노우플레이크 스키마로 변형하면 다음과 같습니다:

팩 테이블(Fact_Sales):
- date_id
- product_id
- user_id
- order_id
- quantity

차원 테이블(Dimension tables):
1. Dim_Date:
   - date_id
   - day
   - month
   - year
   - ordered_at
2. Dim_Product:
   - product_id
   - name
   - category_id
   - price
3. Dim_User:
   - user_id
   - name
   - gender
   - age
4. Dim_Category:
   - category_id
   - category_name

여기서 'Dim_Product' 테이블은 'Dim_Category' 테이블을 참조하게 되어 스노우플레이크 스키마를 형성합니다. 이 구조는 데이터의 중복을 줄여주고, 공간 효율성을 높입니다. 그러나, 조인 연산이 더 많아져서 쿼리 성능이 떨어질 수 있습니다.

스노우플레이크 스키마는 스타 스키마를 확장한 형태로, 차원 테이블이 더욱 정규화되어 복잡한 계층 구조를 형성합니다. 이는 데이터의 중복을 줄이지만, 질의의 복잡성이 증가할 수 있습니다.