스타-스키마 디자인

스타-스키마 디자인

---

Star-Schema 설계가 데이터웨어 하우스에 필수적입니까? 아니면 다른 디자인 패턴으로 데이터웨어 하우징을 수행 할 수 있습니까?

---

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

데이터웨어 하우스 아키텍처의 미묘한 부분을 다루거나 Kimball 대 Inmon 화염 전쟁을 시작하지 않고 스타 스키마의 주요 이점은 다음과 같습니다.

• 대부분의 데이터베이스 관리 시스템에는 빠른 술어 확인 을 위해 비트 맵 인덱스 구조 또는 인덱스 교차 를 사용하는 '스타 변환'을 수행하는 쿼리 최적화 프로그램 기능이 있습니다 . 즉, 선택이 해결 될 때까지 팩트 테이블 (일반적으로 인덱스보다 훨씬 큼)을 누르지 않고도 스타 스키마에서 선택을 수행 할 수 있습니다.

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

• 느리게 변경되는 차원 은 눈송이보다 스타 스키마에서 구현하기가 훨씬 쉽습니다.

• 스키마는 이해하기 쉽고 눈송이 또는 ER 스키마 보다 조인이 적습니다 . 당신의보고 팀이 당신을 사랑할 것입니다.

• 스타 스키마는 사용하기가 훨씬 쉽고 (더 중요한 것은) Business Objects 또는 Report Builder 와 같은 임시 쿼리 도구를 사용하여 성능을 향상 시킵니다. 개발자는 이러한 도구에 의해 생성 된 SQL을 거의 제어 할 수 없으므로 쿼리 최적화 프로그램에 최대한 많은 도움을 제공해야합니다. 스타 스키마는 쿼리 옵티 마이저에게 오류가 발생할 가능성이 비교적 적습니다.

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

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

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

---

데이터웨어 하우스 아키텍처에서 Star-Schema 디자인을 적용해야하는 위치 에 대한 데이터웨어 하우징 자료에 대한 지속적인 논쟁 이 있습니다.

간단히 말해서 Kimball 은 데이터 웨어 하우스 에서 Star-Schema 디자인 만 사용하는 것을 매우 강력하게지지하는 반면 Inmon은 먼저 정규화 된 3NF 디자인을 사용하여 엔터프라이즈 데이터웨어 하우스를 구축 하고 나중에 데이터 마트에서 Star-Schema 디자인을 사용 하려고 합니다.

여기에 추가로 Snowflake 스키마 디자인 이 또 다른 접근 방식 이라고 말할 수 있습니다 .

네 번째 디자인은 데이터 볼트 모델링 접근 방식 일 수 있습니다 .

---

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

스타 스키마는웨어 하우스의 최상위 레이어에 대한 패턴이라는 것을 기억해야합니다. 모든 모델은 또한웨어 하우스 스택의 맨 아래에 스테이징 스키마를 포함하며 일부는 모든 소스 시스템이 3NF 모델링 된 스키마로 병합되는 지속 형 변환 병합 스테이징 영역도 포함합니다. 다양한 주제 영역이이 위에 있습니다.

최상위 수준의 별표 스키마에 대한 대안에는 눈송이 스키마 인 변형이 포함됩니다. 일부 조사를 견딜 수있는 새로운 방법은 Dan Linstedt가 제안한 데이터 볼트 모델링 입니다.

---

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

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

---

스타 스키마는 데이터웨어 하우스의 마지막 계층에 자연스럽게 적합합니다. 거기에 도달하는 방법은 또 다른 질문입니다. 내가 아는 한, Bill Inmon과 Ralph Kimball의 두 개의 큰 캠프가 있습니다. 별과 함께 가기로 결정했다면이 두 사람의 이론을보고 싶을 것입니다.

또한 일부보고 도구는 스타 스키마 설정을 정말 좋아합니다. 특정보고 도구에 갇혀있는 경우 창고에서보고 마트가 어떻게 생겼는지 확인할 수 있습니다.

---

스타 스키마는 일반적인 데이터웨어 하우징 요구에 맞는 관계형 데이터베이스를위한 논리적 데이터 모델입니다. 관계형 환경이 주어지면 별 모양 또는 눈송이 스키마가 좋은 디자인 패턴이 될 것이며 많은 DW 디자인 방법론에 고정되어 있습니다.

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

---

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

많은 데이터베이스 수준 최적화에서는 스타 스키마가 있다고 가정합니다. DB가 별이 아닌 레이아웃으로 "올바른 작업"을 수행하도록하기 위해 최적화 및 구조 조정에 많은 시간을 할애 할 것입니다.

장점이 단점보다 중요한지 확인하십시오 ..

(이전에 거기에 가본 것처럼 들리나요?)

-디

---

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

1) 내부와 사이에 테이블을 조인하고, 추출 할 때 데이터를 정리하고, 파생물을 생성하는 등 과도한 부담없이 운영 소스 시스템에서 데이터를 가져 오는 방법

2) How to merge data from disparate sources - some legacy, some file based, from different departments into an integral, accurate, efficiently stored whole that models the business, and does not reflect the structures of the source systems. Remember, systems change / are replaced relatively quickly, but the basic model of the business changes slowly.

3) How to structure the data to meet specific analytical and reporting requirements for particular people/departments in the business as quickly and accurately as possible.

The solution to these three very different problems require different architectural layers to solve them

Staging Layer We replicate the structures of the sources, but only changed data from the sources are loaded each night. once the data is taken from the staging layer into the next layer, the data is dropped. Queries are single table queries with a simple data_time filter. Very little effect on the source.

Enterprise Layer This is a business oriented 3rd normal form database. Data is extracted (and afterward dropped) from the staging layer into the enterprise layer, where it is cleaned, integrated and normalised.

Presentation (Star Schema) Layer Here, we model dimensionally to meet specific requirements. Data is deliberately de-normalise to reduce the number of joins. Hierarchies that may occupy several tables in the Enterprise Layer are collapsed into a single dimension tables, and multiple transactional tables may be merged into single fact tables.

You always face these three problems. If you choose to do away with the enterprise layer, you still have to solve the second problem, but you have to do it in the star schema layer, and in my view, this is the wrong place to do it.

참고URL : https://stackoverflow.com/questions/110032/star-schema-design