I am personally in favor of a dataset based on your data mart (common database) and not on your OLAP cube. The first reason is that when you make your data mart a dataset you have to have no knowledge of MDX, which is difficult to learn. You can suffice with SQL. There are reports and not for static analysis. OLAP is particularly suitable for displaying data at the aggregate level, where speed plays an important role.

In short, build a cube, but no reports on a regular database

I'm curious how you go on a moment to the security of your data. Of course this by no means all reports, but when the report details specific approaches that department then rolls through the foreclosure data nevertheless a welcome addition.
In projects where I worked was the assumption that their data reports only took the cube. There are a number of situations where you do not escape the cube to ignore the data warehouse and direct appeals.

It gave us both before and disadvantages. The biggest drawback we encountered was the query language MDX. Internally, we were good enough to work, but when a customer wants to build reports he did not escape to some knowledge of MDX to do. The queries that dishes up performance reporting services is not always subtly. As you have said the advantage of shielding data in your cube.

I wonder how you look against it here.

Mark,

Once a user has a report parameter to choose his username is passed to a SQL function. Then look at a security table, which parameters they choose. Come out of such departments. User only Division XXX XXX show. Once he has a parameter 'section' would choose going in the background of the table looked to see what he can. There was a table available to all users codes and which departments they may see. Do you understand the principle?

SQL function that is a standard SQL Server functionality or build something yourself?

Because what happens when self-reporting data warehouse administrators to define? Are they themselves consider that this function is called or has a technical link that automatically ensures there?

Homemade function. We use a reporting portal on top of Report Manager. Choose the parameters in the portal and are then passed to the report. Once the user is in the portal there is already a validation trick to parameterbox filling, this does the job.

Johan Hi vdk,
I am not satisfied with cooperation cubes and reporting services. By then going sql'en, rebuilding of business logic, as named above leads to rework, which is already sufficiently valid for other choices in the presentation tooling within the MS BI stack, or beyond. After all, who says you should use Reporting Services? and if the client enforces state free to swing off to a glorious life. SSRS product team of guys who seem to have one or more MS-MS architecture briefings missed because the team has long excelled at SSAS was employed, have understood it.

Remarks:

According to the MS OLAP cube architecture is the "single version of truth" beleveraar at every level. I trust them totally, role of the specialist in DWH is one business process repository to build up as strong as possible, and this lends the cube itself, its place in the process, for good. This business is repository to lend themselves to the organization for themselves, with roles in various appropriate structures and procedures, to release to unrestricted. Through the shared dimensions and facts shared model can Ansi-sparc compliant, a la semantic layer or framework as other vendors call it, a decoupling and thus consistent, single, testable definitions yield. Where these definitions end up in reports / analysis to the organization to decide, but this is their own effort to be (Application Manager, an analyst who ever).

(Continued)

one delivered definition in a business repository is similar to an article in the logistics: do you constantly with reporting services to the corridor, you will run each time the customer back to the shelf, renamed the article (the definition), it goes back out to the counter, and then counts down.
A). if you sell products, and packaged neatly on shelves shall recognize them by myself, (business to explain and document repository) B). The DWH / BI specialist with useful things can occupy the warehouse filling, advice and the matter lay neatly on the shelf (the business repository). Operational efficiency. Or A and B released depends on the presentation tool.

The rigidity of the SSRS reporting tool makes it suitable to dash back to places where rigid graphs by a single passage walkways perspective on reality enforcement. But then we often have a limited set reports.Daarvoor you can tweak it here.

If we consider the MS BI stack, it is useful, so if space is at a command, look at the tooling and the trade-offs they are made. Are you condemned to SSRS may be useful for another task to seek concessions on the back end (rebuilding logic) is not exactly the DWH specialist favorite works given that the disaster has possibly can see into the future. The stack is sql server + sharepoint BI. Your presentation tooling is therefore primarily on the choices you make in licensing. Take your customer only SQL server, fine: that or SSRS will have to put in (the store model described SSRS) report builder or the little brother to himself to walk to the shelf. The Report Builder client tool is rather limited in 2005 that your end user still feels limited

We compare the power of a pivot (in sharepoint, excel services) with traditional reporter elements (tables, graphs) wins in the pivot tower behaviors with flying colors. You can therefore ask whether the era of the rigid tools (Reporting Services and Report Builder) is not just about over.

Reasons why you should use the cube:
- Commitment to the MS architecture is useful for the future (you may assume that the vendor makes it logical leaps)
- Escape the inefficient store model: detailed repository strong business value and non-hand span and reporting services to waste time, let alone logic duplication
- Dimension security is much more detailed than relational database security. Easier to draw, and cell-security can descend to the unique value (you will not succeed unless tig relational functions to use)
- T-SQL is suitable for data logistics in the path, for shifting collections from A to B, however, unsuitable for analysis, analysis centered on the event after. Through cubes diversions you aggregations of the DWH to the cube, which is exactly one of the reasons of multidimensional models by dimensional modeling is exactly identifies where to aggregate and EEE to aggregation easily adjustable, that is the OLAP engine " .
- Leaf-level reporting can also cubes, although this will be slightly slower than the alternative with the stored procedure which works on the views DWH (to ANSI-compliant to sparc)

Are you not satisfied with the presentation tools, you simply buy something else for the presentation, something that still often occurs on the MS stack.
Rebuilding business logic, as mentioned above is from DWH / data logistically it ultimately risky situation and leads to rework, is in itself sufficiently valid for other choices in the presentation tooling in the MS BI stack, or beyond .