My challenge is to figure out whether or not I need to maybe combine some of the measurements into single fact tables, or if it is important to keep them separated. For example, miles and hours almost always go hand in hand as they will directly relate to a voyage (one trip will have distance and timespan columns). However, notice that hours has one addiitonal fact - NumberLayoverHours. You can't have layoverMiles, it just doesn't exist. Would it make sense to pull all the mile attributes into one fact table? Oor do you see them being parted out?
Depends on the granularity of the fact table. Do the measures use the same dimension keys and does it make sense in that fact table to aggregate the measures over the same dimesnion filters? If so they can go in the ame fact table otherwise separate - and maybe combined in an aggregate fact table.
It sounds like your fact table might be dealing with trips in which case it makes sense to include the layover hours in that table - it doesn't matter that there won't be a measure for layover miles.
========================================== Cursors are useful if you don't know sql. SSIS can be used in a similar way. Beer is not cold and it isn't fizzy.
Awesome...That makes sense...this part: " it doesn't matter that there won't be a measure for layover miles." is the main concept that I'm looking for. And to answer the questions about the dimension filters, yes, they would mean the same things...I was more concerned about accidentally setting things up where you could misrepresent the aggregates by having sums of different levels of granularity side by side (ie month and day in the same report) this would obviously cause problems if you were trying to show a total for a month and a total for a day side by side.