Snowflaking 날짜 차원

Question

, I 등 시작일, finish_date, service_date, onhold_date, RESUME_DATE과 같은 열이있는 프로젝트 차원이

나는 모든 날짜에 대한 외래 키를 도입해야 팩트 테이블을 날짜 차원에 연결하거나 눈송이를 project_dimensiondate_dimension으로 설정해야합니까? 주어진 프로젝트에서 모든 날짜를 사용할 수있는 것은 아니므로 모든 열을 fact_table에 유지하면 fact_table에 null 키가 생길 수 있습니다.

이 시나리오에서 날짜를 처리하는 가장 좋은 방법은 무엇입니까?

Answer 1

데이터웨어 하우스에서 필자는 분명히 개인적인 선호도는 약간 있지만, 사용하는 환경에 따라 달라질 수 있지만 일반적으로 눈 별표가 가능한 일반 스타 스키마를 선호합니다. 오라클 (내가 가장 많이 익숙한 환경)에서는 물리적으로 눈송이를 지원하지만 비즈니스 모델 (논리적) 레이어를 눈송이로 표시하지 않는 것이 가장 좋습니다.

개인적으로, 나는 몇 가지 이유로 사실에 FK를 넣으려고했다. 하나는 별을 유지하는데, 일반적으로 눈송이가 더 많은 결합을 도입하고 별이 더 빨리 집계를 처리하므로 성능이 향상됩니다. 둘째,이 데이터를 다른 사실의 데이터와 결합하는 사용자가있는 경우 준수 된 날짜 측정 기준을 적용하면 실적을 쿼리하는 데 도움이 될 수 있으며 더 강력합니다. 마지막으로 별이 가장 일반적 일 수 있으므로 다른 사람들이 앞으로이 영역에서 작업하게하는 것이 더 쉬워야하고/미래의 다른 응용 프로그램에서 데이터가 더 잘 작동 할 수 있습니다.

null FK의 경우 시스템 기본값 날짜를 기본값으로 지정합니다. 지정되지 않은 레코드는 01/01/1901입니다. 비즈니스 사용자가 1901을 보지 못하도록하고 싶지 않다면 null을 남겨 두지 않을 것입니다. 그렇더라도 case 문을 사용하여 null 값을 지정하지만 테이블에 필드를 채 웁니다.

다음은 각 유형의 장단점을 설명하는 좋은 기사입니다. 내가 말했듯이, 둘 다 완전히 옳고 그른 것입니다.

http://www.dataonfocus.com/star-schema-and-snowflake-schema/