스타 스키마 디자인 [닫기]

Question

데이터 웨어하우스에 스타-스키마 설계가 필수인가요?아니면 다른 디자인 패턴으로 데이터 웨어하우징을 할 수 있나요?

Answer 1

사용 스타 스키마 데이터 웨어하우스 시스템은 여러 가지 이점을 제공하며 대부분의 경우 최상위 계층에 사용하는 것이 적절합니다.'현재 상태'를 보유하고 데이터 구성과 같은 작업을 용이하게 하는 정규화된 구조인 운영 데이터 저장소(ODS)가 있을 수도 있습니다.그러나 이것이 바람직하지 않은 합리적인 상황이 있습니다.나는 ODS 레이어가 있거나 없는 시스템을 구축할 기회가 있었고 각 경우에 아키텍처를 선택하는 구체적인 이유가 있었습니다.

데이터 웨어하우스 아키텍처의 미묘함을 다루거나 Kimball 대 Kimball 비교를 시작하지 않고인몬 불꽃 전쟁 스타 스키마의 주요 이점은 다음과 같습니다.

• 대부분의 데이터베이스 관리 시스템에는 쿼리 최적화에 시설이 있습니다. 비트맵 인덱스 구조물이나지수 교차점 빠른 술어 해상도.이는 선택이 해결될 때까지 팩트 테이블(보통 인덱스보다 훨씬 큼)을 조회하지 않고도 스타 스키마에서 선택을 수행할 수 있음을 의미합니다.

• 파티셔닝 스타 스키마는 사실 테이블만 분할하면 되기 때문에 상대적으로 간단합니다(성경적으로 큰 차원이 있는 경우는 제외). 파티션 제거 이는 쿼리 최적화 프로그램이 쿼리 결과에 참여할 수 없는 파티션을 무시하여 I/O를 절약할 수 있음을 의미합니다.

• 천천히 변화하는 차원 눈송이보다 스타 스키마에서 구현하기가 훨씬 쉽습니다.

• 스키마는 이해하기 쉽고 스키마보다 조인이 덜 포함되는 경향이 있습니다. 눈송이 또는 E-R 스키마.당신의 보고팀은 당신을 좋아할 것입니다.

• 스타 스키마는 사용하기가 훨씬 쉽고 (더 중요하게는) 다음과 같은 임시 쿼리 도구를 사용하여 성능을 향상시킵니다. 비즈니스 객체 또는 보고서 작성기.개발자는 이러한 도구로 생성된 SQL을 거의 제어할 수 없으므로 쿼리 최적화 프로그램에 가능한 한 많은 도움을 제공해야 합니다.스타 스키마는 쿼리 최적화 프로그램이 잘못될 가능성이 상대적으로 적습니다.

일반적으로 보고 계층은 특별한 이유가 없는 한 스타 스키마를 사용합니다.여러 소스 시스템이 있는 경우 운영 데이터 저장소 정규화된 또는 눈송이 스키마를 사용하여 데이터를 축적합니다.ODS는 일반적으로 기록을 수행하지 않기 때문에 이것이 더 쉽습니다.기록 상태는 정규화된 구조를 사용하는 것보다 훨씬 쉽게 수행할 수 있는 스타 스키마에서 추적됩니다.정규화되거나 눈송이화된 운영 데이터 저장소는 '현재' 상태를 반영하며 데이터에 내재된 어떤 것 이상의 기록 보기를 보유하지 않습니다.

ODS 로드 프로세스는 데이터 스크러빙 및 일치와 관련이 있으며 정규화된 구조를 사용하면 더 쉽게 수행할 수 있습니다.ODS에 깨끗한 데이터가 있으면 차원 및 사실 로드는 일반적이거나 상대적으로 간단한 메커니즘을 사용하여 비교적 간단하게 기록(시간 경과에 따른 변경)을 추적할 수 있습니다.이는 스타 스키마를 사용하는 것이 훨씬 쉽습니다. 예를 들어 많은 ETL 도구는 천천히 변경되는 차원을 위한 내장 기능을 제공하며 일반 메커니즘을 구현하는 것은 비교적 간단합니다.

이러한 방식으로 시스템을 계층화하면 책임이 분리됩니다. 비즈니스 및 데이터 정리 논리는 ODS에서 처리되고 스타 스키마 로드는 기록 상태를 처리합니다.

Answer 2

데이터웨어하우징 문헌에서는 다음과 같은 내용에 대해 지속적인 논쟁이 있습니다. 어디 데이터웨어 하우스 아키텍처에서 스타 스키마 디자인을 적용해야 합니다.

요컨대 킴볼 데이터웨어하우스에서는 스타-스키마 디자인만을 사용하는 것을 매우 높이 평가합니다. 인몬 먼저 다음을 사용하여 Enterprise Datawarehouse를 구축하려고 합니다. 정규화된 3NF 디자인하고 나중에 데이터마트에서 스타-스키마 디자인을 사용합니다.

여기에 덧붙여 다음과 같이 말할 수도 있습니다. 눈송이 스키마 디자인 또 다른 접근 방식입니다.

네 번째 디자인은 다음과 같습니다. 데이터 저장소 모델링 접근하다.

Answer 3

스타 스키마는 대용량 데이터에 고속 액세스를 가능하게 하는 데 사용됩니다.주제 영역에 대해 수행될 수 있는 쿼리를 충족하는 데 필요한 조인 양을 줄임으로써 고성능이 가능해집니다.이는 차원 테이블에서 데이터 중복성을 허용하여 수행됩니다.

스타 스키마는 창고의 최상위 레이어에 대한 패턴이라는 것을 기억해야 합니다.모든 모델에는 웨어하우스 스택 하단의 스테이징 스키마도 포함되며, 일부 모델에는 모든 소스 시스템이 3NF 모델링 스키마로 병합되는 영구적으로 변환된 병합 스테이징 영역도 포함됩니다.다양한 주제 영역이 이 위에 있습니다.

최상위 수준의 별 모양 스키마에 대한 대안에는 눈송이 스키마인 변형이 포함됩니다.일부 조사를 뒷받침할 수 있는 새로운 방법은 다음과 같습니다. 데이터 저장소 모델링 Dan Linstedt가 제안했습니다.

Answer 4

스타 스키마의 장점은 대부분의 사람들이 데이터 웨어하우스에서 수행하려는 작업 종류에 대한 자연스러운 모델이라는 것입니다.예를 들어, 다양한 세부 수준(예: 월, 일, 연도)으로 보고서를 쉽게 생성할 수 있습니다.또한 일반적인 비즈니스 데이터를 데이터 웨어하우스의 공통적이고 중요한 기능인 스타 스키마에 삽입하는 것도 효율적입니다.

원하는 모든 종류의 데이터베이스를 사용할 수 있지만 비즈니스 도메인을 잘 알지 못하면 스타 스키마를 사용한 경우처럼 보고서가 효율적으로 실행되지 않을 가능성이 높습니다.

Answer 5

스타 스키마는 데이터 웨어하우스의 마지막 계층에 적합합니다.거기에 어떻게 가는지는 또 다른 질문입니다.내가 아는 한에는 Bill Inmon과 Ralph Kimball이라는 두 개의 큰 진영이 있습니다.스타와 함께 가기로 결정했다면 이 두 사람의 이론을 살펴보고 싶을 수도 있습니다.

또한 일부 보고 도구는 별 모양 스키마 설정을 정말 좋아합니다.특정 보고 도구에 묶여 있으면 창고에서 보고 마트가 어떻게 보일지 결정할 수 있습니다.

Answer 6

스타 스키마는 일반 데이터 웨어하우징 요구 사항에 맞는 관계형 데이터베이스의 논리적 데이터 모델입니다.관계형 환경이 제공된다면 별 모양이나 눈송이 스키마는 많은 DW 디자인 방법론에 내장된 좋은 디자인 패턴이 될 것입니다.

그러나 관계형 데이터베이스 엔진 외에도 효율적인 데이터 웨어하우징에 사용할 수 있는 다른 엔진도 있습니다.다차원 스토리지 엔진은 OLAP 작업에 매우 빠를 수 있습니다(예: TM1).이 경우 별 모양 스키마 디자인을 적용할 수 없습니다.특별한 논리 모델이 필요한 다른 예로는 XML 데이터베이스 또는 열 기반 데이터베이스(예:실험적인 C스토어)).

Answer 7

없이도 가능합니다.그러나 당신은 자신의 삶을 힘들게 만들 것입니다. 조직은 DW 위에 존재하는 표준 도구를 사용하기를 원할 것이며 이러한 도구는 별 모양 스키마를 기대할 것입니다. 라운드에 사각형 말뚝을 맞추는 데 많은 노력이 소요될 것입니다. 구멍.

많은 데이터베이스 수준 최적화에서는 스타 스키마가 있다고 가정합니다.별로 좋지 않은 레이아웃으로 DB가 "올바른 작업"을 수행하도록 최적화하고 재구성하는 데 많은 시간을 소비하게 됩니다.

장점이 단점보다 더 크다는 것을 확인하세요..

(내가 전에 거기에 가본 적이 있는 것 같나요?)

-디

Answer 8

우리가 해결해야 할 세 가지 문제가 있습니다.

1) 테이블 내부 및 테이블 간 조인, 추출 시 데이터 정리, 파생물 생성 등을 통해 데이터에 과도한 압력을 가하지 않고 운영 소스 시스템에서 데이터를 가져오는 방법.

2) 서로 다른 소스(다른 부서의 일부 레거시, 일부 파일 기반)의 데이터를 비즈니스를 모델링하고 소스 시스템의 구조를 반영하지 않는 통합적이고 정확하며 효율적으로 저장된 전체로 병합하는 방법.시스템은 상대적으로 빠르게 변경/교체되지만 비즈니스의 기본 모델은 느리게 변경된다는 점을 기억하세요.

3) 비즈니스의 특정 인력/부서에 대한 특정 분석 및 보고 요구 사항을 최대한 빠르고 정확하게 충족하도록 데이터를 구성하는 방법.

매우 다른 세 가지 문제를 해결하려면 이를 해결하기 위해 서로 다른 아키텍처 계층이 필요합니다.

스테이징 층 우리는 소스의 구조를 복제하지만 소스에서 데이터 만 변경하면 매일 밤로드됩니다.데이터가 스테이징 레이어에서 다음 레이어로 이동되면 데이터가 삭제됩니다.쿼리는 간단한 data_time 필터를 사용하는 단일 테이블 쿼리입니다.소스에 미치는 영향은 거의 없습니다.

엔터프라이즈 계층 이것은 비즈니스 지향적 인 3 차 일반 양식 데이터베이스입니다.데이터는 스테이징 계층에서 엔터프라이즈 계층으로 추출된 후 삭제되어 정리, 통합 및 정규화됩니다.

프리젠 테이션 (Star Schema) 계층은 여기에 특정 요구 사항을 충족하기 위해 차원으로 모델링합니다.데이터는 조인 수를 줄이기 위해 의도적으로 비정규화됩니다.엔터프라이즈 계층에서 여러 테이블을 차지할 수 있는 계층은 단일 차원 테이블로 축소되고 여러 트랜잭션 테이블은 단일 팩트 테이블로 병합될 수 있습니다.

당신은 항상 이 세 가지 문제에 직면합니다.엔터프라이즈 계층을 없애기로 결정했다면 여전히 두 번째 문제를 해결해야 하지만 스타 스키마 계층에서 이를 해결해야 하는데, 내 생각에는 여기가 잘못된 위치인 것 같습니다.