That behaviour is dependent on your `KeyColumns` setting.

Given a cube with these 2 named queries in the `datasource view`

Cities:

    SELECT        1 AS id, 'India' AS country, 'Calcutta' AS city
    UNION
    SELECT        2 AS id, 'India' AS country, 'Bangalore' AS city

Sales:

    SELECT        1 AS city, 5 AS salesamount
    UNION
    SELECT        2 AS city, 5 AS salesamount

A dimension based on cities, linked to the Sales table on the  `sales.city->cities.id` relation that looks like this, using the id column as `KeyColumns`:

[![enter image description here][1]][1]

The result is this:

[![enter image description here][2]][2]

However, if I change the `KeyColumn` property to `country` for that attribute like this:

[![enter image description here][3]][3]

The result is all sales are reported under one single country:

[![enter image description here][4]][4]

I agree [the documentation](https://msdn.microsoft.com/en-us/library/ms174919.aspx) is a bit terse:

> Contains the column or columns that represent the key for the
> attribute, which is the column in the underlying relational table in
> the data source view **to which the attribute is bound**. The value of
> this column for each member is displayed to users unless a value is
> specified for the NameColumn property.

Where you should interpret it as "there is one separate attribute member for each distinct value in the key column, even if the displayed value is the same"

Do note however that changing the key column might require you to change the `NameColumn` and the `OrderBy` properties.

Also, `KeyColumns` can be comprised of multiple columns acting as a unique key instead of a single key like in my example.

Sometimes when it's too risky for existing reports to change the structure already in place it might be a good option to add an extra attribute.

  [1]: https://i.sstatic.net/wZvoK.png
  [2]: https://i.sstatic.net/5wEYR.png
  [3]: https://i.sstatic.net/HO9qo.png
  [4]: https://i.sstatic.net/evD3t.png