The attributes useful around time are quite limited; there is a small debate as to whether there are sufficient to warrant the development of a Time dimension. My take on it is that if the exact time can be categorized into useful periods for your organization such as shifts then a separate dimension may be useful; if that is not the case then a simple timestamp on the fact table will suffice. But without doubt, do not change the granularity of a date dimension to hours or minutes; it will grow hugely.
A degenerate dimension can be created with time as a column to split the attribute from the measures on the fact table; calculations involving time ranges will perform much better and easier to implement when the timestamp is also contained in the fact.
Use the timestamp on the fact as a key to the time dimension if you do decide to create one. If the granularity is to the hour then there will be 24 records, 1,440 by the minute and 86,400 by the second. As with all dimensions there should be an additional Unspecified Row for null or erroneous values.
A degenerate dimension can be created with time as a column to split the attribute from the measures on the fact table; calculations involving time ranges will perform much better and easier to implement when the timestamp is also contained in the fact.
Use the timestamp on the fact as a key to the time dimension if you do decide to create one. If the granularity is to the hour then there will be 24 records, 1,440 by the minute and 86,400 by the second. As with all dimensions there should be an additional Unspecified Row for null or erroneous values.
No comments:
Post a Comment