데이터웨어 하우스에서 다 대다 관계를 구현하는 몇 가지 방법은 무엇입니까?

데이터웨어 하우스 모델링 (Star, Snowflake)의 주요 토폴로지는 일대 다 관계를 염두에두고 설계되었습니다. 이러한 모델링 체계에서 다 대다 관계에 직면하면 쿼리 가독성, 성능 및 구조가 심각하게 저하됩니다.

데이터웨어 하우스에서 차원 간 또는 팩트 테이블과 차원간에 다 대다 관계를 구현하는 방법에는 무엇이 있으며 필요한 세분성 및 쿼리 성능과 관련하여 어떤 타협이 발생합니까?

내 경험상 재귀 계층은 이것을 다루는 가장 실용적인 방법입니다. 다음과 같은 장점이 있습니다.

1. 무제한 깊이.
2. 컴팩트 함.
3. 적응성.
4. 속도.

반대로 각 수준의 "대다"조인마다 추가 테이블이 필요합니다. 이것은 하드 코딩되어 스키마 업데이트에 대해 유지 관리하기가 어렵습니다.

필터링 된 인덱스를 사용하면 큰 계층 적 조인 테이블이 전용 테이블보다 뛰어난 속도로 수행 될 수 있습니다. 그 이유는 각 조인이 "테이블을 데이터 테이블에 조인"하는 것과 비교하여 "부모 자식"이기 때문입니다. 후자는 처리하고 저장할 인덱스가 더 많습니다.

나는 수년 동안이 문제를 해결하려고 노력해 왔습니다. 최근에 이것이 내가 생각해 낸 것입니다.

데이터웨어 하우스 모델에서 M : M 관계에 대한 일부 시나리오

대부분의 OLAP 서버 및 ROLAP 시스템에는 현재 M : M 데이터 구조를 처리 할 수있는 방법이 있지만 이에주의해야 할 몇 가지주의 사항이 있습니다. M : M 관계를 구현하는 경우보고 계층과 지원하려는 도구를 주시해야합니다.

시나리오 1 : 팩트 테이블에 대한 M : M 차원

모터 정책에 여러 드라이버가있을 수 있습니다. 드라이버를 추가하거나 제거하면 정책 조정 트랜잭션이 조정에 따라 변경되는 드라이버 목록과 관계가있을 수 있습니다.

옵션 1-M : M driver-fact 브리지 테이블 지정된 정책에 대해 드라이버 x 트랜잭션 행이 있으므로 상당히 많은 양의 데이터가 있습니다. SSAS는이 데이터 구조를 직접 사용할 수 있지만 ROLAP 도구를 통한 쿼리 속도가 느립니다.

M : M 관계가 팩트 행과 관련된 엔티티 (예 : 자동차 운전자)를 기반으로하는 경우 ROLAP 도구에도 적합 할 수 있습니다. ROLAP 도구가 M : M 관계를 지원하는 경우 (예 : 비즈니스의 컨텍스트 사용) 사물).

옵션 2-더미 '조합'차원 테이블 공통 코드 목록을 팩트 테이블에 맵핑하는 경우 (즉, 연결된 엔티티가 팩트 행에 고유하지 않은 경우) 데이터 볼륨을 줄이는 다른 방법을 사용할 수 있습니다. 이 유형의 시나리오의 예는 입원 환자 방문의 ICD 코드입니다. 각 입원 환자 방문에는 하나 이상의 ICD 진단 및 / 또는 절차가 나와 있습니다. ICD 코드는 글로벌 코드입니다.

이 경우 각 사례에서 코드 조합의 고유 목록을 구성 할 수 있습니다. 각 개별 조합에 대해 하나의 행으로 차원 테이블을 작성하고 ICD 코드 자체에 대한 조합과 참조 테이블 사이에 링크 테이블을 작성하십시오.

팩트 테이블에는 '조합'차원에 대한 차원 키가있을 수 있으며 차원 행에는 실제 ICD 코드에 대한 참조 목록이 있습니다. 대부분의 ROLAP 도구는이 데이터 구조를 사용할 수 있습니다. 도구가 실제 M : M 관계에서만 작동하는 경우 팩트와 코딩 참조 테이블 간의 M : M 관계를 에뮬레이트하는보기를 작성할 수 있습니다. 이것은 SSAS에서 선호되는 접근 방식입니다.

옵션 1의 장점 : -M : M 테이블을 통해 특정 관계가있는 팩트 테이블 행을 선택하는 것을 기반으로하는 적절하게 인덱스 된 쿼리가 상당히 효율적일 수 있습니다.

• 약간 더 간단한 개념적 모델

옵션 2의 장점 : -데이터 스토리지가 더 컴팩트합니다

• 조합을 사람이 읽을 수있는 형식으로 '콤비네이션'차원의 코드로 표시하여 직선 1 : M 관계를 에뮬레이션 할 수 있습니다. 이는 M : M 관계에 대한 지원이없는 멍청한보고 도구에서 더 유용 할 수 있습니다.

시나리오 2 : 차원 간의 M : M 관계 :

유스 케이스를 생각하기는 어렵지만 ICD 코드를 사용하여 건강 관리에서 무언가를 상상할 수 있습니다. 비용 분석 시스템에서 입원 환자 방문은 차원이 될 수 있으며 방문 (또는 NHS- 말하기의 컨설턴트-에피소드)과 코딩 사이에 M : M 관계를 갖습니다.

이 경우 M : M 관계를 설정하고 기본 차원에서 사람이 읽을 수있는 렌더링을 체계화 할 수 있습니다. 관계는 직선 M : M 링크 테이블 또는 전과 같이 브리징 '조합'테이블을 통해 수행 할 수 있습니다. 이 데이터 구조는 Business Objects 또는보다 우수한 품질의 ROLAP 도구를 통해 올바르게 쿼리 할 수 ​​있습니다.

내 머리 꼭대기에서, SSAS가 팩트 테이블과의 관계를 바로 잡지 않고 이것을 소비 할 수 없다는 것을 알 수 없으므로 코딩과 팩트 테이블 사이의 M : M 관계에 대한 견해를 제시해야합니다 이 데이터에 SSAS를 사용하는 행.

트랜잭션 시스템이나 현재 데이터 모델과 같이 모델에서 어떤 종류의 다 대다 관계를 염두에두고 있는지 정확히 알고 싶습니다.

일반적으로 차원 간의 다 대다 관계는 차원에 대한 사실입니다. 고객이 여러 고객에게 서비스를 제공하는 여러 지사에서 주문한다는 사실. 그 각각은 사실입니다. 그것은 효과적인 날짜 또는 그와 비슷한 것을 가질 것이지만, 관계는 "사실"일 수 있습니다. 관계 자체는 고객 및 지사 외에 다른 차원을 가질 수 있습니다. 따라서 중심에 (실제로 사실이 아닌) 팩트 테이블이있는 일반적인 스타 스키마입니다. 이 별이 창고의 다른 차원 별들과 어떻게 관련 될 수 있는지는 분명히 달려 있습니다. 다른 별을 결합 할 때마다 비즈니스 키를 사용하여 실수로 교차 조인을 수행하지 않도록해야합니다.

일반적으로 이러한 차원 관계 테이블은 더 큰 팩트 테이블과 같은 정도로보고하지 않으며, 그렇게 할 때 항상 많은 양의 데이터는 아니므로 성능에 영향을 미치지 않는 경향이 있습니다. 위의 경우 시간이 지남에 따라 고객 / 지점 활용도를 볼 수 있지만 실제 주문 수량에 대한 더 나은 데이터는 주문 팩트 테이블에서 사용 가능하며, 이는 아마도 고객, 지사 등의 차원도있을 수 있습니다. 대부분의 사람들은 다대 다를 고려할 것이지만 (고객에서 지점까지 다 대다 관계를 정의하기 위해 주문을 고려할 수 있지만) 데이터웨어 하우스 환경에서 더 일반적입니다. 해당 관계 수준 (예 : 고객, 지점, 월)에 요약 정보를 롤업 한 경우 다 대다 모델에 대해서만 숫자 집계를 수행 할 수 있습니다.

다음은 Kimball의 일부 관련 기사와 주어진 다 대다 관계 모델링에 적용될 수있는 기사입니다. 다 대다 관계는 문제 영역 / 논리 모델에서만 개념입니다. 정규화 된 OLTP 모델에서는 링크 테이블을 사용하여 처리 할 수있을 것입니다. 링크 테이블은 물론 각 방법마다 하나씩입니다. 정규화되지 않은 Kimball 데이터웨어 하우스 모델에는이를 수행하는 여러 가지 방법이 있으며, 그 중 하나는 기본적으로 해당 연결 테이블을 별의 중심에있는 사실로 취급합니다. 다른 하나는 플래그 열의 배열입니다.

궁극적으로 선택은 정확히 모델링하는 것, 변경 방법 및보고 방법에 따라 달라집니다. 차원 모델링과 데이터웨어 하우징이 일반적으로 표준화 된 모델과 크게 다른 곳입니다. 표준화 된 모델은 데이터의 논리적 및 이론적 관계에 중점을 둡니다. 데이터웨어 하우징은 항상 실제 사용 사례를 주시하고 비정규 화하여이를 수행합니다.

브릿지 테이블을 사용하여 대체 계층 구조 모델링 :

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

다 대다 관계에 대한 세 가지 옵션 (숫자 공유 할당과 연결됨-흥미로운 부분에 대한 주석 참조)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

불행히도 많은 Kimball 's Information Week / DBMS 잡지 기사에는 더 이상 좋은 링크가 없습니다 ...

이 문제를 해결할 수있는 한 가지 방법은 팩트 테이블에 2 개의 열이 있고 2 차원의 외래 키는 다 대다 관계 선박을 갖는 것입니다.