Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
help with creating a universe - dimension/measure/detail
- Thread starter achowe
- Start date
Have you tried using the universe wizard? Not used it myself but i'm guessing it'll make life easier.
What stage are you at? Have you made a connection to the database you are reporting from? Have you inserted the tables into designer?
As a source of information, although very meaty, the BO help guides which are packed with the programme are very good.
What stage are you at? Have you made a connection to the database you are reporting from? Have you inserted the tables into designer?
As a source of information, although very meaty, the BO help guides which are packed with the programme are very good.
- Thread starter
- #3
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
Information analyst
tbl@shimano-eu.com
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
Information analyst
tbl@shimano-eu.com
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.....
T. Blom
Information analyst
tbl@shimano-eu.com
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.....
T. Blom
Information analyst
tbl@shimano-eu.com
- Status
Similar threads
- Locked
- Question
- Locked
- Question