나는 약 10 개의 외래 키를 포함하는 하나의 주 팩트 테이블을 가지고있다. 이제는 N : 1 관계가있는 다른 4 개의 팩트 테이블이 주 팩트 테이블에 연결됩니다. 질문은이 4 개의 팩트 테이블에 외래 키를 모두 복사해야합니까? 아니면 SSAS 큐브 처리 중에 주 팩트 테이블에 런타임을 결합해야합니까?주요 사실 테이블의 모든 외래 키를 다른 관련 테이블로 복사해야합니까?
장단점은 무엇입니까?
나는 의견에 linebreak를 추가 할 수 없습니다. 그래서 여기에 의견을 남깁니다.
메인 팩트 표
FactTable (PKEY, FKey1, FKey2, FKey3, FKey4, 값) 인
FactTable1 (PKEY, FactTable.PKey, ErrorCounter)
FactTable2 (PKEY, FactTable.PKey 같은 종래 사실 테이블
FactTable1 (PKEY, FactTable.PKey, FactTable.FKey1, FactTable.FKey2, FactTable.FKey3, FactTable.FKey4, ErrorCounter)
문제는이 같은 구조화 FactTable1 또는 FactTable2 변경해야한다
어떤 이유로 모든 것을 하나의 사실 테이블에 넣으시겠습니까? 그들은 SSAS를 측정/그룹으로 어떻게 관련 지을 수 있습니다.
현재 성능 문제가 있습니까? 큐브가 별도의 테이블에있을 때 큐브를 처리하는 데 5 초 이상이 소요되고 하나의 테이블에 모든 큐브를로드하는 데 5 분의 ETL이 소요된다면 그대로 유지하는 것이 현명합니다. 다른 방법이라면 하나의 팩트 테이블에 모든 것을 넣는 것이 좋습니다.
Dim과 Fact 사이의 관계로 SSAS에서 큐브를 모델링하는 방법이 테이블이 관계형 데이터베이스에서 서로 관련되는 것과 반드시 같을 필요는 없습니다.
제 큐브 모델에서 모든 사실은 모든 dim에 대해 정기적 인 관계를 유지합니다.그래서 내 현재 관계형 데이터베이스 스키마에서, 나는 각각의 관련된 팩트 테이블에 대한 뷰를 생성하고 메인 테이블에 가입하여 외래 키를 얻는다. 나는 SSAS DSV에서 이러한 뷰를 직접 바인딩합니다. 내가 신경 쓰는 것은 성능, 둘 다 큐브 프로세스 및 ETL입니다. ETL 중에 관련된 모든 테이블에 모든 키를 저장하는 것이 현명한 방법입니다. 나는 간단한 차이를 보여 주었다. –
성능이 목표이고 공간이 문제가 아니며 상위 테이블을 참조하지 않고 하위 팩트 테이블에서보고 할 예정이라면 FACT를 다른 FACT 테이블에 추가하고 아무 것도 잃지 않고 잠재적으로 조금 얻을 수 있습니다 속도. 관련 테이블을 쿼리 할 때 당신은 항상 부모의 사실 테이블을 포함하는 경우
당신은 예를 제공 할 수 있습니다 (항상 가입하고 그렇게함으로써 비용을 초래하기 때문에)
그러나, 다음 아무 소용이 없습니다. – Diego
을 쉽게 분석 할 수 있습니다. 메인 팩트 표 FactTable (PKEY, FKey1, FKey2, FKey3, FKey4, 값) FactTable1 (PKEY, FactTable.PKey, ErrorCounter) FactTable2 (PKEY, FactTable.PKey, EventCounter) 등에 관련 사실 테이블이다 질문 : FactTable1 또는 FactTable2를 다음과 같이 구성해야합니다. FactTable1 (PKey, FactTable.PKey, FactTable.FKey1, FactTable.FKey1, FactTable.FKey3, FactTable.FKey4, ErrorCounter) –
어떻게 4 개의 팩트 테이블을 가질 수 있습니까? 다른 사실과 다 대일 관계가 있습니까? 정의에 따라 팩트 테이블은 공통 차원으로 관련됩니다. 매우 제한된 상황을 제외하고는 다른 사실 테이블에 사실 키를 두지 마십시오. –