스타 스키마 디자인

Question

스타 스키마 디자인은 데이터웨어 하우스에 필수적입니까? 또는 다른 디자인 패턴으로 데이터웨어 하우징을 수행 할 수 있습니까?

Answer 1

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

데이터웨어 하우스 아키텍처의 subtlties에 가거나 킴볼 Inmon 대 불꽃 전쟁을 스타 스키마의 주요 이점을 시작하지 않고

은 다음과 같습니다 쿼리 최적화 의 시설을 갖추고

• 대부분의 데이터베이스 관리 시스템 Bitmap Index 구조를 사용하거나 조건부 해상도의 경우 을 사용하는 '별 변환'을 수행하십시오. 즉, 선택 사항이 해결 될 때까지 사실 테이블 (보통 인덱스보다 훨씬 큽니다)을 치지 않고도 스타 스키마에서 선택을 수행 할 수 있습니다.

• Partitioning 별표 스키마는 사실 테이블 만 분할해야하므로 비교적 간단합니다 (성경적으로 큰 차원이없는 경우).Partition elimination은 쿼리 최적화 프로그램이 쿼리 결과에 참여할 가능성이없는 패시브를 무시할 수 있음을 의미하므로 I/O가 절약됩니다.

• Slowly changing dimensions은 눈송이보다 별표 스키마에서 구현하는 것이 훨씬 쉽습니다.

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

• 스타 스키마는 사용하기가 훨씬 쉬우 며 (더 중요한 것은) Business Objects 또는 Report Builder과 같은 임의 (ad-hoc) 쿼리 도구로 잘 수행 할 수 있습니다. 개발자는 이러한 도구로 생성 된 SQL을 거의 제어 할 수 없으므로 가능한 한 많은 쿼리 최적화 프로그램을 제공해야합니다. 스타 스키마는 쿼리 최적화 프로그램이이를 잘못 처리 할 수있는 기회를 상대적으로 거의 제공하지 않습니다.

일반적으로 사용하지 않는 구체적인 이유가없는 한 일반적으로보고 계층은 별표 스키마를 사용합니다. 원본 시스템이 여러 개인 경우 Operational Data Store을 정규화 된 스키마 또는 눈송이 스키마와 함께 구현하여 데이터를 누적 할 수 있습니다. ODS는 일반적으로 히스토리를 작성하지 않기 때문에 더 쉽습니다. 역사 상태는 정규화 된 구조보다 훨씬 쉽게 수행 할 수있는 스타 스키마에서 추적됩니다. 표준화 또는 눈 깜짝 놀란 운영 데이터 저장소는 '현재'상태를 반영하며 데이터에 내재되어있는 모든 것 이상의 과거 기록을 보유하지 않습니다.

ODS로드 프로세스는 데이터 스크러빙 및 적합성과 관련이 있으며 정규화 된 구조로 수행하는 것이 더 쉽습니다. ODS에서 데이터를 정리하면 차원 및 팩트로드는 제네릭 또는 상대적으로 간단한 메커니즘을 사용하여 히스토리 (시간 경과에 따른 변경 사항)를 비교적 간단하게 추적 할 수 있습니다. 스타 스키마로 수행하는 것이 훨씬 쉽습니다. 예를 들어 많은 ETL 도구는 천천히 변화하는 차원을위한 기본 제공 기능을 제공하고 일반적인 메커니즘을 구현하는 것은 비교적 간단합니다.

이러한 방식으로 시스템을 계층화하면 비즈니스와 데이터 정리 논리가 ODS에서 처리되고 스타 스키마가 이전 상태를 처리하게됩니다.

Answer 2

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

원하는 데이터베이스를 사용할 수는 있지만 비즈니스 도메인을 잘 알지 못하면 별표 스키마를 사용하는 경우 보고서가 효율적으로 실행되지 않을 수 있습니다.

Answer 3

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

스타 스키마는웨어 하우스의 최상위 계층에 대한 패턴임을 기억해야합니다. 모든 모델에는웨어 하우스 스택의 맨 아래에 스테이징 스키마가 포함되어 있으며 일부에는 모든 원본 시스템이 3NF 모델 스키마로 병합되는 병합 된 변환 병합 스테이지 영역이 포함됩니다. 다양한 주제 영역이이 위에 있습니다.

최상위 레벨에서 별표 스키마의 대안으로는 변형, 즉 눈송이 스키마가 있습니다. 약간 조사를 또한 참을지도 모른다 새로운 방법은 Dan Linstedt가 제시 한 Data Vault Modelling이다.

Answer 4

스타 스키마는 데이터웨어 하우스의 마지막 계층에 적합합니다. 어떻게 거기에 도착하는지 또 다른 질문입니다. 내가 아는 한 빌 인 몬 (Bill Inmon)과 랄프 킴볼 (Ralph Kimball)이라는 두 개의 큰 캠프가 있습니다. 당신은 별을 가지고 가기로 결정할 때 /이 두 사람의 이론을 보길 원할 것입니다.

또한 일부보고 도구는 스타 스키마 설정을 정말로 좋아합니다. 특정보고 도구에 갇혀 있으면보고 마트가 창고에서 어떻게 보이는지 파악할 수 있습니다.

Answer 5

하지 않아도됩니다. 그러나 조직은 일상 생활에서 열심히 노력할 것입니다. 조직에서 DW를 기반으로하는 표준 도구를 사용하기를 원할 것입니다.이 도구는 스타 스키마를 기대합니다. 라운드에서 사각형 펙을 맞추기 위해 많은 노력을 기울일 것입니다. 구멍.

많은 데이터베이스 수준 최적화에서는 스타 스키마가 있다고 가정합니다. 당신은 당신의 not-quite-star 레이아웃으로 "옳은 일을"하도록 DB를 얻으려면 많은 시간을 최적화하고 재구성해야 할 것입니다.

장점이 단점보다 중요한 있는지 확인합니다 ..

이 (내가 전에 거기에 있었던 것처럼 소리를합니까?)

-D

Answer 6

스타 스키마 관계에 대한 논리적 데이터 모델입니다 정기적 인 데이터웨어 하우징 요구 사항에 적합한 데이터베이스 관계 환경이 주어지면 스타 또는 스노우 플레이크 스키마가 DW 디자인 방법론에서 많은 유선으로 연결되는 좋은 디자인 패턴이 될 것입니다.

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

Answer 7

에 대한 데이터웨어 하우스 아키텍처에서이 Star-Schema 디자인이 적용되어야 ● 데이터웨어 하우스의 litterature에서 계속 논쟁이되고있다. 첫째 Inmon가 normalized 3NF 디자인을 사용하여 엔터프라이즈 데이터웨어 하우스를 구축하고 나중에 마트에서 스타 스키마 디자인을 사용하고자하는 동안 매우 높은 데이터웨어 하우스 만 스타 - 스키마 디자인을 사용하여 짧은 Kimball 지지자에서

.

여기에 덧붙여서 Snowflake schema design은 또 다른 접근 방법이라고 할 수 있습니다.

네 번째 디자인은 Data Vault Modeling 접근 방식 일 수 있습니다.

Answer 8

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

2) 어떻게 병합하는 우리가 추출로 데이터를 청소, 내부와 그들 사이의 테이블을 조인하여 그들에 과도한 압력을주지 않고 운영 소스 시스템에서 데이터를 얻을하는 방법

1), 생성 유도 서로 다른 부서의 일부 레거시, 일부 파일 기반, 다른 부서의 데이터를 비즈니스를 모델링하고 소스 시스템의 구조를 반영하지 않는 필수적이고 정확하며 효율적으로 저장되는 일부 데이터. 시스템 변경/교체 속도가 비교적 빠르지 만 비즈니스의 기본 모델은 천천히 변합니다.

3) 가능한 한 신속하고 정확하게 비즈니스의 특정 인물/부서에 대한 특정 분석 및보고 요구 사항을 충족시키기 위해 데이터를 구성하는 방법.

이 세 가지 매우 다른 문제에 대한 해결책은 우리가 소스의 구조를 복제 그들에게

준비 레이어 를 해결하기 위해 서로 다른 아키텍처 레이어를 필요로하지만 매일 밤로드 된 소스에서 데이터를 변경했습니다. 스테이징 계층에서 다음 계층으로 데이터를 가져 오면 데이터가 삭제됩니다. 쿼리는 간단한 data_time 필터를 사용하는 단일 테이블 쿼리입니다. 소스에 미치는 영향은 거의 없습니다.

엔터프라이즈 레이어 이것은 비즈니스 지향 3 정규형 데이터베이스입니다. 스테이징 계층에서 엔터프라이즈 계층으로 데이터가 추출 된 후 삭제됩니다. 여기서 엔터프라이즈 계층은 정리되고 통합되고 표준화됩니다.

프레젠테이션 (스타 스키마) 레이어 여기서 특정 요구 사항을 충족시키기 위해 차원 적으로 모델을 만듭니다. 조인 수를 줄이려면 의도적으로 데이터가 비정규 화됩니다. 엔터프라이즈 계층에서 여러 테이블을 차지할 수있는 계층 구조는 단일 차원 테이블로 축소되며 여러 트랜잭션 테이블이 단일 팩트 테이블로 병합 될 수 있습니다.

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