I expect I would have a drive_usage fact table with a link to a snapshot time dimension, a drive dimension, a computer dimension and the various numerical facts about the drive at that instant in time.
There should probably be nothing regularly changing in the drive dimension - I guess it depends upon your definition of drive - is it a physical drive or a logical unit or what. Perhaps your "C" drive has a serial number, and it's replaced - then the dimension will expire and a new dimension is added. These things about a dimension are not really "facts", they are attributes. This wouldn't affect reporting because the data for computer X, drive C has continuity. Similarly if computer X is upgraded from dual core to quad core and so there is a change to the dimension (assuming something beyond number of cores is not tracked in a fact table, like a motherboard revision). The capacity of a drive would be in the fact table, so changes to that over time are just new facts with new dates. Sometimes you can even model changes to membership as facts. i.e. if physical drives 1-5 are in logical drive C one day and then physical drives 1-6 are in logical drive C the next, that might just be a fact change in the physical drive membership fact table. These are what some people call factless fact tables, since the only fact is the existence of the row shows membership - there is not much to be done except totalling or counting.
When you get into folders, modeling the hierarchy can be a lot more tricky depending upon what you are trying to achieve with rollups.
There is a lot of art to DW modeling in domains which aren't run-of-the-mill scenarios.
Old question & I know the original posters are inactive, but since it came up in a Google search, I thought I'd add my thoughts.
1) Make Start_Date and End_Date regular, atomic attributes (either
ISO8601 strings or the DB's datetime object) and only allow limitted
filtering.
Putting a date attribute into an existing dimension makes sense if the main goal is informational (i.e. people want to include the start/end date of the promotion in reports). However, if the intention is to filter, then filtering on an atomic date attribute will be relatively painful.
2) Make Start_Date and End_Date foreign keys to the Date table,
breaking the star schema, but allowing the same filtering capabilities
as the full Date dimension.
This type of snowflaking is called an Outrigger Dimension and can be acceptable in a star schema. (http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/outrigger-dimension/). I imagine this is what you did.
3) Include attributes like Start_Date_Day_of_Week, Start_Date_Quarter,
maintaining the star schema but increasing the dimension size and
essentially duplicating the structure of the Date dimension in the
Promotions dimension.
The duplication would get messy (maintaining multiple date fields, especially since you have multiple dates in the same dimension). It also makes future maintenance more complex: if you want to alter your date dimension, you have to repeat that alteration in dozens of places (or have an inconsistent user experience).
On the flip side, this might be a valid option if, for example, there are just one or two ways that you know people want to filter promotions on. For example, if you know end-users want to quickly filter to active promotions or "promotions closed in the last 30 days", you could calculate and add that as a specific attribute in the promotion dimension, rather than linking to a full date dimension for promotion start & end date. (Though what starts out as one or two attributes can expand quickly, as end-users find more and more time periods they want to filter to.)
There is a 4th and 5th option, depending on the specifics of what you intend to filter by promotion start/end dates:
4) Add the promotion start/end date fields as keys in the Sales table.
You'll be storing the same piece of information each time a promotion is used, so at first glance, it feels like a lot of duplication. But denormalization is the name of the game in a star schema. If your goal is to filter to sales based on the promotion start or end date (i.e. sales where the promotion start date was last month), I would recommend this over an outrigger dimension.
5) Create a new, factless fact table, for promotions
If your goal isn't to filter sales at all, then a factless fact table might be a better solution. This could tell you how many promotions were in effect on a given date (regardless of whether there were associated sales), for example. More information: http://www.kimballgroup.com/2011/04/design-tip-133-factless-fact-tables-for-simplification/
My experience with dimensional modeling is that the best solution often depends on what the end-user is trying to accomplish. If you (or they) are not yet sure what they're trying to accomplish (i.e. you know promotions have start & end dates and that's it), I'd start with option #1. This puts the information in your model without too much work.
If it later transpires end-users are trying to filter Sales by start & end dates, that's when I'd consider #2 or #4. If it transpires end-users are trying to analyze promotions independently of sales, I'd look at #5.
Best Answer
You haven't given a lot of details, but on the face I'd say make it a new fact table. It sounds like your cohorts will be entirely distinct, so it wouldn't be meaningful to total or average across both sets. Your records won't have any overlap in dimensions (except Date, which is almost universal), so they're really distinct things, they just happen to have similar fields.