Star schema와 Snowflake schema 비교

star and snowflake schema는 데이터 웨어하우스에서 사용되는 가장 있기 있는 다차원 데이터 모델이다.

스타 스키마와 스노우 플레이크 스키마의 결정적인 차이점은 

스타 스키마는 정규화를 사용하지 않는 반면, 스노우 플레이크 스키마는 데이터의 중복을 제거하기 위해 정규화를 사용한다는 것이다. 

팩트 및 차원 테이블은 스키마를 만드는데 필수 요구사항이다.

 

관계형 데이터베이스의 설계는 엔티티-관계 데이터 모델을 사용한다. 이러한 모델에서 데이터베이스 스키마는 엔티티 집합과 엔티티 간의 관계로 구성된다. 이러한 종류의 데이터 모델은 온라인 거래 처리 등에 적합하다. 

데이터 웨어하우스는 온라인 데이터 분석을 지원하는 간략한 주제 지향 스키마가 필요하다. 스키마는 전체 데이터베이스를 논리적으로 설명하는 데 사용되므로 데이터 하우스는 유지관리를 위해 스키마가 필요하다.

 

 

Star schema

 

https://www.geeksforgeeks.org/difference-between-star-schema-and-snowflake-schema/

 

 

스타 스키마는 데이터 웨어하우스가 각 차원에 대해 단일 테이블과 함께 팩트 테이블로 구성되는 단순하고 일반적인 모델링이다.

스키마는 중심인 팩트 테이블을 둘러싸고 확장되는 패턴으로 표시된 차원 테이블을 사용하여 별 모양처럼 보인다.

팩트 테이블의 dimension은 기본 키와 외래 키를 통해 차원 테이블에 연결된다.

 

예) 전자 제품 제조 회사의 매출을 포함하는 스키마

판매(Sales)는 시간(Time), 품목(Item), 지점(Branch), 위치(Locaion) 차원에 따라 이루어진다.

스키마에는 네 가지 차원 각각에 대한 키와 함께 판매된 달러(Dollars_sold) 및 판매 단위(Units_sold)라는 두 가지 측정값이 포함된 판매에 대한 중앙 팩트 테이블이 있다.

팩트 테이블의 용량은 시스템을 통해 time_key, item_key와 같은 차원 식별자를 생성함으로써 감소된다.

https://techdifferences.com/difference-between-star-and-snowflake-schema.html

단일 테이블만 각 차원을 모방하고 각 테이블에는 스타 스키마에 표시된 대로 속성 그룹(group of attributes)이 포함된다.

Location Dimension Table은 {location_key, street, city, state, country} 라는 attribute set을 포함한다.

위 스키마에서는 일부 중복이 발생할 수 있다. 예를 들어, 두 개의 city가 동일한 state, country일 수 있으므로 차원 테이블에 이러한 도시에 대한 항목이 있으면 state 및 country 속성 간에 중복이 생긴다.

 

Snowflake schema

https://www.geeksforgeeks.org/difference-between-star-schema-and-snowflake-schema/

 

 

눈송이 스키마는 차원 테이블의 계층적 형태를 포함하는 일종의 스타 스키마이다.

이 스키마에는 기본 및 외래키를 통해 팩트 테이블에 연결된 다양한 차원 및 하위 차원 테이블로 구성된 팩트 테이블이 있다.

구조는 눈송이와 유사하게 생겼다.

 

테이블을 추가 테이블로 분할하는 정규화를 사용한다. 테이블을 분할함으로써 중복성을 줄이고 메모리 낭비를 방지할 수 있다.

스노우플레이크 스키마는 관리하기는 더 쉽지만 설계와 이해가 복잡하다. 또한 쿼리를 실행하는 데 더 많은 조인이 필요하므로 검색 효율이 떨어질 수 있다.

 

예) 위와 동일한 예제 사용

 

sales fact table은 스타 스키마의 테이블과 동일하지만 차원 테이블의 정의는 다르게 진행된다.

스타 스키마 항목에 대한 단일 차원 테이블은 눈송이 스키마에서 정규화되어 결과적으로 새로운 item 및 supplier 테이블이 생성된다. 

예를 들어 item_key, brand, item_name, type, supplier_key attributes로 구성된 item dimension table이 있다.

여기서 supplier_key는 supplier 차원 테이블에 연결된다.

 

https://techdifferences.com/difference-between-star-and-snowflake-schema.html

마찬가지로 location dimension 테이블에서는 city_key 속성으로 city dimension table에 연결된다.

여기서 상태 속성은 정규화될 수 있다.

 

 

 

Star schema vs. Snowflake schema

https://techdifferences.com/difference-between-star-and-snowflake-schema.html

1. Star 스키마 차원 테이블은 정규화되지 않고 Snowflake 스키마 차원 테이블은 정규화된다.
   : 눈송이 스키마는 정규화를 통해 데이터 중복성을 제거한다. 이에 반해 스타 스키마에서는 정규화가 수행되지 않아 데이터가 중복된다.
2. Snowflake스키마는 차원 테이블을 저장하는 데 공간을 덜 사용하지만, 더 복잡하다.
   : 스타 스키마는 눈송이 스키마에 비해 더 많은 공간(space)를 사용한다.
   스타 스키마는 간단하고 이해하기 쉬우며 덜 복잡한 쿼리를 포함한다. 반대로 눈송이 스키마는 이해가 어렵고 복잡한 쿼리를 포함한다.
3. 스타 스키마는 Join을 적게 사용하고, 눈송이 스키마는 Join을 많이 사용한다.
   : Star 스키마는 팩트 테이블과 차원 테이블만 조인하여 SQL 쿼리를 더 간단하고 빠르게 만든다.
4. Snowflake 스키마에는 중복 데이터가 없으므로 유지 관리가 더 용이하다.
5. Snowflake 스키마는 데이터 웨어하우스에 적합하고 Star 스키마는 단순한 관계가 있는 데이터마트에 적합하다.
6. 스타 스키마에서 쿼리를 실행하는데 소요되는 시간이 더 적다. 반대로 눈송이 스키마는 조인의 과도한 사용으로 인해 더 많은 시간을 소비한다.
7. 스타 스키마에는 하나의 dimension 항목에 대해 하나의 dimension 테이블만 포함하는 반면 눈송이 스키마는 하나의 dimension 항목에 대한 dimension 및 sub-dimension 테이블까지 있을 수 있다.

 

두 스키마 모두 읽기 쿼리 및 복잡한 데이터 분석의 속도를 개선한다. 다양한 소스에서 정보를 가져오는 대규모 데이터 세트를 처리하는 경우 더욱 좋다.

 

Conclusion

Star 및 Snowflake 스키마는 데이터 웨어하우스 설계에 사용된다.

눈송이 스키마는 유지하기 쉽고 중복성을 줄여 공간을 덜 차지하지만 설계가 복잡하다는 단점이 있다.

스타 스키마는 이해 및 설계가 간단하고 조인을 덜 사용하며 간단한 쿼리가 가능하지만 데이터 중복성 및 무결성과 같은 몇 가지 문제가 있다.

눈송이 스키마를 사용하면 중복성이 최소화되지만 데이터 웨어하우스 설계에서 가장 많이 사용되는 것은 스타 스키마이다.

 

 

 

References

https://techdifferences.com/difference-between-star-and-snowflake-schema.html

https://www.integrate.io/ko/blog/star-schema-vs-snowflake-schema-ko/

https://www.geeksforgeeks.org/difference-between-star-schema-and-snowflake-schema/