Star 스키마와 Snowflake 스키마 비교:
5가지 차이점

데이터 웨어하우징 영역에서 Star 스키마와 Snowflake 스키마는 방대한 양의 데이터를 효율적으로 구성하는 데 중요한 역할을 합니다. 이 두 스키마는 모두 고유한 이점을 가지고 있으며 데이터 처리 환경의 고유한 요구 사항을 충족합니다. 자세한 내용을 살펴보기 전에 먼저 스냅샷 비교를 통해 상황을 정리해 보겠습니다. Star 스키마는 좀 더 직관적인 반면, Snowflake 스키마는 Star 스키마의 좀 더 정규화된 버전입니다.

Snowflake 스키마와 Star 스키마를 비교할 때 기본 정의를 기억하는 것이 중요합니다. Star 스키마는 데이터 웨어하우스에서 정보를 구성하는 효율적인 방법을 제공하는 반면, Snowflake 스키마는 보다 효율적인 데이터 처리를 허용하는 스타 스키마의 변형입니다.

Star 스키마와 Snowflake 스키마의 주요 차이점은 다음과 같습니다.

• Star 스키마 차원 테이블은 정규화되지 않고 Snowflake 스키마 차원 테이블은 정규화됩니다. 
• Snowflake 스키마는 차원 테이블을 저장하는 데 공간을 덜 사용하지만, 더 복잡합니다.
• Star 스키마는 팩트 테이블과 차원 테이블만 조인하여 SQL 쿼리를 더 간단하고 빠르게 만듭니다.
• Snowflake 스키마에는 중복 데이터가 없으므로 유지 관리가 더 용이합니다.
• Snowflake 스키마는 데이터 웨어하우스에 적합하고 Star 스키마는 단순한 관계가 있는 데이터마트에 적합합니다.

기본적으로 Star 스키마는 데이터 웨어하우스에서 데이터와 정보를 보다 효율적으로 구성할 수 있는 방법을 사용자에게 제공합니다. 이에 비해 Star 스키마의 변형인 Snowflake 스키마는 사용자가 데이터를 처리할 때 더 효율적인 방법을 제공합니다. 이 두 가지 프로세스는 매우 유사하지만 사용자가 알아야 할 주요 차이점도 있습니다. 이 글에서는 먼저 Star 스키마에 대해 자세히 살펴본 다음 Snowflake 스키마로 전환하여 각각의 뉘앙스와 장점을 살펴보겠습니다.

Star 스키마와 Snowflake 스키마 비교에 대해 자세히 알아보고, 두 가지 유형의 데이터 웨어하우스 스키마가 기업 데이터의 이동, 저장, 처리 및 복잡한 분석 작업에서 조직의 효율성을 개선하는 데 어떻게 도움이 되는지 계속 읽어보세요.

목차

• Star 스키마와 Snowflake 스키마 개요
• Star 스키마란?
  • 팩트 테이블의 유형
  • 차원 테이블의 유형
  • 팩트 테이블과 차원 테이블이 함께 작동하는 방식 -
  • Star 스키마 다이어그램
  • Star 스키마에서 데이터의 비정규화
  • Star 스키마의 이점
  • Star 스키마의 당면 과제
• Snowflake 스키마란?
  • Snowflake 스키마 다이어그램
  • Snowflake 스키마의 이점
  • Snowflake 스키마의 당면 과제
• Integrate.io의 지원 방법

Star 스키마란?

Star 스키마는 데이터를 데이터 웨어하우스로 구성하기 위한 가장 간단한 구조를 제공합니다. Star 스키마의 중심은 일련의 "차원 테이블"을 인덱싱하는 하나 이상의 "팩트 테이블"로 구성됩니다. Star 스키마와 Snowflake 스키마를 이해하려면 팩트 테이블과 차원 테이블을 깊이 있게 살펴봐야 합니다.

Star 스키마의 목적은 비즈니스와 관련된 수치 "팩트" 데이터를 선별하여 설명 또는 "차원" 데이터와 분리하는 것입니다. 팩트 데이터에는 가격, 중량, 속도, 수량과 같은 정보, 즉 수치 형식의 데이터가 포함됩니다. 차원 데이터에는 수치 정보와 함께 색상, 모델 이름, 지리적 위치, 직원 이름, 영업 사원 이름 등 수많은 사항이 포함됩니다.

팩트 데이터는 팩트 테이블로 구성되고 차원 데이터는 차원 테이블로 구성됩니다. 팩트 테이블은 데이터 웨어하우스의 Star 스키마 중심에 있는 통합 지점입니다. 이를 통해 머신 러닝 툴에서 데이터를 단일 단위로 분석할 수 있으며 다른 비즈니스 시스템에서 데이터에 액세스할 수 있습니다. 차원 테이블은 데이터 웨어하우스를 구성하는 팩트 테이블을 통해 수렴되는 데이터(수치 및 비수치)를 보유하고 관리합니다.

보다 기술적인 관점에서 볼 때 팩트 테이블은 다양한 이벤트와 관련된 수치 정보를 추적합니다. 예를 들어 팩트 테이블에는 차원 테이블의 추가(설명 및 비수치) 정보에 매핑되는 외래 키와 함께 수치 값이 포함될 수 있습니다. 보다 기술적인 팩트 테이블은 낮은 수준의 세분성(또는 "세부사항")을 유지합니다. 즉, 원자 수준에서 정보를 기록합니다. 이로 인해 시간이 지남에 따라 팩트 테이블 내에 많은 기록이 축적될 수 있습니다.

팩트 테이블의 유형

팩트 테이블에는 세 가지 주요 유형이 있습니다.

• 트랜잭션 팩트 테이블: 개별 상품 판매와 같은 이벤트와 관련된 기록 정보입니다.
• 스냅샷 팩트 테이블: 연말정산 명세서와 같이 특정 시점에 적용되는 기록 정보입니다.
• 누적 스냅샷 테이블: 특정 상품 또는 상품 범주에 대한 올해 초부터 현재까지의 판매 수치와 같은 누계 데이터와 관련된 기록 정보입니다.

차원 테이블의 유형

차원 테이블은 일반적으로 팩트 테이블보다 적은 수의 기록을 저장합니다. 그러나 수치 데이터를 저장하는 것 외에도 차원 테이블의 기록에는 설명 속성도 포함됩니다. 정보 시스템에 따라 차원 테이블의 종류는 다양합니다. 몇 가지 예를 소개하겠습니다.

• 시간 차원 테이블: 정확한 시간, 날짜, 월, 연도별 이벤트를 식별하는 정보입니다.
• 지역 차원 테이블: 주소/위치 정보입니다.
• 직원 차원 테이블: 주소, 전화번호, 이름, 직원 번호, 이메일 주소 등 직원 및 영업 사원에 대한 정보입니다.
• 상품 차원 테이블: 제품, 제품 번호 등에 대한 설명 정보입니다.
• 고객 차원 테이블: 고객 이름, 전화번호, 연락처 정보, 주소 등입니다.
• 범위 차원 테이블: 시간, 가격 및 기타 수량에 대한 값 범위와 관련된 정보입니다.

팩트 테이블과 차원 테이블이 함께 작동하는 방식

차원 테이블에는 일반적으로 자연 키와 관련된 속성에 매핑되는 서로게이트 기본 키(즉, 단일 열 정수로 구성된 데이터 유형)가 나열됩니다. 다른 매장과 관련된 정보가 있는 차원 테이블인 "Dim_Store"가 있다고 가정해 보세요(아래 Star 스키마 그림 참조). 각 매장과 매장 이름, 크기, 위치, 직원 수, 범주 등과 같은 관련 비수치 및 기타 정보 행에 ID 번호를 할당할 수 있습니다. 다음과 같이 팩트 테이블("Fact_Sales")에 매장 ID 번호를 나열할 때마다, "Dim_Store" 차원 테이블에 있는 매장 데이터의 특정 행에 매핑됩니다.

물론 Star 스키마는 여기서 멈추지 않습니다. 팩트 테이블에 연결되는 정보가 있는 추가 포인트(또는 차원 테이블)가 있기 때문입니다. 예를 들어 다음과 같은 내용을 알고 싶다고 가정해 보겠습니다.

• 얼마나 많은 제품을 구매했나요?
• 어떤 제품을 구매했나요?
• 어떤 매장에서 제품을 구매했나요?
• 구매한 제품의 이름과 주소는 무엇이었나요?
• 구매한 제품을 제조한 브랜드 이름은 무엇이었나요?
• 고객이 각 제품을 구매한 요일은 언제였나요?

이와 같은 쿼리를 수행하려면 모든 차원 테이블(Dim_Date, Dim_Store 및 Dim_Product)에 포함된 데이터에 액세스해야 합니다. 이들은 별도의 데이터베이스이지만, 통합 지점 역할을 하는 팩트 테이블을 통해 모든 데이터를 단일 테이블에 있는 것처럼 쿼리할 수 있습니다. 즉, Star 스키마 데이터 웨어하우스가 작동하는 방식입니다.

현재 데이터 웨어하우스에서 중복성을 제거하고 접근성을 개선하기 위해 노력하고 있다면, BI 도구에 연결하고 사용하는 방법을 재평가할 때가 된 것일 수 있습니다. 다행히도 데이터 관리가 지나치게 복잡할 필요는 없습니다. Integrate.io를 사용하면 모든 데이터 소스를 원활하게 연결하여 신뢰할 수 있는 단일 데이터 소스를 만들 수 있습니다. 지금 바로 14일 무료 평가판을 시작하여 직접 확인해 보세요!

Star 스키마 다이어그램

다음 다이어그램은 간단한 Star 스키마의 모양을 보여 줍니다.

*이미지 제공: SqlPac at English Wikipedia, CC BY-SA 3.0.

여기서 Fact_Sales라는 팩트 테이블이 다이어그램의 중앙에 있습니다. 해당 스키마에는 ID 번호에 대한 다음 열이 포함됩니다. Date_Id, Store_Id, Product_Id, Units_Sold. 통합 지점으로서 팩트 테이블은 차원 테이블의 다양한 정보를 통합합니다: Dim_Product, Dim_Store, Dim_Date.

보시다시피 Star 스키마는 중앙 팩트 테이블 "core"와 차원 테이블 "points"에서 이름을 가져옵니다. Star 스키마에 차원 테이블이 많은 경우 데이터 엔지니어는 이를 지네 스키마라고 합니다.

Star 스키마에서 데이터의 비정규화

Star 스키마의 목표는 소스 스키마가 다른 다양한 데이터베이스에 포함된 방대한 양의 데이터에 대한 읽기 쿼리 및 분석 속도를 높이는 것입니다. Star 스키마는 차원 테이블 네트워크 내에서 데이터의 "비정규화"를 통해 이 목표를 달성합니다.

전통적으로 데이터베이스 관리자는 동일한 데이터의 중복 사본을 제거하여 데이터의 "정규화", 즉 중복 정보를 하나의 사본으로 정규화하려고 했습니다. 데이터 사본 하나만 업데이트하면 되므로 쓰기 명령이 더 빨라졌습니다.

그러나 데이터 시스템이 여러 차원 테이블로 확장되는 경우 여러 소스의 데이터에 액세스하고 분석하면 읽기 쿼리 및 분석 속도가 느려집니다. 속도를 높이기 위해 Star 스키마는 데이터를 “비정규화”하여 데이터베이스 정규화의 기존 규칙을 완화합니다.

Star 스키마는 차원 테이블에서 팩트 데이터(또는 ID 번호 기본 키)를 가져와 이 정보를 복제하고 팩트 테이블에 저장합니다. 이러한 방식으로 팩트 테이블은 모든 정보 소스를 함께 연결합니다. 이를 통해 읽기 쿼리 및 분석 속도가 무한히 빨라집니다. 그러나 쓰기 명령 속도는 저하됩니다. 더 느린 쓰기 명령은 시스템이 각 업데이트 후에 "비정규화된" 데이터의 모든 대응 사본을 업데이트해야 하기 때문에 발생합니다.

Star 스키마의 이점

Star 스키마는 다음과 같은 이점을 제공합니다.

• 더 간단해진 쿼리: 모든 데이터가 팩트 테이블을 통해 연결되기 때문에 여러 차원 테이블은 하나의 큰 정보 테이블로 처리되므로, 쿼리를 더 간단하고 쉽게 수행할 수 있습니다.
• 더 쉬워진 비즈니스 인사이트 보고: Star 스키마는 현재 보고서 및 기간별 보고서와 같은 비즈니스 보고서를 가져오는 프로세스를 간소화합니다.
• 더 향상된 쿼리 성능: 고도로 정규화된 스키마의 병목 현상을 제거함으로써 쿼리 속도가 증가하고 읽기 전용 명령의 성능이 향상됩니다.
• OLAP 시스템에 데이터 제공: OLAP(온라인 분석 처리) 시스템은 Star 스키마를 사용하여 OLAP 큐브를 구축할 수 있습니다.

Star 스키마의 당면 과제

앞서 언급했듯이 Star 스키마에서 읽기 쿼리 및 분석을 개선하려면 다음과 같은 문제가 발생할 수 있습니다.

• 데이터 무결성 감소: 비정규화된 데이터 구조로 인해 Star 스키마는 데이터 무결성을 적용하지 않습니다. Star 스키마는 이상 현상이 발생하는 것을 방지하기 위해 대책을 사용하지만 간단한 삽입 또는 업데이트 명령은 여전히 데이터 불일치를 유발할 수 있습니다.
• 다양하고 복잡한 쿼리를 처리하는 역량 감소: 데이터베이스 디자이너는 특정 분석 요구 사항에 맞게 Star 스키마를 구축하고 최적화합니다. 이는 비정규화된 데이터 세트이므로 상대적으로 좁은 범위의 단순 쿼리 세트에서 가장 잘 작동합니다. 이에 비해 정규화된 스키마는 훨씬 더 복잡한 분석 쿼리를 허용합니다.
• 다대다 관계 없음: 단순한 차원 스키마를 제공하기 때문에 Star 스키마는 "다대다 데이터 관계"에 적합하지 않습니다.

관련 게시물: 6 Database Schema Designs and How to Use Them

Snowflake 스키마란?

Star 스키마가 작동하는 방식을 알아봤으므로 이제 눈송이 모양의 Snowflake 스키마를 살펴볼 준비가 되었습니다. Snowflake 스키마의 목적은 Star 스키마에서 비정규화된 데이터를 정규화하는 것입니다. 이는 쓰기 명령 속도 저하와 일반적으로 "Star 스키마"와 관련된 기타 문제를 해결합니다.

Snowflake 스키마는 "다차원" 구조입니다. 그 핵심에는 차원 테이블에서 찾은 정보를 연결하는 팩트 테이블이 있으며, 이는 Star 스키마에서처럼 외부로 방출됩니다. 차이점은 Snowflake 스키마의 차원 테이블이 이를 둘 이상의 테이블로 나눈다는 것입니다. 이렇게 하면 Snowflake 패턴이 생성됩니다.

이 "Snowflake" 방법을 통해 Snowflake 스키마는 (1) "낮은 카디널리티" 속성(상위 테이블에 여러 번 나타남)을 제거하고 (2) 차원 테이블이 완전히 정규화될 때까지 차원 테이블을 둘 이상의 테이블로 전환하여 연결되는 차원 테이블을 정규화합니다.

Snowflake 패턴과 마찬가지로 Snowflake 데이터베이스는 매우 복잡해집니다. 스키마는 하위 테이블에 둘 이상의 상위 테이블이 있는 정교한 데이터 관계를 생성할 수 있습니다.

IBM은 Snowflake 스키마와 Star 스키마를 다음과 같이 효과적으로 비교합니다.

"Star 스키마와 Snowflake 스키마 설계는 팩트 및 차원을 별도의 테이블로 분리하는 메커니즘입니다. Snowflake 스키마는 여러 개의 차원을 가질 수 있고 각 차원은 여러 개의 레벨을 가질 수 있습니다."

Snowflake 스키마 다이어그램

Snowflake 개념에 대해 깊이 다루기 전에 Snowflake 스키마의 이미지부터 살펴보겠습니다.

*이미지 제공: SqlPac at English Wikipedia, CC BY-SA 3.0.

위의 이미지에서는 Star 테이블의 예를 사용하고 각 치수 테이블을 "Snowflake"로 만들었습니다. 먼저 Dim_Product 차원 테이블부터 살펴보겠습니다. Dim_Product 테이블의 다양한 열이 조회 테이블로 Snowflake화되었습니다.

Star 스키마 예에서 Dim_Product에는 브랜드의 비수치 이름이 포함되었습니다. 이제 Dim_Brand 조회 테이블을 가리키는 Brand_Id 번호만 포함됩니다. Dim_Product 테이블을 이와 같은 수치 값으로 변환하여 시스템이 쿼리를 처리할 수 있는 속도를 높입니다. 무엇보다도 데이터를 저장하는 데 필요한 공간을 줄이게 됩니다. 이는 Dim_Product 테이블에 더 이상 브랜드의 전체 이름(Brand_Id 번호에 비해 긴 데이터 문자열) 항목이 여러 개 포함되지 않기 때문입니다.

간단히 말해서 수치는 서면 이름이나 정성적 설명 값보다 처리에 필요한 공간과 시간이 크게 줄어듭니다. 따라서 차원 테이블을 조회 테이블로 Snowflake화하면 수백만 개의 데이터 행과 열을 처리할 때 스토리지 비용을 대폭 절감할 수 있습니다.

방대한 양의 데이터를 다루고 있다면, 데이터를 이동하고 가시성을 확보하는 방법에 대한 오래된 문제도 해결하려고 노력하고 있을 것입니다. Integrate.io의 14일 무료 평가판을 시작한 후, 저희 팀과의 미팅을 예약하여 강력한 ETL 툴이 어떻게 시스템 전체에서 데이터를 손쉽게 푸시하고 풀링하는 데 도움이 되는지 알아보세요.

Snowflake 스키마의 이점

Snowflake 스키마는 일반 Star 스키마에 비해 다음과 같은 이점을 제공합니다.

• 많은 OLAP 데이터베이스 모델링 툴과 호환: 데이터 과학자가 데이터 분석 및 모델링에 사용하는 특정 OLAP 데이터베이스 툴은 Snowflake 데이터 스키마를 사용하도록 특별히 설계되었습니다.
• 데이터 저장 요구 사항 감소: 일반적으로 Star 스키마에서 비정규화되는 데이터를 정규화하면 디스크 공간 요구 사항을 크게 줄일 수 있습니다. 본질적으로 이는 수치가 아닌 데이터의 긴 문자열(설명자 및 이름과 관련된 정보)을 스토리지 관점에서 훨씬 덜 부담되는 수치 키로 변환하기 때문입니다.

Snowflake 스키마의 당면 과제

Snowflake 스키마와 관련된 세 가지 잠재적인 문제가 있습니다.

• 복잡한 데이터 스키마: 상상할 수 있듯이 Snowflake 스키마는 Star 스키마의 속성을 정규화하면서 많은 수준의 복잡성을 생성합니다. 이러한 복잡성으로 인해 소스 쿼리 조인이 더 복잡해집니다. 데이터를 저장하는 보다 효율적인 방법을 제공하는 데 있어 Snowflake는 이러한 복잡한 조인을 탐색하는 동안 성능 저하를 초래할 수 있습니다. 그러나 처리 기술의 발전으로 인해 최근 몇 년 동안 Snowflake 스키마 쿼리 성능이 향상되었습니다. 이러한 이유로 Snowflake 스키마의 인기가 증가하고 있습니다.
• 큐브 데이터 처리 속도 저하: Snowflake 스키마에서 복잡한 조인으로 인해 큐브 데이터 처리 속도가 느려집니다. Star 스키마는 일반적으로 큐브 데이터 처리에 더 효과적입니다.
• 낮은 데이터 무결성 수준: Snowflake 스키마는 UPDATE 및 INSERT 명령을 수행한 후 더 큰 정규화와 더 적은 데이터 손상 위험을 제공하지만, 기존의 고도로 정규화된 데이터베이스 구조와 함께 제공되는 초국가적인 보증 수준은 제공하지 않습니다. 따라서 Snowflake 스키마에 데이터를 로드할 때 로드 후 정보 품질을 주의하고 다시 확인하는 것이 중요합니다.

관련 게시물: Top 17 Business Intelligence Tools Of 2024

요약

요약하자면, Star 스키마와 Snowflake 스키마는 데이터 웨어하우징에서 중요한 역할을 하며, 각각 고유한 강점을 제공하지만 각기 다른 도전 과제에 직면해 있습니다. Star 스키마는 큐브 데이터에 단순성과 빠른 처리 속도를 제공하는 반면, Snowflake 스키마는 복잡성이라는 대가로 스토리지 효율성을 가져옵니다. 의사 결정권자는 데이터 웨어하우징 프로젝트의 구체적인 요구 사항에 따라 이러한 장단점을 비교 검토해야 합니다. 또한, 올바른 툴과 전략을 마련하면 이러한 스키마와 관련된 많은 문제를 효과적으로 해결할 수 있습니다.

Integrate.io의 지원 방법

방대한 양의 데이터를 다루고 있고 Star 스키마와 Snowflake 스키마 사이를 오가는 경우 Integrate.io가 도움이 될 수 있습니다. Star 스키마와 Snowflake 스키마를 관리하기 위해 맞춤 제작된 Integrate.io의 솔루션이 어떻게 원활한 데이터 이동과 풍부한 가시성을 제공하는지 알아보세요. 지금 바로 14일 무료 평가판을 시작하거나 데모를 예약하세요. 전문가가 필요에 맞는 스키마를 선택하고 최적화할 수 있도록 안내해 드리겠습니다.