차원 디자인 : 특정 데이터 유형에 대한 사실 대 차원에 대해 확실하지 않습니다.

Question

특정 차원에서 무엇을 가져야하는지 결정하고 개발중인 스타 스키마에 대해 팩트 테이블에서 무엇을 가져야하는지 결정하는 데 어려움이 있습니다.

예를 들어 프로젝트가 부동산 관리 회사의 주택을 추적하고 있다고 가정 해 봅시다. 다양한 날짜, 임차인, 계약서 등의 치수는 모두 매우 간단합니다. 집이 어디에 있든 관계없이 현재 소유자, 현재 임대인, 현재 임대 계약은 물론 이웃, 주소, 현재 임대 가격, 현재 시장 가격 등을 추적해야합니다. . 소유자, 임차인 및 계약서 자체는 치수입니다 (이웃 및 주소는 치수 일 수도 있지만 그 정도는 신경 쓰지 않습니다).

집에 보관 된 많은 데이터가 쿼리 필터링이나 큐브의 행 및 열 머리글에 사용됩니다. 그 중 일부는 부수적 인 정보로만 필요하며 집 단위로 집에서 보았지만 집계되지는 않았습니다. 데이터 감안할 때

, 나는 그것으로 무엇을해야하는지, 나는이 (적어도) 세 가지 옵션 :

• DimHouse : 집 테이블에서 더 잘 볼 수있는 속성의 많은, 차원이다 사실 테이블이지만 브라우징 및 필터링에 사용되므로 여기에 있어야합니다. 현재의 임차인과 같은 속성에는 눈송이/아우 트리거가 필요합니다.
• FactHouse : 다른 팩트 테이블에 가입되어있는 집 정보의 누적 된 스냅 샷이 있습니다. 아마도 트리밍 된 DimHouse를 브리지로 사용했을 것입니다. 이것은 나에게 이상한 것 같지만 사실 테이블에 사실 인 것처럼 보이는 것을 넣습니다.
  • 관련 사실 테이블에 현재 소유자, 현재 임차인 등을두고 그 사실을 소유자/임차인/등으로 최신 상태로 유지하십시오. 변화 (이상한,하지만 스타 스키마 토지에서 우리를 계속 것입니다).

는 그래서 차원 경로를 추락했습니다. 그것은 나에게 약간의 마음을 불 태우지 만 목표를 성취합니다. 데이터를 구성하는 더 좋은 방법이 있는지 알고 싶습니다. 그들은 필자가 의미가 있고 ("최상의"가치를 위해) 일을하는 가장 좋은 방법 인 경우 이중화 (예 : 사실 테이블과 유사한 데이터가있는 차원 테이블) 또는 눈송이는 신경 쓰지 않습니다.

Answer 1

스타 스키마는 특정 종류의 쿼리를 쉽고 효율적으로 만들기위한 목적으로 만들어졌습니다.

치수 란 무엇이며 사실은 무엇인지에 따라 별의 도움을받지 못하는 검색어를 발견하면 크기 및 사실에 대한 대안보기 주변에 별표를 추가로 만듭니다. 수행하려는 쿼리를보다 쉽게 ​​지원할 수 있습니다.

트랜잭션 데이터베이스를 정규화 된 상태로 유지합니다. BI 데이터웨어 하우스에 관해서는 이중화 불안이 심장 화상을 피하기 위해 이동해야합니다.