Setting up a relative dimension?

I have a pretty simple scenario but a very large data set (using even simpler example below to illustrate my issue).

Let's say i have a cube comprised of Country table(fact) that has one dimension called Continent.

With this, i can aggregate country data by continent.

But let's say each country has a city:

Here i can't assign Continent dimension directly to city, because city does not have a continent property. This is a simplified example, and it would be trivial to join Country information in while populating the city fact table. However, my application is using a very large dataset that requires a long time to query, and i am trying to avoid having to make a join on Country to get the continent id. I need to be able to write simple MDX query to get population count by country or by c开发者_如何学City.

How can i set up my cube, so that dimension relationship in above scenario can be set up between city and continent, without adding continentID to city?

Update

As Brian suggested, i could make country a dimension. This is how i did it initially, and perhaps i didn't do it correctly but it was a performance hit because: Above example is simple, but in my case, i have 15 properties (such as continent above) that i need to aggregate my data on. If i create a country dimension, and specify those 15 properties as dimensional attributes, every time i process my cube, it will do a "select distinct continent from country" x15 (once per each attribute) in order to get that distinct list of continents. if Country table is huge (which in my case it is a view comprised of many big tables), it will take a very long time just to get that list of distinct values per dimension.

my attempt above is just a way to work around this problem, and have separate table per dimension that i could easily manage. my only problem is that i have sub views which need to be aggregated on those properties, while the properties do not exist on sub tables and need to be looked up from "country" view etc..

It doesn't look like the dimensional model was thought through very well.

A band aid to fix the problem would be a Country Dimension. Country is common to both Country and City.

I'm sure the problem is much more complex than this, but you've listed a very simple issue.

AFAIK, no amount of MDX (or any other technology) can overcome bad design problems. The dimensional model is the foundation of data warehouse performance. It's very important to get it right early.