So far I have used the universe wizard and connected to the database. However I still need to define my own data types, i.e. dimension/measure/detail before it will let me go ahead and produce any real kind of reports/charts etc.....
The role of dimension/detail/measure is as always open to debate. If you create an object in the universe by dragging a column from table to the objects panel BO will set it as a dimension. Objects that will be aggregated or otherwise calculated with should be set to measures, deactivate the LOV and set the proper aggregate behavior.
Whether an object qualifies for dimension or detail depends upon the following:
1. If you want to use an object for drilling down through an hierarchy, it should be a dimension.
2. If you want it in linked dataproviders as an object to link on , it should be a dimension.
Typical dimension are:
product,time-objects,customer,region,country
An object that acts as an property on a dimension is usually a detail, like Customer-name,Product-size.
In some cases it will be wise to create a dimension AND a detail for the same database object. For instance a report on customer-sales may be too difficult to interpret just using the customer numbers. So, for drilling down, you may want to create an dimension out of the name too.
Be careful, cause stuuf like names are often non-unique, so an even better solution is to create an new object like
concatenation of number + name to create unique values.
T.Blom, you made an interesting point about deactivating the LOV with measures, I've not come across thgis before and was wondering why it is the case??
This is not mandatory of course, but since most measures are calculated/aggregated fields there is little use in having a LOV. With an average database a distinct list (that is what a LOV is) will either be VERY large and/or will have to be refreshed every time (performance!) to be of any use.
Secondly, users will become used to using a LOV (forgetting to refresh altogether) and typically using a measure in a condition will be much quicker by just manually entering a value.
Thirdly, measures are almost by definition non-indexed fields, making the use of LOV's even less desirable. Doing a refresh can be a real pain.....
Last but not least, there is no guarantee that you will get a value from the LOV that'll suit you.
Suppose you want ......... Sales_revenue > 1500
If you have a LOV with values like 1476 and 1534 around the 1500 mark you may be tempted to select 1476.
You can guess what you (possibly) will miss the next time the source is updated.
If one can think of a measure with distinct values which don't grow in number a LOV may have some use.....
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.