2

스타 스키마를 사용하여 데이터웨어 하우스를 만들고 있습니다. 모든 차원 테이블을 성공적으로 작성했지만 필자는 사실 테이블에 머물러 있습니다. Sales 테이블을 Fact 테이블로 만들 필요가 있습니다. SalesKey, OrderKey, ProductKey 등이 있습니다 ... 모든 주문은 판매이므로 각 주문에는 고유 한 SalesKey가 있지만 각 판매에는 하나 이상의 제품이 있습니다.데이터웨어 하우스 만들기

이 테이블을 만드는 것이 최선의 방법은 무엇입니까? 사실과 차원 사이의 M 관계 : 당신이 각 차원 (즉 1을 가진 각 사실 레코드에 대해 평가 한 것이 바람직하다을 스타 스키마를 설계 할 때

나는 일반적으로 그

SalesKey OrderKey ProductKey 
-------- -------- ---------- 
s1   o1  p1 
s1   o1  p2 
s2   o2  p1 

답변

2

같은 무언가를 창조해야).

트릭은 ORDER-LINE 차원을 포함하여 1 주문 (= 1 판매)에 많은 주문 라인이 포함될 수 있도록하는 것입니다. 각 주문 라인에는 1 개의 제품이 들어 있습니다.

기본적으로 팩트 테이블이 1 : M 관계의 ORDER-LINE 차원에 연결되는 눈송이 스키마를 사용하게됩니다. ORDER-LINE 차원은 M : 1 관계에있는 PRODUCT 차원에 연결됩니다.

Salesfact과 PRODUCT 차원 사이에 M : M 관계가있는 원래의 문제는 ORDER-LINE 차원을 브리지 테이블로 사용하여 해결되었습니다.

2

주문 항목/라인을 추가하는 것이 까다로울 수 있습니다. 여러 가지 방법으로 처리 할 수 ​​있습니다.

"주문 라인 항목"또는 "트랜잭션 제어 ID"열을 팩트 테이블에 추가하십시오.

이렇게하면 "OrderLineItem"축약 된 차원 키 (종종 소스 시스템의 거래 제어 번호 또는 주문 번호)를 사용하여 SalesKey, OrderKey, ProductKey를 모두 사용할 수 있습니다.

이 방법을 사용할 때 발생할 수있는 한 가지 문제는 주문 행 아웃 (세금, 계산원 아이디 등)에 주문 수준 측정 값이 없을 때입니다. Kimball이 선호하는 접근 방법은 가능하다면 이러한 조치들을 주문 라인에 배포하는 것입니다. http://www.kimballgroup.com/html/designtipsPDF/DesignTips2003/KimballDT46AnotherLook.pdf

:

여기 타락한 차원에서 킴볼 좋은 기사입니다

관련 문제