You would need as many time dimensions as there are roles.
In the sample model great outdoors warehouse, there are 3 date keys in the sales fact table. They are salesdatekey, shipdatekey, and closedatekey. You will notice that there are 3 aliases for the time dimension table and 3 DMR dimensions. This is because of the role-playing which is taking place. You will notice that the sales dimension has relationships to all the other facts and time (ship date) and time (close date) do not have any relationships to other facts.
You need to identify if there is any role-playing involving your time dimension table and your fact table. If there is, then you would need to create aliases and set one relationship which represents one role-playing scenario for each of the aliases. This would ensure that the proper join is used in the SQL when it comes time for the query.
Since you only seem to have one time related key-- in your case daykey-- you probably do not have any roleplaying.
The other columns which you mention are usually attributes rather than keys.
------------------------------
IAN HENDERSON
------------------------------