데이터 웨어하우스 모델링에서 스타 스키마란 무엇입니까?
데이비드 카터
⚡ 스마트 요약
데이터 웨어하우스 모델링에서 스타 스키마는 중앙 팩트 테이블을 주변 차원 테이블의 중심에 배치하여 비정규화된 별 모양 설계를 만듭니다. 이는 분석 쿼리를 단순화하고 보고 속도를 높이며 비즈니스 인텔리전스 플랫폼 전반에서 OLAP 큐브의 성능을 향상시킵니다.
스타 스키마란 무엇입니까?
A 스타 스키마 데이터 웨어하우스에서 스타 스키마는 하나의 중앙 팩트 테이블이 여러 개의 관련 차원 테이블에 연결되는 모델링 구조입니다. 팩트 테이블이 중심에 위치하고 차원 테이블이 마치 점으로 뻗어나가는 별 모양을 닮았다고 해서 스타 스키마라고 불립니다.
스타 스키마는 가장 단순한 형태의 데이터 웨어하우스 스키마이며, 스타 조인 스키마라고도 합니다. 차원 테이블이 비정규화되어 있기 때문에 매우 큰 데이터 세트를 쿼리하는 데 최적화되어 있어 대규모 데이터 세트 쿼리에 널리 사용됩니다. 차원 모델링 및보고.
다차원 스키마란 무엇인가?
A 다차원 스키마 이 스키마는 데이터 웨어하우스 시스템을 모델링하기 위해 특별히 설계되었습니다. 이러한 스키마는 분석 목적으로 구축된 매우 큰 데이터베이스의 고유한 요구 사항을 충족합니다. 올랩 일상적인 거래 처리 목적이 아니라.
데이터 웨어하우스 스키마 유형: 다차원 스키마에는 크게 세 가지 유형이 있으며, 각 유형은 고유한 장점을 제공합니다.
- 스타 스키마 – 중앙 팩트 테이블이 비정규화된 차원 테이블에 직접 연결됩니다.
- 눈송이 스키마 – 차원이 추가적인 하위 차원 테이블로 정규화되는 스타 스키마의 확장입니다.
- 갤럭시 스키마 팩트 컨스턴테이션이라고도 하는 이 방식은 공통 차원 테이블을 공유하는 여러 팩트 테이블을 사용합니다.
스노우플레이크 스키마는 스타 스키마를 직접적으로 기반으로 하기 때문에, 스타 스키마의 상세 예제를 살펴보기 전에 두 모델을 비교해 보는 것이 도움이 됩니다.
스타 스키마 vs 스노우플레이크 스키마
스타 스키마와 눈송이 스키마 두 스키마 모두 팩트 테이블과 디멘션 테이블을 중심으로 데이터를 구성하지만, 디멘션을 저장하는 방식에서 차이가 있습니다. 스타 스키마는 각 디멘션을 하나의 비정규화된 테이블에 저장하는 반면, 스노우플레이크 스키마는 이러한 디멘션을 여러 개의 관련 테이블로 정규화합니다.
- 논리적 구조: 별 모양 도식은 평면적이고 단순하지만, 눈송이 모양 도식은 차원을 하위 차원으로 분기시킵니다.
- 조회 속도: 스타 스키마는 조인이 적게 필요하므로 쿼리 실행 속도가 일반적으로 더 빠르고 SQL도 더 간단해집니다.
- 스토리지 : 스노우플레이크 스키마는 중복을 제거하므로 공간을 덜 사용하지만 설계 복잡성은 증가합니다.
- 데이터 무결성: 정규화된 눈송이 차원은 무결성을 더 잘 보장하는 반면, 비정규화된 별 차원은 성능에 유리합니다.
- 사용 용이성 : 스타 스키마는 분석가가 이해하기 쉽고 유지 관리가 빠른 반면, 스노우플레이크 스키마는 더 신중한 설계가 필요합니다.
실제로 팀들은 빠르고 직관적인 보고가 필요한 데이터 마트 및 대시보드에는 스타 스키마를 선택하고, 저장 공간 절약과 엄격한 일관성이 더 중요한 경우에는 스노우플레이크 스키마를 선택하는 경우가 많습니다.
스타 스키마의 예시
다음 스타 스키마 예시에서 팩트 테이블은 중앙에 위치하며 Dealer_ID, Model_ID, Date_ID, Product_ID, Branch_ID와 같은 모든 차원 테이블에 대한 키와 판매량, 매출과 같은 측정 가능한 속성을 저장합니다.
각각의 주변 차원 테이블은 해당 측정값에 설명적인 맥락을 추가하므로, 다른 테이블을 조인하지 않고도 단일 쿼리로 딜러, 모델, 날짜, 제품 또는 지점별로 판매 데이터를 그룹화하거나 필터링할 수 있습니다.
사실 테이블
스타 스키마에서 팩트 테이블은 팩트 정보를 담고 있으며 차원 테이블과 연결되어 있습니다. 팩트 테이블은 두 가지 유형의 열을 포함합니다.
- 사실 또는 측정값을 저장하는 열입니다.
- 각 차원 테이블에 연결되는 외래 키입니다.
일반적으로 팩트 테이블의 기본 키는 테이블을 구성하는 모든 외래 키로 이루어진 복합 키입니다.
팩트 테이블은 상세 수준의 팩트 또는 집계된 팩트를 포함할 수 있습니다. 집계된 팩트를 포함하는 팩트 테이블은 종종 요약 테이블이라고 하며, 일반적으로 이미 특정 수준으로 집계된 팩트를 포함합니다.
차원 테이블
차원은 데이터를 계층 구조로 분류하는 구조입니다. 계층 구조나 레벨이 없는 차원은 평면 차원 또는 목록이라고 합니다. 각 차원 테이블의 기본 키는 팩트 테이블의 복합 기본 키의 일부입니다.
차원 속성은 제품 이름이나 도시와 같이 차원 값을 설명하는 데 도움이 되는 설명적인 텍스트 속성입니다. 차원 테이블은 거래 이벤트가 아닌 이러한 설명적인 컨텍스트를 저장하기 때문에 팩트 테이블은 일반적으로 차원 테이블보다 훨씬 큽니다.
스타 스키마 설계 방법
스타 스키마 설계는 랄프 킴볼이 대중화한 차원 모델링 접근 방식을 따릅니다. 목표는 명확하고 재사용 가능한 차원을 중심으로 비즈니스 측정값을 구성하여 완성된 모델을 쉽게 쿼리하고 신속하게 보고할 수 있도록 하는 것입니다. 아래의 5단계는 대부분의 차원 모델링 프로젝트에서 따르는 프로세스를 설명하며, 최상위 비즈니스 질문에서 시작하여 물리적 팩트 테이블과 차원 테이블로 내려갑니다.
- 비즈니스 프로세스를 파악하십시오: 분석하고자 하는 활동(예: 판매, 배송)을 선택하세요.ping또는 재고. 이 결정은 팩트 테이블이 무엇을 측정할지 정의합니다.
- 곡물을 신고하십시오: 각 사실 행이 나타낼 세부 정보 수준을 결정합니다. 예를 들어 품목별, 거래별 또는 일별로 한 행씩 지정할 수 있습니다. 명확한 세부 정보 수준은 모델의 일관성을 유지하는 데 도움이 됩니다.
- 치수를 확인하세요: 제품, 고객, 판매점, 지점, 날짜 등 사실을 분류하는 데 필요한 설명적 맥락을 나열합니다. 각각은 속성 차원 테이블이 됩니다.
- 사실 관계를 파악하세요: 기업이 원하는 수치적 측정값을 결정하십시오. trac판매량, 수익, 비용 등의 k 값을 중앙 정보 테이블에 입력합니다.
- 별을 만들어 보세요: 외래키를 통해 팩트 테이블을 각 차원에 연결합니다.ping 차원이 비정규화되어 다이어그램은 차원으로 둘러싸인 단일 중앙 팩트 테이블을 형성합니다.
스타 테이블을 구축한 후에는 모든 차원에 대체 키를 추가하고, 각 팩트 테이블에 연결된 날짜 차원이 있는지 확인하고, 모든 팩트 테이블의 세분성이 동일한지 확인해야 합니다. 또한 요약 테이블은 나중에 생성할 수 있으므로 가장 낮은 수준의 원자적 데이터를 먼저 로드하는 것이 좋습니다. 이러한 규칙을 따르면 스키마가 고성능에 최적화되고 간결해집니다. 데이터웨어 하우스 보고.
스타 스키마의 특성
- 스타 스키마에서 각 차원은 하나의 차원 테이블로만 표현됩니다.
- 각 차원 테이블에는 고유한 속성 집합이 포함되어 있습니다.
- 차원 테이블은 외래 키를 사용하여 팩트 테이블과 조인됩니다.
- 차원 테이블은 서로 연결되어 있지 않습니다.
- 팩트 테이블에는 키와 측정값이 포함되어 있습니다.
- 스타 스키마는 이해하기 쉽고 디스크 사용률을 최적화합니다.
- 차원 테이블은 정규화되어 있지 않습니다. 예를 들어, 위 예시에서 Country_ID는 다른 차원 테이블처럼 별도의 국가 조회 테이블을 가지고 있지 않습니다. OLTP 디자인이 그럴 겁니다.
- 이 스키마는 다양한 BI 도구에서 널리 지원됩니다.
스타 스키마의 장점
스타 스키마는 데이터 웨어하우스 설계의 인기 있는 출발점이 되는 여러 가지 이점을 제공합니다.
- 스타 스키마는 고도로 정규화된 트랜잭션 소스에서 데이터를 가져올 때 다른 스키마보다 더 간단한 조인 로직을 사용합니다.
- 스타 스키마는 기간별 비교 및 기준 시점 보고와 같은 일반적인 비즈니스 보고 로직을 단순화합니다.
- 스타 스키마는 OLAP 시스템에서 큐브를 효율적으로 구축하는 데 널리 사용되며, 대부분의 주요 OLAP 시스템에서 큐브 구조를 설계하지 않고도 스타 스키마를 소스로 사용할 수 있습니다.
- 쿼리에 적용할 수 있는 특정 성능 튜닝을 활성화함으로써 쿼리 프로세서는 더 나은 실행 계획을 제공할 수 있습니다.
스타 스키마의 단점
- 스키마가 고도로 비정규화되어 있기 때문에 데이터 무결성이 엄격하게 보장되지 않습니다.
- 고급 분석 요구 사항 측면에서 유연성이 부족합니다.
- 스타 스키마는 비즈니스 엔티티 간의 다대다 관계를 강화하지 않습니다.
스타 스키마는 언제 사용해야 할까요?
스타 스키마는 저장 공간 절약보다 빠르고 예측 가능한 쿼리 성능이 더 중요한 경우에 적합한 선택입니다. 이 모델은 차원 테이블을 비정규화하고 조인 횟수를 최소화하기 때문에 비즈니스 사용자가 대규모 과거 데이터에 대해 유사한 보고서, 대시보드 및 집계를 반복적으로 실행하는 분석 워크로드에 적합합니다.
스타 스키마가 매우 적합한 일반적인 상황은 다음과 같습니다.
- 데이터 마트: 성의 데이터 마트 단순하고 명확하게 이해되는 관계를 가진 문서는 읽기 쉬운 구조의 이점을 누릴 수 있습니다.
- BI 대시보드: 비즈니스 인텔리전스 이러한 도구들은 스타 스키마에 깔끔하게 매핑되므로 보고서와 시각화 자료를 빠르게 구축할 수 있습니다.
- OLAP 큐브: 스타 스키마는 OLAP 큐브, 집계 및 슬라이스 앤 다이스 분석을 위한 자연스러운 소스입니다.
만약 저장 공간 최소화, 엄격한 데이터 무결성 또는 심층적이고 변화하는 계층 구조에 우선순위를 두게 된다면, 스노우플레이크 스키마나 보다 정규화된 설계가 더 적합할 수 있습니다. 많은 팀들이 이 두 가지 방식을 결합하여 스타 스키마로 시작한 후, 실제로 정규화가 필요한 차원만 정규화하기도 합니다.
