What I mean is that ID's are usually foreign keys that link to other tables. In a datawarehouse you should be using surrogate keys for all your dimensions and link them to the fact table. The combination of all the dimension surrogate keys within the fact table make up the primary key of the fact table, it doesn't really need it's own different primary key.

A measure should be numeric but not an ID. An ID will be slow, and not amenable to fast aggregation.

For example it should be a currency amount, or a count indicator.

So for example if you are counting, you should have a column specially for the count, and just contain a 1 in it if it exists. Don't put a 0 in this column if it doesn't exist, it's unnecessary and will make querying slower. If the source datamart/datawarehouse does not have a row for this particular dimension/measure intersection then the cube should not have a cell, i.e. it should be EMPTY (doesn't exist - like a 'hole' in the matrix).

Cubes are supposed to be sparse, meaning they should not contain blanks or zeros, only EMPTY cells. These will either return as NULL in a query or not at all (depending on your query) If you must report zeros (for example a monthly total where you don't want to skip empty months) you can just use isempty() in an MDX query.

I don't think you should re-purpose an auto-incrementing ID field as a measure. If you have a new column containing only 1's then the cube when processed will automatically sum these values across all the dimensions for you ( and the sum of existing 1's is exactly the same as a count), and the MDX queries will be fast.