schema types data warehouse modeling star snowflake schema
이 자습서에서는 다양한 데이터웨어 하우스 스키마 유형에 대해 설명합니다. 스타 스키마 및 눈송이 스키마 및 스타 스키마 대 눈송이 스키마의 차이점에 대해 알아보십시오.
이것에 초보자를위한 Date Warehouse 튜토리얼 , 우리는 데이터웨어 하우스의 차원 데이터 모델 이전 튜토리얼에서.
이 튜토리얼에서는 데이터 마트 (또는) 데이터웨어 하우스 테이블을 구조화하는 데 사용되는 데이터웨어 하우스 스키마에 대해 모두 학습합니다.
자바에서 배열에 추가 할 수 있습니까?
시작하자!!
대상 청중
- 데이터웨어 하우스 / ETL 개발자 및 테스터.
- 데이터베이스 개념에 대한 기본 지식이있는 데이터베이스 전문가.
- 데이터웨어 하우스 / ETL 영역을 이해하고자하는 데이터베이스 관리자 / 빅 데이터 전문가.
- 데이터웨어 하우스 일자리를 찾고있는 대학 졸업자 / 신입생.
학습 내용 :
데이터웨어 하우스 스키마
데이터웨어 하우스에서 스키마는 모든 데이터베이스 엔티티 (팩트 테이블, 차원 테이블) 및 논리적 연관으로 시스템을 구성하는 방법을 정의하는 데 사용됩니다.
다음은 DW의 다양한 유형의 스키마입니다.
- 스타 일정
- SnowFlake 스키마
- 갤럭시 다이어그램
- 스타 클러스터 스키마
# 1) 스타 스케줄
이것은 데이터웨어 하우스에서 가장 간단하고 효과적인 스키마입니다. 여러 차원 테이블로 둘러싸인 중앙의 팩트 테이블은 스타 스키마 모델의 스타와 유사합니다.
사실 테이블은 모든 차원 테이블과 일대 다 관계를 유지합니다. 사실 테이블의 모든 행은 외래 키 참조가있는 차원 테이블 행과 연관됩니다.
위의 이유 때문에이 모델의 테이블 간 탐색은 집계 된 데이터를 쿼리하기 쉽습니다. 최종 사용자는이 구조를 쉽게 이해할 수 있습니다. 따라서 모든 BI (비즈니스 인텔리전스) 도구는 스타 스키마 모델을 크게 지원합니다.
스타 스키마를 디자인하는 동안 차원 테이블은 의도적으로 비정규 화됩니다. 더 나은 분석 및보고를 위해 상황 별 데이터를 저장하는 많은 속성이 있습니다.
스타 스키마의 이점
- 쿼리는 데이터를 검색하는 동안 매우 간단한 조인을 사용하므로 쿼리 성능이 향상됩니다.
- 보고를 위해 데이터를 검색하는 것은 어떤 기간의 어느 시점에서나 간단합니다.
스타 스키마의 단점
- 요구 사항에 많은 변경 사항이있는 경우 기존 스타 스키마는 장기적으로 수정 및 재사용하는 것이 권장되지 않습니다.
- 데이터 중복성은 테이블이 계층 적으로 분할되지 않기 때문에 더 많습니다.
스타 스키마의 예는 다음과 같습니다.
스타 스키마 쿼리
최종 사용자는 비즈니스 인텔리전스 도구를 사용하여 보고서를 요청할 수 있습니다. 이러한 모든 요청은 내부적으로 'SELECT 쿼리'체인을 생성하여 처리됩니다. 이러한 쿼리의 성능은 보고서 실행 시간에 영향을 미칩니다.
위의 Star 스키마 예에서 비즈니스 사용자가 2018 년 1 월에 Kerala 주에서 판매 된 Novel 및 DVD의 수를 알고 싶다면 Star 스키마 테이블에 다음과 같이 쿼리를 적용 할 수 있습니다.
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Product pdim, Sales sfact, Store sdim, Date ddim WHERE sfact.product_id = pdim.product_id AND sfact.store_id = sdim.store_id AND sfact.date_id = ddim.date_id AND sdim.state = 'Kerala' AND ddim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name 결과 :
| 상품명 | 수량 _ 판매 | |
|---|---|---|
| 7 | 누구나 쉽게 스키마를 이해하고 설계 할 수 있습니다. | 스키마를 이해하고 설계하는 것은 어렵습니다. |
| 짧은 이야기 | 12,702 | |
| DVD | 32,919 |
스타 스키마를 쿼리하는 것이 얼마나 쉬운 지 이해 하셨기를 바랍니다.
# 2) SnowFlake 스키마
스타 스키마는 SnowFlake 스키마를 설계하기위한 입력 역할을합니다. 스노우 플레이 킹은 스타 스키마의 모든 차원 테이블을 완전히 정규화하는 프로세스입니다.
차원 테이블의 여러 계층 구조로 둘러싸인 중앙에 팩트 테이블의 배열은 SnowFlake 스키마 모델의 SnowFlake처럼 보입니다. 모든 사실 테이블 행은 외래 키 참조가있는 차원 테이블 행과 연관됩니다.
SnowFlake 스키마를 설계하는 동안 차원 테이블은 의도적으로 정규화됩니다. 외래 키는 해당 상위 속성에 링크하기 위해 차원 테이블의 각 레벨에 추가됩니다. SnowFlake 스키마의 복잡성은 차원 테이블의 계층 구조 수준에 정비례합니다.
SnowFlake 스키마의 이점 :
- 새 차원 테이블을 생성하면 데이터 중복성이 완전히 제거됩니다.
- 스타 스키마와 비교할 때 Snow Flaking 차원 테이블에서 사용하는 스토리지 공간이 더 적습니다.
- Snow Flaking 테이블을 업데이트 (또는) 유지하는 것은 쉽습니다.
SnowFlake 스키마의 단점 :
- 정규화 된 차원 테이블로 인해 ETL 시스템은 테이블 수를로드해야합니다.
- 추가 된 테이블 수로 인해 쿼리를 수행하려면 복잡한 조인이 필요할 수 있습니다. 따라서 쿼리 성능이 저하됩니다.
SnowFlake 스키마의 예는 다음과 같습니다.
위 SnowFlake 다이어그램의 차원 테이블은 아래에 설명 된대로 정규화됩니다.
- Date 차원은 Date 테이블에 외래 키 ID를 남겨 분기 별, 월별 및 주간 테이블로 정규화됩니다.
- Store 차원은 State에 대한 테이블을 구성하도록 정규화됩니다.
- 제품 차원은 브랜드로 정규화됩니다.
- Customer 차원에서 도시에 연결된 속성은 Customer 테이블에 외래 키 ID를 남겨 두어 새 City 테이블로 이동됩니다.
같은 방식으로 단일 차원은 여러 수준의 계층을 유지할 수 있습니다.
위 다이어그램의 여러 계층 수준은 다음과 같이 참조 할 수 있습니다.
- 분기 별 ID, 월별 ID 및 주간 ID는 날짜 차원 계층 구조에 대해 생성되고 날짜 차원 테이블에 외래 키로 추가 된 새 서로 게이트 키입니다.
- State id는 Store 차원 계층 구조에 대해 생성 된 새 서로 게이트 키이며 Store 차원 테이블에 외래 키로 추가되었습니다.
- Brand id는 Product 차원 계층 구조에 대해 생성 된 새 서로 게이트 키이며 Product 차원 테이블에 외래 키로 추가되었습니다.
- City id는 Customer 차원 계층 구조에 대해 생성 된 새 서로 게이트 키이며 Customer 차원 테이블에 외래 키로 추가되었습니다.
눈송이 스키마 쿼리
SnowFlake 스키마를 사용하는 스타 스키마 구조와 동일한 종류의 보고서를 최종 사용자에 대해 생성 할 수 있습니다. 그러나 여기서 쿼리는 약간 복잡합니다.
위의 SnowFlake 스키마 예제에서 Star 스키마 쿼리 예제에서 디자인 한 것과 동일한 쿼리를 생성 할 것입니다.
즉, 비즈니스 사용자가 2018 년 1 월 케 랄라 주에서 판매 된 소설과 DVD의 수를 알고 싶다면 SnowFlake 스키마 테이블에 다음과 같이 쿼리를 적용 할 수 있습니다.
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Sales sfact INNER JOIN Product pdim ON sfact.product_id = pdim.product_id INNER JOIN Store sdim ON sfact.store_id = sdim.store_id INNER JOIN State stdim ON sdim.state_id = stdim.state_id INNER JOIN Date ddim ON sfact.date_id = ddim.date_id INNER JOIN Month mdim ON ddim.month_id = mdim.month_id WHERE stdim.state = 'Kerala' AND mdim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name 결과 :
| 상품명 | 수량 _ 판매 |
|---|---|
| 짧은 이야기 | 12,702 |
| DVD | 32,919 |
Star (또는) SnowFlake 스키마 테이블을 쿼리 할 때 기억해야 할 사항
모든 쿼리는 아래 구조로 디자인 할 수 있습니다.
SELECT 절 :
- select 절에 지정된 속성이 쿼리 결과에 표시됩니다.
- Select 문은 또한 그룹을 사용하여 집계 된 값을 찾기 때문에 where 조건에서 group by 절을 사용해야합니다.
FROM 절 :
- 모든 필수 팩트 테이블과 차원 테이블은 컨텍스트에 따라 선택해야합니다.
WHERE 조항 :
- 팩트 테이블 속성과 결합하여 where 절에서 적절한 차원 속성을 언급합니다. 차원 테이블의 서로 게이트 키는 쿼리 할 데이터 범위를 수정하기 위해 팩트 테이블의 각 외래 키와 조인됩니다. 이를 이해하려면 위에 작성된 스타 스키마 쿼리 예제를 참조하십시오. SnowFlake 스키마 예제에 작성된대로 내부 / 외부 조인을 사용하는 경우 from 절 자체에서 데이터를 필터링 할 수도 있습니다.
- 차원 속성은 where 절에서 데이터에 대한 제약으로도 언급됩니다.
- 위의 모든 단계로 데이터를 필터링하면 보고서에 적합한 데이터가 반환됩니다.
비즈니스 요구에 따라 위의 구조를 따라 스타 스키마 (또는) SnowFlake 스키마 쿼리에 팩트, 차원, 속성 및 제약 조건을 추가 (또는) 제거 할 수 있습니다. 또한 하위 쿼리를 추가 (또는) 다른 쿼리 결과를 병합하여 복잡한 보고서에 대한 데이터를 생성 할 수 있습니다.
# 3) 갤럭시 다이어그램
은하 스키마는 Fact Constellation Schema라고도합니다. 이 스키마에서 여러 팩트 테이블은 동일한 차원 테이블을 공유합니다. 팩트 테이블과 차원 테이블의 배열은 Galaxy 스키마 모델에서 별 모음처럼 보입니다.
이 모델에서 공유 된 치수를 준수 치수라고합니다.
이 유형의 스키마는 복잡한 요구 사항 및 Star 스키마 (또는) SnowFlake 스키마에서 지원하기 위해 더 복잡한 집계 된 팩트 테이블에 사용됩니다. 이 스키마는 복잡성으로 인해 유지 관리가 어렵습니다.
Galaxy Schema의 예는 아래와 같습니다.
# 4) 스타 클러스터 스키마
많은 차원 테이블이있는 SnowFlake 스키마는 쿼리하는 동안 더 복잡한 조인이 필요할 수 있습니다. 차원 테이블이 더 적은 스타 스키마는 더 많은 중복성을 가질 수 있습니다. 따라서 위의 두 스키마의 특징을 결합하여 성단 스키마가 등장했습니다.
스타 스키마는 스타 클러스터 스키마를 설계하기위한 기본이며 스타 스키마의 필수 차원 테이블이 거의 눈에 띄지 않아 더욱 안정적인 스키마 구조를 형성합니다.
다음은 스타 클러스터 스키마의 예입니다.
어떤 것이 더 나은 눈송이 스키마 또는 스타 스키마입니까?
DW 시스템에서 사용되는 데이터웨어 하우스 플랫폼과 BI 도구는 설계 할 적절한 스키마를 결정하는 데 중요한 역할을합니다. Star 및 SnowFlake는 DW에서 가장 자주 사용되는 스키마입니다.
BI 도구를 사용하여 비즈니스 사용자가 간단한 쿼리로 테이블 구조와 쉽게 상호 작용할 수있는 경우 스타 스키마가 선호됩니다. 비즈니스 사용자가 더 많은 조인과 복잡한 쿼리로 인해 테이블 구조와 직접 상호 작용하기 위해 BI 도구가 더 복잡한 경우 SnowFlake 스키마가 선호됩니다.
일부 저장 공간을 절약하고 싶거나 DW 시스템에이 스키마를 설계하기 위해 최적화 된 도구가있는 경우 SnowFlake 스키마를 사용할 수 있습니다.
스타 스키마 대 눈송이 스키마
다음은 Star 스키마와 SnowFlake 스키마의 주요 차이점입니다.
| S. 아니 | 스타 일정 | 스노우 플레이크 스키마 |
|---|---|---|
| 하나 | 데이터 중복성은 그 이상입니다. | 데이터 중복성은 적습니다. |
| 두 | 차원 테이블을위한 저장 공간이 더 많습니다. | 차원 테이블의 저장 공간은 비교적 적습니다. |
| 삼 | 비정규 화 된 차원 테이블을 포함합니다. | 정규화 된 차원 테이블을 포함합니다. |
| 4 | 단일 사실 테이블은 여러 차원 테이블로 둘러싸여 있습니다. | 단일 사실 테이블은 차원 테이블의 여러 계층으로 둘러싸여 있습니다. |
| 5 | 쿼리는 팩트와 차원 간의 직접 조인을 사용하여 데이터를 가져옵니다. | 쿼리는 팩트와 차원 간의 복잡한 조인을 사용하여 데이터를 가져옵니다. |
| 6 | 쿼리 실행 시간이 더 짧습니다. | 쿼리 실행 시간이 더 깁니다. |
| 8 | 하향식 접근 방식을 사용합니다. | 상향식 접근 방식을 사용합니다. |
결론
이 자습서의 장점 및 단점과 함께 다양한 유형의 데이터웨어 하우스 스키마에 대해 잘 이해 하셨기를 바랍니다.
또한 Star Schema 및 SnowFlake Schema를 쿼리 할 수있는 방법과 차이점과 함께이 둘 중에서 선택할 스키마를 배웠습니다.
ETL의 데이터 마트에 대해 자세히 알아 보려면 다가오는 튜토리얼을 계속 지켜봐주십시오 !!
=> 여기에서 간단한 데이터웨어 하우징 교육 시리즈를 확인하십시오.