Having the date and time separate will allow you to do aggregates by time much easily. for eg: if you want to run a query to find what time period of the day is most busy. This is much easily performed using a separate time dimension.
Also, you should just have one timekey. Decide on either GMT/ EST time - then use this in the fact table. If you need to run reports based off the other timezone, just convert it in your application or query.
I would link at all/most levels. This denormalized star means that yes, the data is redundant, but it typically makes the reporting and analysis a lot easier. Note that this is very different from OLTP normalization, and you don't typically have to worry about redundant data getting out of sync because in a DW scenario data never changes. New facts get added and dimensions get expired and new ones created.
I don't see a Dim_Folder. I would assume that the actual path of the folder would be an attribute of the Dim_Folder. Only the numeric quantity and any degenerate dimensions (http://en.wikipedia.org/wiki/Degenerate_dimension) would be in the fact table. I wouldn't think of the folder path as a degenerate dimension because it keeps coming back in each snapshot (an a folder isn't a transaction).
So you could do something like this:
SELECT AVG(bytes_on_disk)
FROM FACT_Folder
INNER JOIN DIM_Folder
ON FACT_Folder.FolderDimID = DIM_Folder.DimID
INNER JOIN DIM_Date
ON FACT_Folder.SnapshotDateID = DIM_Date.DateID
WHERE DIM_Date.Date BETWEEN '20120101' AND '20121231'
AND DIM_Folder.FolderPath = '/usr/bin/'
See how the DIM_Folder usage makes the set of dim ids small and then, we're assuming some kind of index on snapshot date and then folder dim id (or vice versa).
See how you also now don't need to join on folder at all if you just want the data at a higher level. Since you usually know all this at ETL time, there is a different motivation than in OLTP systems where you want everything to move together when something is changed (leg bone connected to the thigh bone, etc.). In DW scenario, you really don't want anything to move.
So, bam! - total Farm usage analysis:
SELECT DIM_Farm.Farm_Name, SUM(bytes_on_disk)
FROM FACT_Folder
INNER JOIN DIM_Farm
ON FACT_Folder.FarmDimID = DIM_Farm.DimID
INNER JOIN DIM_Date
ON FACT_Folder.SnapshotDateID = DIM_Date.DateID
WHERE DIM_Date.Date BETWEEN '20120101' AND '20121231'
GROUP BY DIM_Farm.Farm_Name
Remember stars are really simple for analysis. You NEVER need to worry about inadvertent cross joins in a single non-snowflaked star. When linking different stars, you DO have to watch out. So queries in MOST cases are MUCH simpler in star-schemas. No network traversal and worrying about many-many relationships like in a normalized model.
Best Answer
Typically dimensional modelling starts by identifying facts and the dimensions about those facts. Most of those things you mention are dimension attributes.
Staff/employees alone and their place in an organization is probably going to be modeled with a factless fact table.
You may well have a supervisor/employee relationship, and this would be an instance of a factless fact table where the facts in that table are likely to be dates of supervision (these are really a lot like degenerate dimensions).
However, I expect you will have fact tables like hours worked etc which will use these dimensions as foreign keys.
It is very unusual to be modeling dimensions in isolation, as dimensional modeling is a very pragmatic type of approach which is very dependent upon the type of data you have as well as the types of analysis. The choice of how many dimension tables and which attributes go in which dimensions is very dependent upon data behavior and can sometimes be quite arbitrary.