4

저는 스타 스키마를 모델링하는 데있어 새로운데, 신선한 것은 Data Warehouse Toolkit입니다.스타 스키마 : 클라이언트 및 비 클라이언트에 대한 분리 된 차원 또는 교환 원에 대한 공유 차원?

고객 및 비 고객이 일부 직원과 전화 회의 통화를 요청하는 비즈니스 프로세스가 있습니다.

"잠재 고객"이라고하는 사실 테이블에는 참석자가 통화에 연결된 기간 및 통화에 대한이 사람의 연결 비용이 포함됩니다. 곡물은 "전화 회의 개별 연결"입니다.

나는 나의 일치 된 클라이언트 차원을 사용하고 (이 질문의 일부가 아닌 차원 생략) 이런 식으로 (아직 클라이언트가 아닌 호출자)가 아닌 클라이언트 차원을 만들어야합니다

First potential model http://i50.tinypic.com/1416xr7.png

아니면 괜찮을 것은/더 나은이 방법으로 확인 된 클라이언트 차원에 관련된 비 확인 된 참석 차원이하기 :

Second potential model http://i47.tinypic.com/2ccm9tg.png

을 또는 더 나은/s의이 이 같은 비즈니스 프로세스를 모델링하는 표준 메커니즘?

편집 :

무엇 위의 모델 2를 사용하지만, 클라이언트 차원 테이블 위에 뷰를 작성하고 참석 차원이 단지 하나의 차원처럼 보이게 약?

아래의 Damir의 답변에 대한 대안이 있습니까?

+0

비용 (회사) 비용 또는 각 사람이 별도로 지불하는 비용은 있습니까? –

+0

cost_of_connection은 각 발신자가 연결될 수 있도록 내 회사가 지불하는 금액입니다. 그것은 우리에게 드는 비용입니다. – cethegeek

답변

3

두 개의 테이블 (차원)으로 클라이언트를 분할 할 필요가 없습니다. 모든 고객, 활성 고객 및 잠재 고객을 동일한 차원 테이블에 넣기 만하면됩니다. 지불 고객과 잠재 고객을 구별하기 위해 IsActive 특성 (열)을 도입 할 수 있습니다. 머지 않아 데이터 마이닝 도구를 사용하여 고객에 대해 자세히 알아보고 그렇지 않은 사람들과 서비스 비용을 지불하려는 사람들을 구별합니다. 알고리즘이 작동하려면 지불하는 사람과 지불하지 않는 사람 모두에게 데이터를 제공해야합니다. 요약하면 잠재 고객은 유료 고객과 동일한 테이블에 속합니다.

이렇게하면 모델 번호 1을 사용할 수 있습니다. 사실 테이블의 측정 값이 올바른지 확인하십시오. 10 배 실제 비용처럼 - 예를 들어, call_id 경우 = 123 (10) 사람들이 전화하지 의미가 무엇인가의 총 비용을 반환해야 다음,

sum(cost_of_connection) 
from factAudience 
where call_id = 123; 

참여했다. dimClient을 -

편집

A "지불 클라이언트"와 "잠재 고객"그러므로 동일한 차원 테이블에 속하는 두 클라이언트의 유형입니다. DW의 어딘가에 dimSale에 FK를 가진 사실 (또는 유사)이 있습니다. 지불 및 잠재 고객을 구별하기 위해 dimClient에 열이 없더라도 factClient 및 dimClient에 가입하여 유료 고객을 확보 할 수 있습니다.

"고객이 누구입니까?" DW를 조직에 도입 할 때 흔히 발생하는 논쟁입니다. 고객 획득, 보존, 전환 등을 분석 할 수 있으려면 잠재 고객은 적어도 DW에서 지불 고객과 동일한 대우를받습니다. 신규 고객 확보 및 창출은 거의 모든 CEO의 목록 상단에 있습니다.

+0

ETL 계층을 사용하여 준수 된 클라이언트 차원과 전화 회의 참석자 목록을 병합하는 새로운 차원을 만드는 것이 좋습니다. 내 규정 준수 클라이언트 차원이 천천히 변화하는 차원이기 때문에 복잡성이 많이 발생하지 않습니까? 이제는 운영 데이터로 최신의 클라이언트 차원을 유지해야합니다. 이 새로운 차원도 ... – cethegeek

+0

내 질문에 편집보기. 그것이 모델링면에서 수용 가능한 타협입니까? – cethegeek

+0

나는 당신의 대답을 받아 들일 것입니다. (제 편집에 대한 답변을 기다리고 싶지만 현상금에 1 시간 남았습니다. 그리고 가장 좋은 답변이 신용을 얻고 싶습니다.) 당신이 마음에 들지 않는다면 나는 여전히 여분의 차원에 대한 장단점과 2 차원의 관점에 대한 토론을하고 싶습니다. – cethegeek

0

약간의 차이가 있습니다. 두 번째 버전이 더 정확할 수도 있지만 olap 시스템이이를 지원합니까?

2

저는 두 번째로 갈 것입니다 : 자신의 전용 차원에서 참석자를 모델링하는 한편, 클라이언트 차원 (또는 다른 방법으로)을 해당 차원의 특성을 통해 공개 할 수있게 해주는 것입니다. 그러면 원하는 방식 일 것입니다. ("모든 참석자를 보여주세요"다음에 "고객이 누구인지"에 이어 실제 삶을 자세히 살펴보십시오.)

클라이언트 차원에서 나는 참석자가 클라이언트가 아닌 "알 수없는"요소와 일치하는 모든 참석자에 대해 client_id를 채 웁니다.

여기에 대한 좋은 논의가있다 :

http://crpit.com/confpapers/CRPITV75Riazati.pdf

0

두 번째는 나에게 "눈송이 스키마"처럼 보인다. 위키 백과 문서에서 시작하여 눈송이 스키마를 살펴보십시오. 별과 눈송이 사이의 몇 가지 비교를 볼 수 있습니다.

+0

그것이 제가 질문을 올린 이유입니다. 그러나 그렇지 않으면 불가능한 드릴 다운 동작을 허용합니다. – cethegeek