In most cases, it is better to use two separate dimensions for date and time. time in your case would have just 96 (24 * 4) members. These could be aggregated to hours, and depending on reporting/user needs to other time ranges like shift names. I would use an integer key for this, maybe a "speaking key" like 1415 for the time span from 2:15 pm to 2:30 pm (i. e. hour of start * 100 + minutes of start
). This would make it easy to calculate the foreign key in the fact table from the DATETIME_START
column. But you can also assign meaningless integer surrogate keys to each record.
The date dimension would contain days as the granularity, and could have attributes like day of week holiday yes/no, month, year, quarter, ... That very much depends on reporting necessities. Better prepare more than fewer attributes here, as this makes life for reporting easier. And the dimension table has few records, so there is no need to restrict the number of attributes too much. You can use a similar structure for the integer primary key of this table, e. g. 20131009 for October, 9, 2013. But again, just an arbitrary integer surrogate key would do as well.