Modeling IT Infrastructure

[jball]

I'm developing a data warehouse for an IT infrastructure to reflect a service oriented architecture. Examples of some facts are:

Inventory of devices deployed
Inventory of devices not deployed
Device purchases/leases
Device utilization

Devices would be associated with servers, storage arrays, networking. I'm curious if anyone has worked with creating a dimensional model for something like this. I'm a little hung up on how to do the hierarchy of devices and track deployed devices. For example, an infrastructure would consist of a datacenter, which contains cabinets, containing racks, containing chasis, containing servers.

I need to track the amount of servers being used along with the amount of chasis being used that contain the servers. I know so many servers can be in a specified type of chasis. The 'Deployed Device Inventory Snapshot' fact could be at the server grain. There could then be a dimension handling the hierarchy of the system to allow calculations I suppose for number of chasis deployed, and other metrics ... given a number of servers that a particular chasis can have. Or would a better approach be to have separate deployed inventory facts for each item in the hierarchy? For example, have a separate fact for servers, chasis, racks, cabinets with metrics for each of those?

Does anyone have suggestions or experience with something like this?

[BoxesAndLines]

I've not developed a dimensional modeling for this domain, but what may help in understanding the data relationships is a logical data model. I have found once I have a normalized model of the data, building the dimensional model is significantly easier.

[ngalemmo]

Wither chassis, racks, cabinets is a hierarchy of chassis or separate dimensions depends on the attributes associated with each. Either way could work.

Depending on what you are trying to model, there are a variety of different fact tables.

For example, if you are simply modeling the service dates of a server, then a state fact with server, location (or chassis, rack, cabinet dimensions if you don't use a hierarchy), and begin/end service dates would suffice. If you are modeling events relating to a server, then an additional event type dimension, a single event date dimension (instead of begin and end dates), a timestamp if needed (degenerate dimension) and whatever measures are applicable would be added.

[Sponsored content]