A dimension is a descriptive data field, something that can’t be aggregated. Think name, address, color, phone number, etc.
A measure is a value that can be aggregated: sales volume, employee count, etc.
Functionally, these two types behave differently in BO. If you create a report with nothing but one measure object (ex. employee count), the report will have one row – the aggregated value of that measure (sum, count, max, etc.). If you add a dimension to that report (ex. state), you’ll now have one row for each unique value of the dimension, and the original measure column will now have the aggregated value of the measure for each value of the dimension (count of employees in each state).
Generally the decision to make something a dimension or measure is pretty clear, based on the definitions above. Sometimes it’s not so clear, such as “product price” – it’s numeric but generally you don’t want to sum up product prices, so it might make more sense for this to be a dimension.
Detail objects are less commonly used (I hardly use them at all). They are similar to dimensions in that they are descriptive, but they represent something that is a detail description of a dimension. For example, you might have a dimension for “State Name”, and a detail object for “Capital City”. Even here, there would be nothing wrong with Capital City as a dimension.
There is one subtle benefit to using a dimension object, in a fairly advanced scenario: when you create a report that combines results from two or more queries, you have to align (“merge”) at least one dimension object from each query. A report block can contain measures from any of the queries, but it can only contain dimensions if they are merged. So if you have a dimension that is only present in one of the queries, it can’t be in a report block – however, if you create a detail variable that references that dimension, the detail can be added to the report block.
Joe
joepeters 
(BOB member since 2002-08-29)