스타 스키마

컴퓨팅에서 스타 스키마는 데이터 마트 스키마의 가장 단순한 스타일이며 데이터 웨어하우스와 차원 데이터 마트를 개발하는 데 가장 널리 사용되는 접근방식이다.^[1] 스타 스키마는 임의의 수의 치수 테이블을 참조하는 하나 이상의 팩트 테이블로 구성된다. 스타 스키마는 눈송이 스키마의 중요한 특수 케이스로, 더 간단한 질의를 처리하는데 더 효과적이다.^[2]

스타 스키마는 실제 모델이 사실표가 중앙에 있는 별 모양과 그것을 둘러싸고 있는 차원 테이블이 별의 포인트를 나타내는 것과 유사하다는^[3] 데서 그 이름을 얻는다.

모델

스타 스키마는 비즈니스 프로세스 데이터를 사실로 구분하고, 비즈니스에 대한 측정 가능하고 정량적인 데이터와 사실 데이터와 관련된 기술 속성인 치수를 보유한다. 사실 데이터의 예로는 판매 가격, 판매 수량 및 시간, 거리, 속도 및 중량 측정이 있다. 관련 차원 속성 예로는 제품 모델, 제품 색상, 제품 크기, 지리적 위치 및 영업 사원 이름이 있다.

여러 차원을 가진 스타 스키마를 지네 스키마라고 부르기도 한다.^[4] 몇 가지 속성만 치수를 가지면 유지하기가 더 간단하지만, 많은 테이블 조인이 있는 쿼리가 발생하고 스타 스키마를 사용하는 것이 덜 쉬워진다.

팩트 테이블

팩트 테이블은 특정 이벤트에 대한 측정 또는 메트릭을 기록한다. 팩트 테이블은 일반적으로 숫자 값과 기술 정보가 보관되는 치수 데이터에 대한 외래 키로 구성된다.^[4] 팩트 테이블은 낮은 수준의 균일한 세부사항("grandularity" 또는 "grain"으로 알려져 있다), 즉 팩트 테이블은 매우 원자적인 수준에서 사건을 기록할 수 있다. 이것은 시간이 지남에 따라 팩트 표에 많은 수의 기록이 축적되는 결과를 초래할 수 있다. 팩트 테이블은 다음 세 가지 유형 중 하나로 정의된다.

• 트랜잭션 팩트 표에는 특정 이벤트(예: 판매 이벤트)에 대한 사실이 기록됨
• 스냅샷 팩트 테이블은 특정 시점에 사실을 기록함(예: 월말의 계정 세부 정보)
• 스냅샷 테이블 누적은 특정 시점에 집계된 사실(예: 제품의 총 월별 판매)

팩트 테이블에는 일반적으로 각 행이 고유하게 식별될 수 있도록 대리 키가 할당된다. 이 키는 간단한 기본 키 입니다.

치수표

차원 테이블은 대개 팩트 테이블에 비해 상대적으로 적은 수의 레코드를 가지고 있지만, 각 레코드에는 팩트 데이터를 설명하는 속성 수가 매우 많을 수 있다. 치수는 다양한 특성을 정의할 수 있지만, 치수 표에 의해 정의되는 가장 일반적인 속성 중 일부는 다음과 같다.

• 시간 치수 표는 이벤트가 스타 스키마에 기록되는 최저 시간 세분화 수준에서 시간을 설명한다.
• 국가, 주 또는 시와 같은 위치 데이터를 설명하는 지리 차원 표
• 제품 치수 표에 제품 설명
• 직원 차원 표에 영업 직원과 같은 직원이 설명됨
• 보고 단순화를 위한 시간 범위, 달러 값 또는 기타 측정 가능한 수량을 설명하는 범위 차원 표

치수 테이블에는 일반적으로 대리 기본 키(일반적으로 단일 열 정수 데이터 유형)가 할당되며, 자연 키를 구성하는 치수 속성의 조합에 매핑된다.

혜택들

스타 스키마는 변별화된다. 즉, 트랜잭션 관계형 데이터베이스에 적용되는 정규화의 일반적인 규칙은 스타 스키마 설계 및 구현 중에 완화된다. 스타-스키마 폄하 시 얻을 수 있는 이점은 다음과 같다.

• 단순한 쿼리 – 일반적으로 스타 스키마 조인 로직은 고도로 정규화된 트랜잭션 스키마에서 데이터를 검색하는 데 필요한 조인 논리보다 간단하다.
• 단순화된 비즈니스 보고 논리 – 고도로 정규화된 스키마와 비교할 때, 스타 스키마는 기간 초과 및 보고와 같은 일반적인 비즈니스 보고 논리를 단순화한다.
• 성능 향상 쿼리 – 스타 스키마는 고도로 정규화된 스키마와 비교하여 읽기 전용 보고 애플리케이션에 성능 향상 기능을 제공할 수 있다.
• 빠른 집계 – 스타 스키마에 대한 단순한 쿼리로 집계 작업의 성능이 향상될 수 있다.
• 정육면체 공급 – 스타 스키마는 모든 OLAP 시스템에서 전용 OLAP 정육면체를 효율적으로 구축하기 위해 사용된다. 사실 대부분의 주요 OLAP 시스템은 전용 정육면체 구조를 구축하지 않고도 스타 스키마를 소스로 직접 사용할 수 있는 ROLAP 작동 모드를 제공한다.

단점들

스타 스키마의 주요 단점은 분석적 필요성 측면에서 표준화된 데이터 모델만큼 유연하지 않다는 것이다.^{[citation needed]} 표준화된 모델은 모델에 정의된 비즈니스 논리를 따르는 한 모든 종류의 분석 쿼리를 실행할 수 있다. 스타 스키마는 특정 데이터 뷰를 지향하여 더욱 목적에 맞게 구축되는 경향이 있으므로, 실제로 더 복잡한 분석을 허용하지 않는다.^{[citation needed]} 스타 스키마는 사업체 간의 다대다수 관계를 쉽게 지원하지 않는다. 일반적으로 이러한 관계는 단순한 치수 모델에 부합하기 위해 스타 스키마에서 단순화된다.

또 다른 단점은 데이터 무결성이 탈원화된 상태로^{[citation needed]} 인해 제대로 강화되지 않는다는 것이다. 일회성 삽입 및 업데이트로 인해 데이터 이상이 발생할 수 있으며, 이를 방지하기 위해 정규화된 스키마가 설계된다. 일반적으로 스타 스키마는 정상화에 의해 제공되는 보호의 부족을 보완하기 위해 일괄 처리 또는 거의 실시간 "트래클 피드"를 통해 고도로 통제된 방식으로 로드된다.

예

예제 쿼리에서 사용하는 스타 스키마.

날짜, 스토어 및 제품별로 분류된 판매 데이터베이스(아마도 스토어 체인에서)를 고려하십시오. 오른쪽 스키마의 이미지는 눈송이 스키마 기사에서 제공하는 샘플 스키마의 스타 스키마 버전이다.

Fact_Sales 팩트 테이블이고 3차원 테이블이 있다. Dim_Date, Dim_Store 그리고 Dim_Product.

각 치수 테이블에는 기본 키가 있다. Id 열(예: 스키마에서 행으로 표시됨)의 열 중 하나와 관련된 열 Fact_Sales 테이블의 3열(수직) 기본 키(수직)Date_Id, Store_Id, Product_Id. 기본 키가 아닌 키 Units_Sold 이 예에서 팩트 표의 열은 계산 및 분석에 사용할 수 있는 측정값 또는 측정지표를 나타낸다. 치수 테이블의 비주 키 열은 치수의 추가 속성(예: Year 의 Dim_Date 치수).

예를 들어, 1997년에 브랜드와 국가별로 얼마나 많은 TV가 판매되었는지에 대해 다음과 같은 질의를 한다.

선택  P.브랜드,  S.나라 AS 나라들.,  SUM(F.Units_Sold)  From 팩트_세일즈 F 이너 가입하다 딤_날짜 D    켜기 (F.날짜_Id = D.아이디) 이너 가입하다 딤_스토어 S   켜기 (F.스토어_Id = S.아이디) 이너 가입하다 Dim_Product P 켜기 (F.product_Id = P.아이디)  어디에 D.연도 = 1997 AND  P.Product_Category = 'tv'  그룹 BY  P.브랜드,  S.나라 

참고 항목

• 데이터창고
• 온라인 분석 처리
• 리버스 스타 스키마
• 눈송이 스키마
• 팩트 별자리
• 활동 스키마

참조

외부 링크

• 별: 쿼리에 최적화된 스키마를 위한 패턴 언어
• 팩트 별자리 스키마