Not totally sure I understand the question, but I'll base my response on what I think it is:

One approach to this might be to use a COUNT of a data item, which in effect then becomes a measure in the cube. This is common in web traffic analysis cubes, etc. I do this as a part of the exercises in the following Database Journal articles:

http://www.databasejournal.com/featu...le.php/2237551

http://www.databasejournal.com/featu...le.php/3067851

It's somewhat more of a concern, however, that you seem to want to create a cube before you know exactly what the measures need to be; the "things that the cube measures" need to drive its design, and the "ingredients" to supply those measures need to be in the fact table if you expect any degree of success. It's more a question of "what do I need to have to build my cube, as designed to meet business requirements" than "what can I build based upon what happens to be in the fact table."

Does that make sense? What kind of cube are you trying to build? Do you understand the general use of a fact (versus a dimension) table?

Let us know if we can help further ... Specific examples are most useful!

Bill Pearson
MSAS Architect and Author