Actual Date vs Date Key in Fact table

Hi,
I have a dilemma designing this fact table regarding the dates
Fact_Job
--------
fact_job_key - SK
job_key - NK
contractor_key
job_type_key
job_estimated_start_date
job_start_date_key
job_end_date_key
job_amount

The business user wants to slice and dice by job_start_date and job_end_date but not by job_estimated_start_date though they would like to see the estimated start date when creating a report. I was wondering if I should keep the job_estimated_start_date as an actual date instead of creating a key which will then link to dim_job_estimated_start_date (a view of dim_date) just to avoid unnecessary join.

Does this violate any fundamentals regarding the fact table?

Thanks

Yes, it violates the basic principle that, when given a choice, users will eventually do all of the above. Use an FK and sleep well at night.

Joins are not bad. Joins are good. Repeat 10 times and then return to modeling.

ngalemmo - Thanks so much. I really appreciate your efforts in advising and educating people regarding dimensional modelling/DW.

"Joins are good". I agree with this statement but not completely true. Isn't it true that one of the reasons we don't encourage snowflakes is because of the joins which can impact performance.

Thanks

KKumar wrote:ngalemmo - Thanks so much. I really appreciate your efforts in advising and educating people regarding dimensional modelling/DW.

"Joins are good". I agree with this statement but not completely true. Isn't it true that one of the reasons we don't encourage snowflakes is because of the joins which can impact performance.

Thanks

You are correct. Fact to dimension joins are good. Snowflake joins are bad. It's not so much the performance aspect, as any relational database can perform joins very efficiently today. It goes more to keeping the model simple and easily navigatable.