.What is the difference between reporting and analysis in datawarehousing? Both are giving output with drill down(hierarchy) and i am feeling similar in the case of outputs.
They are distinct concepts.
First you analyze, then you report the results of the analysis. One is almost useless without the other.
Analysis extract relevant information, reporting displays the information.
Data-warehouse reporting (or reports of any sort for that matter) stands for an output from the data-warehouse which can be BI dashboards, just row column reports or any sort of visualization of data. All these reports may or may not have drill downs.
Related
I have data on a MSSQL Server database and have to develop a service that should produce daily reports mostly in pdf format. Mobile and web could be introduced in the future, but are not required now.
There isn't any analytics to implement, just text and numbers that are sums, reached thresholds, warnings and so on. The business logic is in my application / database.
The rest of the report are list of files in a table with names, metadata list and so on.
My feeling is that SSRS is the right tool for me, despite of old style graphic components and tedious RDL definitions :-(
Power BI examples I saw, are really oriented to beautiful charts and but I have a lot of text filled with some number.
The article SSRS vs. Power BI - when to use and why? doesn't clarify enough my scenario.
So before starting the project I'm trying to check if the same things are possible in Power BI in order to use new graphical effects and not closing the door for a future analytics on data.
Any suggestion about the right tech/tool to use for my purpose?
If you want to use Power BI for that, you will need paginated reports to be able to produce reports with multiple pages. The "normal" reports are more suitable to be seen in a browser, to be interactive. However paginated reports a Premium only feature, so it will be an expensive solution. So it looks like SSRS is the right choice in your case.
I have a mysql database as a "Data Ware House".
I have a lot of ready to go queries that I want to run as reports.
So what I need is a web based reporting GUI (Portal) that Can get configuration of:
query, fields titles and report description.
So when ever I want to add a report I just need to provide a query and the reporting gui will have that report in the menu.
Thanks
Have a look at myDBR reporting tool. You can generate good looking reports very easily from your existing queries. myDBR is also able to genereate charts and drill-down reports in a few seconds.
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.
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.
I am developing a Reporting Services solution for a DOD website. Frequently I'll have a report and want to have as a parameter the Service (in addition to other similar mundane, but repetitive parameters like Fiscal Year, Data Effective Date, etc). Basically everything I've seen of SSRS 2005 says it can't be done... but I personally refuse to believe that MS would be so stupid/naive/short-sited to leave something like sharing datasets out of reporting entirely.
Is there a clunky (or not so clunky way) to share datasets and still keep the reporting server happy? Will SSRS2008 do this?
EDIT:
I guess I worded that unclearly. I have a stack of reports. Since I'm in a DoD environment, one common parameter for these reports is Service (army, navy, etc. for those non US users). Since "Business rules" cause me to not be able to use stored procedures; is there a way I can make 1 dataset and link to it from the various reports? Will Reporting 2008 support something like this? I'm getting sick of re-typing the same query in a bunch of reports.
I am not clear if you need to share a dataset, since you have some SQL results that you need to use twice, and don't want to re-compute the same data twice, or you want to do something regarding parameters. So with this "I didn't really understand the question" preface...
You cannot share a dataset. Meaning, you can't, lets say, have a dataset returning table A, and in dataset B try to join with A.
If this is really what you want to do, you could use temporary tables to store A and then in dataset B use the temporary table. There are best practices around that, but since I am not sure this is what you need, I won't spend time talking about that right now.
If you cannot use Stored Procedures, I hope you can use a view.
Else you could leave SQL Server and use CSV sheets as data storage.