Using Discoverer for OLAP though, I'm stuck, as although Marketing Manager is a dimension attribute, I can't display it in the crosstab - I can only use it to make dimension member selections:

If you're an old Express user and you're reading this, you're probably thinking "what about one dimensional text variables - they're our way to include labels in crosstabs". What this involves is using AWM10g to create an additional cube in your analytic workspace, with one dimension (in our case, Product) and a single measure defined as a text variable. Then, whenever you display products on the screen, you can include your "attribute measure" in the report as well. Traditionally, this is done as a way of adding text annotations to cubes, with the annotation being held in a variable dimensioned the same way as the measure.

Note that the measure is nonadditive, which means that it will only exist at the bottom level of the product dimension.

Next, we add the measure to the crosstab:

and then the measure appears - but it gets added alongside the Sales measure, and then is only visible when you drill down to the bottom level. So - it's not really where we were expecting it to appear, and it's not being used as a way of subdividing our products into those managed by particular product managers.

Now I'm sure there are probably ways of getting around this - maybe making product managers into a hierarchy of their own, or there may be some other way of achieving this. But what this says to me is that, when you use the logical dimensional model and you load up your dimension with attributes, it's not all that straightforward to have the attributes appear on the report, or use them to further group or subdivide your data. It's just the way the logical dimensional model works - it's got it's advantages (logical grouping of data into measures, dimensions, attributes and so on) but it's not as freeform as an SQL query tool that lets you group data by just about anything.

The other issue is around the production of tabular reports. As you know, Discoverer for OLAP is designed around crosstab reports - indeed it's the only option that you get when putting together a new workbook. But what if your organisation wanted to produce a report that lists out the products that you sell, who is the marketing manager, grouped into product categories and listed in order of sales volumes. Using Discoverer Plus, you could produce something like this:

A straightforward listing report, group sorted by category and with the category, product name, marketing manager (remember, an attribute) and sales total on the report.

With Discoverer for OLAP, although you can't choose to create a tabular report, you can achieve something like this by creating a worksheet using only one dimension (product) and hiding the others.

Then, by bringing in the Marketing Manager measure that we created earlier, we can put something together that is "sort of like" our relational tabular report:

However, it's probably not what we were really after. The product name and category are part of the dimension crosstab element, not the report, the report is all spread out rather than available on one page, and there's lots of cells that have no values in. It's probably not what the users were expecting and probably won't be acceptable for production use.

Now none of this is meant to detract from what Discoverer for OLAP, and the OLAP Option, offers. It's just that not all enterprise reporting fits neatly into the category of OLAP analysis of cubes of financial data, and formal OLAP structures aren't always the most appropriate for ad-hoc, freeform reporting. What this says to me is that, in reality, most Discoverer implementations are going to consist of a bit of relational Discoverer analysis, and a bit of OLAP Discoverer analysis; Discoverer for OLAP will be best suited to analysis of cubes of financial or performance data, where you want to drill into and investigate how the figures are made up using complex multidimensional selections, whilst Discoverer Plus is for when your reports need a lot of textual data, you need to produce simple listings of data, or your users want the freedom to have just about anything that's in the underlying database appear in the report.