시작하며

데이터 웨어하우징은 대규모 데이터의 효율적 저장과 빠른 분석을 위해 필수적인 기술입니다.
데이터 웨어하우스에서 데이터를 구조화하는 방법에는 여러 가지가 있지만, 가장 널리 알려진 두 가지는 Star Schema와 Snowflake Schema입니다.
이 포스트에서는 두 스키마의 정의와 특징을 살펴보고, 각 스키마에서 데이터 정규화가 어떻게 이루어지는지 설명합니다.

StarSchema와 SnowFlake Schema?

데이터베이스의 모델링과 정규화와 동시에 DW를 구축하면서 제일 많이 접하는 용어인 StarSchema, SnowFlake Schema에 대해서 정리해봤습니다.

• 두 스키마 구조의 명확한 차이 : Star Schema (별), SnowFlake Schema(눈송이) 두 스키마의 가장 큰 차이는 데이터 정규화에 있습니다.

Star Schema는 정규화를 사용하지 않는 반면, SnowFlake Schema는 정규화를 필수적으로 사용합니다.
특히 SnowFlake Schema는 정규화 (1, 2, 3) 과정을 기반으로 저장된 데이터의 중복을 없애는 것을 목표로 수행됩니다.

데이터 정규화 (Normalization)란? [정규화의 상세 단계]

데이터 정규화는 데이터베이스 설계에서 데이터를 효율적으로 저장하고 중복을 최소화하기 위해 사용되는 과정입니다.
정규화는 테이블을 분할하고 테이블 간의 관계를 정의하여 각 테이블들의 데이터의 일관성과 무결성을 유지합니다.
이를 통해 테이블의 저장 공간을 절약하고 데이터 변경 시 발생할 수 있는 문제를 해소할 수 있습니다.

• 결론 : 정규화는 데이터의 일관성, 무결성을 보장해서, 결국 데이터 조회나 Discover의 난이도를 낮추게 하기 위함입니다.

정규화에 대한 내용들은 워낙 많은 분들이 다루기 때문에 따로 정리하기 보다는 쉽게 설명해주시는 분의 유튜브 링크를 첨부합니다. - 코딩애플

정규화의 상세 단계

정규화는 일반적으로 1NF, 2NF, 3NF, BCNF, 4NF, 5NF 등의 단계로 나뉘는데, 단계가 올라갈수록 더 높은 수준의 데이터 무결성을 보장합니다.

• 1NF (제1정규형): 각 테이블이 원자값(atomic value)만을 포함하도록. 즉, 각 테이블 컬럼에는 하나의 데이터만 기입해야 합니다.

• 2NF (제2정규형): 1NF를 만족하고, 기본 키의 모든 부분집합의 종속이 없는. 즉, 테이블과 관련이 없는 데이터를 따로 저장한다.
  (Dimenssion) - Partial Dependency를 제거한 테이블

• 3NF (제3정규형): 2NF를 만족하고, 비이행적 종속을 가지는 것입니다. 즉. 일반 컬럼에 종속된 데이터를 따로 저장해야 합니다.

예를 들면 아래와 같은 형식의 데이터가 실제 테이블에 저장된다고 생각해보겠습니다.

언뜻 보면 괜찮게 저장된 데이터처럼 보이지만 나라, 성별, 구매 상품 칼럼의 동일한 데이터가 여러 Row로 저장되어 있는 구조입니다.
현재 구조의 테이블을 사용해도 조회 성능 이슈는 느끼지 못할 것입니다, 저장 용량에 대한 문제도 없을 것이고요, 이유는 Row가 4건으로, 데이터 용량이 작기 때문입니다.
그러나, 실제 운영에서의 분석가들은 테이블로 분석 결과나 지표를 만들게 될 텐데, 당연히 4건의 Row가 아닌, 1~2년, 많으면 10년 치의 데이터를 보는 경우가 흔합니다.
결론적으론, 10년 치 데이터에서 Korea Country 값 지역의 남성에게 가장 많이 팔린 제품이 무엇일까? 라는 간단한 Where 조건의 조회에도.
엄청나게 늘어나있는 Row 데이터들을 모두 확인해야 하는 과정이 필요하기 때문에 성능적으로 엄청나게 많은 시간이 소요되며 비효율적이게 됩니다.

Star Schema

위의 사례와 같이, 각각의 비즈니스와 연관되어 있는 데이터들이 하나의 테이블에 저장되어 있는 구조를 피해가지 위해서 Star Schema를 사용합니다.
Star Schema는 DW(Data Warehouse)의 각 차원에서 Dimension Table과 Fact Table로 구성되는 일반적인 모델링입니다.

데이터를 무작정 Star Schema로 만들 거야!라고 한다면 각각의 값에 대한 정보를 기입한 Demension 테이블을 생성해야 합니다.

이해를 돕기 쉽게 위의 데이터를 Dimension Table로 나눠서 저장해 보도록 하겠습니다.

Dimension Table을 만들어 각각의 데이터들을 나누니 각각의 테이블이 어떤 데이터를 가지고 있는지도 명확하고, Key에 따라 어떤 값을 표현하는지도 쉽게 알 수 있습니다.
어찌 보면 당연하겠지만 Dimension은 결국 Fact와 연계되기에 Fact는 계속해서 데이터양이 늘어나지만 Dimension은 그 값이 기하급수적으로는 증가하지 않습니다.
앞으로는 Fact Table의 PK(Primart Key)와 Dimension Table의 FK(Foreign Key)는 서로 관계성이 있어야 되며 그것을 기반으로 서로의 테이블에 연결되는 구조입니다.
앞으로 분석가들은 전체 데이터에서의 특정 상품에 대한 데이터들의 범주를 검색하려 FACT & Dimension을 JOIN을 사용해 필요한 데이터를 만들어서 조회하게 됩니다.

이 구조는 ERD에서 중간의 Fact 테이블을 기준으로 파생되어 있는 Dimension 테이블을 옆에 그린 뒤 관례를 연결하여 표현합니다.

마치 그림으로 그리면 별같이 생겼다고 해서, Star Schema라고 명칭합니다

SnowFlake Schema

저렇게 테이블의 데이터 별로 다 나눠놓고 Join으로만 쓰면 위에 말했던 저장이나, 속도 문제들은 모두 해결되는 게 아닌가요??라는 질문의 답은 = 아닙니다
단순이 테이블을 나눠 놨다고 해서 중복이나 무결성이 유지되는 것은 아닙니다. 위의 그림에서 예를 들면 제품의 가격 같은 경우는 중복이 생길 수 있는 경우죠.
이 경우 Star Schema에서 한 단계 더 나아가 Dimension으로 나누어진 테이블의 정규화까지 진행한 구조를 SnowFlake Schem 라고 합니다.

Product라는 테이블이 Dimension Table에서 제 1차 정규화를 위반하게 생성되었다고 예를 들어보겠습니다.

위와 같이 Product 별 데이터로 Dimension Table을 나누어서 저장해도, 채널 컬럼 데이터 속성은 제 1정규화 정책을 위반하게 됩니다. 결국 데이터의 중복이 생겨버리고 말았죠.
그렇다면 저런 형태의 데이터도 정규화를 거쳐 유일한 데이터만 가지고 있는 테이블로 만들어주는 겁니다.

해당 Dimension Table을 1차 정규화를 통해서 분리하게 되면 다음과 같은 형태가 됩니다.

이처럼 Product의 Key를 사용해, Channel에 대한 테이블들을 또 한 번 나누게 되면, 채널 별로도 유일한 데이터값을 얻을 수 있게 되죠.
이런 식으로 Star Schema로 만족되지 못한 정규화까지 진행해 데이터를 저장하면 아래와 같은 모양이 되는데, 이 모양이 눈 결정을 닮아 SnowFlake Schema 라고 합니다.
아무래도 여러 계층이 테이블로 나뉘다 보니, 끝 단 차원에 나눠져있는 데이터를 가져오는데 많은 Join이 필요하게 됩니다.
또한 계층이 많아질수록 Data Discover를 파악하기 힘들고, 복잡해집니다. 그러나 데이터 중복성이 매우 낮다는 장점을 가지고 있습니다.

결론

Star Schema와 Snowflake Schema는 각각의 장단점을 가지고 있고, 설계한 아키텍처나 서비스의 사용 사례에 따라 적절한 구조의 모델링을 선택하는 것이 중요합니다.

Snowflake Schema와 Star Schema의 특징, 장단점