Identifying fact grain

I'm trying to build a dimensional model for a not-so transactional system and am having trouble identifying fact grain. The source system is sort of an asset management system with entities like servers, location (Data center locations), network gear, product (an internal company system that is hosted on 1 of these servers), business group within the organization that uses these products etc,. It seemed to me that I needed to have more than 1 fact table, mainly because some of these dimensions are pretty disparate, they cannot be lined up on the same record (as foreign keys in the fact table). But going by this approach is going to end up in at least 4 (or more) fact tables! And more importantly I cannot identify the grain, so really my fact tables are in place in order for the end users to be able to run queries joining some of these tables..Is this approach right? Any thoughts and help is highly appreciated!

Thanks.

What are you measuring?

All that the business wants from this model is to be able to report on counts, number of servers against a given location, number of products on a server etc,. That and they definitely want historical data, because they really miss having the capability to compare counts between last month and the current month and so on.

So your grain would be server and product. Location is simply a dimension. Since you want trending, a daily/weekly/monthly snapshot is in order.

Thank you! I was thinking on those lines too, but there are quite a few of those dimensions and I am almost ending up with 4-5 fact tables going that route (combining 3-4 logically related dimensions into a fact, with these dimensional keys sometimes repeating across facts) not to mention that there's not a lot of difference between my dimensions and facts conceptually, other than the fact that I don't have to have all dimensional attributes in the fact tables.

You mean server and product as 2 different fact tables right?

No. Why would I want two fact tables? Put it all in one.