I do have a general question about BI reporting with Microsoft SSRS.
My company uses MS SQL Server as RDBMS and also has MS Analysis Services.
The goal of my company is to establish a consistent definition of Key Performance Indicators for all production facilities and displaying these as a report in SSRS. In the future we also would like to use MS PowerBI for further analysis.
To achieve this goal it is necessary to re-name and do some calculations with the source data from certain PLC systems to reach a common format and join it with data from our ERP - system.
Therefore my question: how is it possible to keep a common data base throughout the company, which offers the possibility for self-service BI? Do other companies normally develop OLAP-cubes for these purposes or is a "materialized view" in the Warehouse getting to a similar result at the end?
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.
We're currently developing a Power BI Dashboard (Office 365) for our company and would like to tailor the information on the dashboard based on the current user's preferences.
Our company has multiple departments and sub-departments, so to display every department's figures to all users would be counter-productive.
For example if Bob is in Sales for Europe - he'll only see European sales, while Sue will only see Sales for America.
Is there a way PowerBI can identify the current user and then filter the results from the SSAS cube based on the user's preferences (which are store on a SQL table)?
I would imagine this could be done via the M Query statement, but I'm unsure on how to use it to filter the results.
It sounds like you have an SSAS cube already? Multidimensional? First setup role based security in SSAS. If you have SQL tables that define who should see what (or in your case it sounds like a user preference, so who wants to see what) then use dynamic security:
http://hccmsbi.blogspot.com/2007/08/implementing-user-specific-security-in.html
Then install the Power BI Enterprise Gateway:
https://powerbi.microsoft.com/en-us/documentation/powerbi-gateway-enterprise/
Then connect it to SSAS:
https://powerbi.microsoft.com/en-us/documentation/powerbi-gateway-enterprise-manage-ssas/
You will need SQL Server 2012 SP1 CU4 or later on SSAS. You will need Enterprise or BI Edition SSAS. And you will need a Power BI Pro license for each user.
Is there any link or zip file where I could get whole MS BI warehouse project (sample) from starting to end? (2008)
Incremental load and even possible creating cubes too. What kind of problems one faced in real time projects, such things.
I could find things on you tube in parts but couldn't link it. Please help.
Rohan
I think the best reference implementation for the MS BI stack is Project REAL. According to Microsoft:
In Project REAL we are creating a reference implementation of a
business intelligence (BI) system using real large-scale data from a
real customer. The goal is to discover the best practices for creating
BI systems with SQL Server 2005 and to build a system that exhibits as
many of those best practices as we can. This project is not just a
demo —we are creating this system for ongoing operation. It is a
complete system, including daily incremental updates of the data,
large multiuser workloads, and system monitoring.
It contains:
A set of instructions for setting up the environment
Guidance on how to explore the implementation
A sample relational data warehouse database (a subset of the Project REAL data warehouse)
A sample source database (from which we pull incremental updates)
SSIS packages that implement the ETL operations
An SSAS cube definition and scripts for processing the cube from the sample warehouse
Sample SSRS reports
Sample data mining models for predicting out-of-stock
conditions in stores
Sample client views in briefing books for the Proclarity and Panorama BI front-end tools
You can download it here - http://www.microsoft.com/download/en/details.aspx?id=12134
you can get the AdventureWorks database and datawarehouse (with the cube) here: http://msftdbprodsamples.codeplex.com/
not sure about the SSIS packages
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.
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)