In Business Intelligence Developer Studio, I'm wondering why one would want to create a report model from an OLAP cube.
As far as I understand it, OLAP cubes and report models are both business-oriented views of underlying structures (usually relational databases) that may not mean much to a business user. The cube is a multidimensional view in terms of dimensions and measures, and the report model is... well I'm not sure entirely -- is it a more business-oriented, but still essentially relational view?
Anyway, in Report Builder I can connect directly to both an OLAP cube or a report model. So I don't see why, if I have an OLAP cube which already provides a business-oriented view of the data suitable for end-users, why I would then convert that to a report model and use that in Report Builder instead.
I think I'm obviously missing some fundamental difference between report models and cubes -- any help appreciated!
In SQL Server 2005 you still had to create a report model over a cube to use Report Builder. RB 2.0 will directly open a cube, although not all available features of SSAS are necessarily supported by RB. This blog entry by Teo Lachev discusses it in more detail.
Generally I would agree that there isn't much point to creating a model based on a cube. I suppose you could use it to hide some aspects of the cube and then you could use role based security to expose different models to users. I don't normally let users outside of BI build reports in SSRS, though, so that wouldn't be a compelling reason for me.
Report models are good if you don't have an OLAP cube. It is a good way to hide the complexity of table joins and fields while providing users with a way to get to the data. It also is a chance to provide friendlier names for business users for fields than how the columns are stored in the database.
Another advantage of an OLAP cube is the calculation engine.
You can have complex calculated measures in your cube that are hard to make and/or time consuming in a relational database, but are well suited to Analysis Services.
You can then expose those calculations to your business users with Report Builder, hiding the inherent complexity.
Security and simplicity.
You can use a report model against a relational or a dimensional database to give a user an easier to use view of the data.
You may also wish to secure your database by only exposing a subset of the columns available.
You could change the underlying data source/schema of the model, but keep the model intact, thus ensuring a seamless experience for end users.
Related
I managed to create a typical SSRS report by building one through MSSQL BI development environment. I used a simple procedure to retrieve a list of databases that reside on our SQL servers. My question would be...would SSRS allow me to build a native UI app in displaying SQL procedure results in a more user friendly way?
For instance, I am currently manually running procedures to retrieve information about our backend systems, and I wonder whether SSRS would be an ideal tool to automate the process by allowing a user to view the information that the procedures produce in a more user friendly way?
I'm not 100% sure about your question, when you ask (emphasis mine):
would SSRS allow me to build a native UI app in displaying SQL procedure results
In any case, SSRS isn't meant for nor very good at functioning as an "App" with proper UI/UX. If you're just after basic features for letting the user pick a stored procedure and then reporting the results back to the user SSRS may suit your needs.
You continue:
I wonder whether SSRS would be an ideal tool to automate the process by allowing a user to view the information that the procedures produce in a more user friendly way?
Whether it's "ideal" really depends on your context.
Finally, the last bit is somewhat confusing: "more" than what? Running queries directly in SSMS? Then probably yes.
Bottom line: if you stick with using SSRS for reporting purposes (possibly interactive, to a certain degree), then SSRS may be the ideal tool for your case.
I am currently evaluating reporting solutions for use within my organization and one of the requirements of the solution must be 'ad hoc reporting' and is defined as 'given an existing report the user will be permitted to modify the data points of the report and, additionally, save the report for later viewing'.
I worked through a basic report using SSAS and SSRS; this certainly worked but I found it to be a little bit to involved with needing to open report builder, specify the cube that should be used, and so on not to mention that the Report Builder (SSRS2K5) is pretty vanilla. The people that will be looking at these reports are certainly not technical people and my concern is that this process will be completely overwhelming. I did find this component and it is much more user friendly since the data source can be set dynamically at runtime and all the user has to focus on is what data they want to see.
Does SSAS/SSRS offer any other methods for ad hoc reporting other than using Report Builder to connect to cubes and going from there? Does anyone know of, or used, any products similar to Active Analysis that they might recommend? Any help would be greatly appreciated!
Excel 2007 and 2010 actually has connection ability to adhoc query and analyze data from an SSAS cube. Excel have a host of features that allows interaction with the cube including using pivot tables and data mining plugins to analyze the data.
simple example here:
http://www.mssqltips.com/sqlservertutorial/2016/using-excel-and-creating-a-pivot-table-report/
SSRS2012 Power View in Sharepoint mode (soon in Excel) - overview is here: http://social.technet.microsoft.com/wiki/contents/articles/3726.power-view-overview-en-us.aspx
Not quite sure what is meant by "user can modify the data points of the report" but with Excel 2007 / 2010 you can use the What If Analysis feature to modify the data in a pivot table. You can also combine that with Analysis Services writeback feature to enable some pretty cool data modelling functionality.
If you're looking for what I call "exploratory analysis" (i.e. you don't know what you're looking for in the analysis) then a product like our ActiveAnalysis component, PowerPivot, or Tableau are all good tools (note that a key difference being that our ActiveAnalysis is a developer component that you can cheaply embed into applications, and the other two are strictly end user tools).
However, if you have users who want to be able to create an "operational report" or they might want to customize existing reports those are probably not ideal tools. We actually created ActiveReports Server specifically for this type of scenario. It is a drag & drop business-user-friendly ad-hoc reporting tool that sounds like it might be more appropriate for the "not technical people" that it sounds like you're dealing with. It does not depend on SSAS and works all inside of a web browser, so nothing to deploy.
Scott Willeke
Product Manager | ActiveReports Server
GrapeCity
Rather than generate my RS reports by directly accessing a SQL database, I'd like to take advantage of Domain Objects I've already written in another application, where complex business rules and calculations already exist so that I don't have to duplicate that logic in stored procedures and other code. I want to keep it DRY.
It would be nice to treat the reporting concern as just another type of view
Is that possible with Reporting Services? It seems logical that it should be, but I'm not finding much information out there.
Yes. You can use the ReportViewer control in Local Processing mode. In this mode, you can just pass a DataSource instead of directly accessing the Database.
Keep in mind that there are certain things that you cannot do in LocalMode that you can in ServerMode. One that I recall, is exporting to anything other than PDF or Excel.
Two interfaces of Reporting Engine are possible:
sql based for sql based user
non-sql Based interface for normal non-sql friendly users
Database is very large so how do I go about thinking about 2) option that is Non-sql based interface
How would it be ?
If you're using SQL Server 2005 or higher, you may want to consider the ReportBuilder supplied as part of Reporting Services.
You just need to build a 'business friendly' schema (known as a 'DataSource View') then auto-build a Report Model on top.
The users just connect to the Report Model using the Report Builder tool and they can create their own reports.
If you already have SQL Server, then the additional costs would be minimal.
You need an easy way to build SQL queries. Look at the wizards in all the desktop databases, but something that isn't paged might be more intuitive, e.g. http://ruleeditor.googlecode.com/svn/wiki/NSRuleEditor_Tiger.png (not affiliated)
I would like to use SQL Reporting Services 2008 to generate my reports, but I want to use my own UI for specifying the report type, columns, parameters and everything. I want to be able to take these criteria, and then kick off an asynchronous request to SSRS and have the report emailed to me. Is this possible? I don't want to go all the way down the road of researching SQL Reporting Services 2008 only to find that it doesn't do what I need it to do. Also, I will have a ton of DB partitions that the data will need to be pulled from. Some reports will need to pull data from only one of these, but other ones may actually need to span different databases. Is it possible when sending a report request to SSRS to specify what servername/database to pull the data from? Is it possible to tell it to take the data from multiple databases and combine it? Thanks.
Like Crystal Reports, ActiveReports and other report generators, SSRS has two basic elements behind each report: the SQL query and the report layout. No matter what tool you use for the SQL -- it can be inline SQL in the report or a call to a stored procedure -- it's going to be the same query. Multiple databases are fine as long as you can specify them up front.
You can have parameterized queries, so the user is prompted to input the relevant filters (customer ID, product group, date range, whatever).
Doing the report layout is similar to other tools -- you drag and drop controls like labels onto the report, and set their formatting.
SSRS does provide a lot of options for distributing the report, including email. You can embed the report in an ASP.Net web page, leave it on the report server site for users to browse to, run it in the wee hours of the morning and cache it so every user doesn't have to wait for the lengthy query to run.
It's a great tool. I think it will be worth your effort to experiment with it. I would wait on creating the customized UI until you've exhausted the possibilities inherent in the tool.
SSRS is not designed with this scenario in mind, for that matter I am not sure that any out of the box reporting solution is going to have an elegant solution for this. While SSRS can do what you are asking (as well as others), it is by no means quick or easy. You seem to be looking for an advanced ad-hoc solution with dynamic sourcing of the data. I would first question the requirements and determine if the business scenario really justifies such an implementation. I would weigh custom building a solution vs your learning curve with a BI reporting solution. You may find that it is easier to just build something on your own.
I think the heterogeneous dynamic database mashup is probably going to be the most challenging part.
Depending on what your scalability requirements are, one place that has that part covered, and a report writer, is Access. (Duck! Incoming!)
I think you may be creating a rod for your own back to a certain extent as RS ships with a few interfaces for report creation.
Mind you the end product is an rdl file which is nothing but xml, so you can write them by hand if you really like.
Multiple data sources are supported, but combining them on a single control/chart/etc are not, so you'll need to configure yourself a cross database capability from one of your data-sources prior to the report request if you want to do that.