I used it to build a simple dashboard. What I did was very simple. I used it to load different datasets. I defined relationships between them and played around with the data by using visuals.
I must have downloaded the version that was really available at that time.
I had to build a simple dashboard in which I had to combine two or three different datasets. They were large enough, so it wasn't possible to work on them easily in Excel. In Power BI, I used the relationship feature, and I was able to store the data in such a way that it does not occupy a lot of space. I could then send the file over email.
Its visualization capabilities are pretty good. It is very easy to use. You can easily make your dashboard.
There is a lot of self-help content available from a lot of different platforms, such as YouTube. So, whenever I faced an issue, it was not difficult. I could always find a solution to the issue I was facing.
Defining a relationship was very confusing. There were circular directions for which I had to do a lot of adjustments in the data. They can do something to make it easier.
I worked on it this summer. I just used it for a month or two.
Defining Relationships can be confusing when you are working with a complex data model. It can result in circular relationship referencing and the interface does not help solve it, or even understand it, in any way. It takes time to figure out a different way to structure the data model and Power BI offers no guidance on that. Online help is limited.
There is a lot of content available online. When I started out, the way I was defining the relationship between the data and the way my model was structured was not very efficient. I spent a lot of time in making it more efficient. So, I would advise others to do enough research. I was learning on the go. If you spend about six or seven hours learning it, it would be much better. Even though it is marketed as something that is easily usable and anyone can come and start using it, there is a bit of a learning curve.
I was very easily able to load the data and conduct an as-is analysis of what is happening, but if I want to do a deeper analysis of the data and break down a variable into different components, I don't know if it is possible in Power BI. I tried to do it a little bit, but it was not easy. So, it is good when you have the data, and you just want to present it and look at it in different ways, but if you want to analyze the data and break down the numbers and play around with the data, I don't know if it is possible in Power BI.
I would rate Power BI a seven out of 10.
Discretization buckets lets you group numerical attributes into ranges. Say you have a customer dimension including the age of the customer you can use this feature to group them into age clusters such as 0-5, 6-10 and so on. While you can tweak how the algorithm creates groups and even provide naming templates for the groups you still have relatively limited control over them. Worst case scenario: A grouping is removed / changed by the algorithm which is referenced in a report. A better way of grouping these attributes is by doing it yourself either in the data source view or a view in the database (there will be a separate tip on this). This way you have complete control over the distribution of values into groups and the naming of the groups.
SSAS has a couple of features that enable it to source data directly from a normalized data model typically found in business applications such as ERP systems. For instance you can “fake” a star schema through queries in the data source view. You can also utilize proactive caching to eliminate any ETL to populate your cube with data. This all sounds very tempting but unfortunatly I have never seen this work in reality. Unless you are working with a very small source system with impeccable data quality and few simultanous users you should avoid the temptation for all the usual reasons: Proactive caching will stress your source system, data quality will most likely be an issue, integrating new data sources will be nearly impossible,etc. There is a reason BI projects spend 70-80% of their time working with modelling and integrating data.
If you are working with multiple environments (dev/test/prod) do not use the deployment functionality of visual studio to deploy to another environment. This will overwrite partitions and roles that may be different between the environments. Use the deployment wizard.
Keep in mind that most client tools do not cope well with changes to SSAS data models. Any renames or removals you do in the model will most likely cause clients that reference those entities to fail. Make sure you test all your reports against the changed model before deploying it to production. Also, if you allow ad-hoc access to your SSAS solution be aware that users may have created reports that you do not know about. Query logging may help you a little here (it gives you an indication of which attribute hierarchies are in use). The best way to avoid all of this is to thoughtfully design your cube and the naming of your SSAS objects so that there is no need to change or remove anything in the first place.
“Real time” means different things to different people. Some interpret it as “simultaneous to an event occurring” while others have more leeway and have various levels of tolerance for delays. I prefer the term “latency”: How old can the data in the BI solution get before it needs to be refreshed?. The lowest latency I have ever implemented is two hours. That is hours not minutes. I know this does not sound very impressive but that is honestly the best I have been able to do at a reasonable cost. When doing “real time” you need to consider a lot of factors: Partitioning, changes to dimensions, ROLAP vs MOLAP / direct query vs xVelocity, source system access, how to administer it, etc., etc. These things add up quickly to a point where the value simply does not justify the cost.
