• The only relationship between those two dimensional tables, is the fact they belong to the same fact table rows.

    It sounds like the relation (one-many) between Server and Site doesn't explicitly exist in the data, except in the fact table, or rather a view on it:

    SELECT DISTINCT ServerID,SiteID FROM fact.IISLogs

    This will give you a set with duplicate values of ServerID, but unique values of SiteID (implying that one Server can have 1 or more Sites, but each Site only has one Server).

    Am I right?

    If so, then the way I'd do it is to build this view, and base the dimension on your two existing dimension tables plus this view, joined on the appropriate ID columns. Your Client and Environment hierarchy levels are going to have to do some deduplication themselves, because (I assume) dim.ServerInfo.Client and dim.ServerInfo.Environment contain duplicate values.

    There probably is a way to do this within SSAS without creating a separate view. It's just my personal preference to create a view, because I find dimensions with duplicates in their source data (and especially, dimensions that are based on fact tables) deeply confusing to deal with. A dimension, IMHO, is supposed to have unique members at the leaf level. Someone else more familiar with that way of doing things (deduplication within SSAS, rather than in a staging database) might come along and be able to say more about it.